Open Stack

On 5/21/15 3:36 PM, Mike Bayer wrote:
>
>
> On 5/21/15 2:57 PM, Mike Bayer wrote:
>>
>>
>> On 5/21/15 2:50 PM, Mike Bayer wrote:
>>>
>>> Put another way, if I want to do a migration that someday, "over 
>>> time", eventually, etc., will drop the "widget_status" table and 
>>> merge it into the "widget" table, how do I write the "get_widget()" 
>>> DB API call ?     Same for just dropping a column.   If we have to 
>>> write code that will return the value of the old table / old column 
>>> while it exists, how does that part work?   Somewhere, there has to 
>>> be code that in one case says: "query(Widget).join(WidgetStatus)" 
>>> and in other case says "query(Widget)".   You have to maintain 
>>> *both* SQL queries at the same time?
>> OK I guess it is this: "Kilo queries Widget JOIN WidgetStatus while 
>> Liberty queries just Widget" - e.g. the two versions of the query are 
>> just in two different releases of the application. You need to run 
>> exclusively the old sqlalchemy/api.py version of the code before 
>> "contract" is run, that is, the new API / nova.objects runs against 
>> the old model code.
>>
>> OK!   let me chew on that.
>
> A side-channel convo with Jay confirms that he had all these same 
> questions / confusion as well - somewhere, his confusion was cleared 
> up, though I don't know where that is.   Might this be a really good 
> reason for this architecture to somewhere be documented really, really 
> completely and thoroughly, with detailed workflow examples and such?  
> If that's been done, can someone link me please?
Here's that link, from way up in this thread:

http://docs.openstack.org/developer/nova/devref/upgrade.html

To the degree that people can help me get on board with how they are 
architecting these things only makes things better, because I'll be 
giving out consistent advice and information to people asking me 
things.   I know I am asking for special treatment, but because I 
maintain the upstream libraries that the work here depends highly on, it 
makes my job a *ton* easier if folks help to keep me in the loop.

Reading in the example here: 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html#proposed-change 


This is the part I'm still unclear on:

" The database migration for this change will simply add the new column, 
but not perform a data migration. Instead, the migration from 
system_metadata to instance_extra will be managed by the objects layer. 
The objects code will handle honoring the system_metadata flavor data, 
if present, otherwise using the new format in instance_extra."

How do we write the database access code for this ?  Using ORM-mapped 
objects, it implies you have an object that has both the system_metadata 
and instance_extra columns on it at the same time. When you run 
"contract" and "system_metadata" is dropped, that mapping will fail.     
I'm looking through all the patches at 
https://blueprints.launchpad.net/nova/+spec/flavor-from-sysmeta-to-blob 
and I'm not seeing where this part happens.   From everything I've read 
today, the data migration between versions A and B is still seeming like 
the key friction point, and while it appears to have a well-defined 
place, I need to be involved with these friction points - Nova's 
database access code has a lot of issues I've been trying to work to 
improve  (poor performance, transaction boundaries all over the place, 
lots of boilerplate), and this seems like a new aspect of it that I'd 
need to take into account.

Can I please have help understanding this?  Thanks.











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150521/10c0869f/attachment.html>