On 4/23/15 11:41 PM, Dan Smith wrote:
That change works on the dataset. However I was referring to the
db/object api (which I have no real knowledge of) that it should be able
to get_by_uuid unmigrated instances and in my case I got the traceback
given in that paste. It's possible I'm just
That change works on the dataset. However I was referring to the
db/object api (which I have no real knowledge of) that it should be able
to get_by_uuid unmigrated instances and in my case I got the traceback
given in that paste. It's possible I'm just using the API incorrectly.
You should be
On 4/22/15 1:20 AM, Dan Smith wrote:
The migrate_flavor_data command didn't actually work on the CLI (unless
I'm missing something or did something odd). See
https://review.openstack.org/#/c/175890/ where I fix the requirement of
max_number. This likely means that operators have not bothered to
Sure, but for people doing continuous deployment, they clearly haven't
ran the migrate_flavor_data (or if they have, they haven't filed any
bugs about it not working[0]).
Hence the usefulness of T-H here, right? The point of the migration
check is to make sure that people _do_ run it before
That is correct -- these are icehouse datasets which have been
upgraded, but never had an juno run against them. It would be hard for
turbo hipster to do anything else, as it doesn't actually run a cloud.
We can explore ideas around how to run live upgrade code, but its
probably a project to
On Thu, Apr 23, 2015 at 1:31 AM, Dan Smith d...@danplanet.com wrote:
Sure, but for people doing continuous deployment, they clearly haven't
ran the migrate_flavor_data (or if they have, they haven't filed any
bugs about it not working[0]).
Hence the usefulness of T-H here, right? The point of
On 4/23/15 1:31 AM, Dan Smith wrote:
Sure, but for people doing continuous deployment, they clearly haven't
ran the migrate_flavor_data (or if they have, they haven't filed any
bugs about it not working[0]).
Hence the usefulness of T-H here, right? The point of the migration
check is to make
On 4/23/15 1:16 PM, Dan Smith wrote:
If I selected all the instance_type_id's from the system-metadata table
and used those uuid's to load the object with something like:
instance = objects.Instance.get_by_uuid(
context, instance_uuid,
Hey, turbo hipster already knows how to upgrade major releases, so
adding this should be possible.
That said, I've been travelling all day so haven't had a chance to
look at this. If Josh doesn't beat me to it, I will take a look when I
get to my hotel tonight.
(We should also note that we can
Hey,
So I can add support to turbo-hipster to apply migrate_flavor_data when
it hits your migration (in fact I started to do this). This means the
tests will pass on your change and continue to once it merges. I'll
update the datasets after the next release but it'll probably be to a
version
(We should also note that we can just merge a thing without turbo
hipster passing if we understand the reason for the test failure.
Sure, that breaks the rest of the turbo hipster runs, but we're not
100% blocked here.)
Indeed, the fact that it's failing actually proves the patch works,
which
The migrate_flavor_data command didn't actually work on the CLI (unless
I'm missing something or did something odd). See
https://review.openstack.org/#/c/175890/ where I fix the requirement of
max_number. This likely means that operators have not bothered to do or
test the migrate_flavor_data
This proposed patch requiring a data migration in Nova master is making
Turbo Hipster face plant - https://review.openstack.org/#/c/174480/
This is because we will require Kilo deployers to fully migrate their
flavor data from system_metadata to instance_extra before they upgrade
to the next
13 matches
Mail list logo
