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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
