<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/21/15 3:36 PM, Mike Bayer wrote:<br>
</div>
<blockquote cite="mid:555E33BE.1050104@redhat.com" type="cite">
<br>
<br>
On 5/21/15 2:57 PM, Mike Bayer wrote:
<br>
<blockquote type="cite">
<br>
<br>
On 5/21/15 2:50 PM, Mike Bayer wrote:
<br>
<blockquote type="cite">
<br>
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?
<br>
</blockquote>
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.
<br>
<br>
OK! let me chew on that.
<br>
</blockquote>
<br>
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?
<br>
</blockquote>
Here's that link, from way up in this thread:<br>
<br>
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/developer/nova/devref/upgrade.html">http://docs.openstack.org/developer/nova/devref/upgrade.html</a><br>
<br>
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. <br>
<br>
Reading in the example here:
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html#proposed-change">http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html#proposed-change</a>
<br>
<br>
This is the part I'm still unclear on:<br>
<br>
"
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
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."<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/nova/+spec/flavor-from-sysmeta-to-blob">https://blueprints.launchpad.net/nova/+spec/flavor-from-sysmeta-to-blob</a>
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.<br>
<br>
Can I please have help understanding this? Thanks.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>