[openstack-dev] [Openstack] [nova] Havana -> Icehouse upgrades with cells
Sam Morrison
sorrison at gmail.com
Thu Apr 24 13:10:55 UTC 2014
Hey Chris,
On 24 Apr 2014, at 4:28 pm, Chris Behrens <cbehrens at codestud.com> wrote:
> On Apr 23, 2014, at 6:36 PM, Sam Morrison <sorrison at gmail.com> wrote:
>
>> Yeah I’m not sure what’s going on, I removed my hacks and tried it using the conductor rpcapi service and got what I think is a recursive call in nova-conductor.
>>
>> Added more details to https://bugs.launchpad.net/nova/+bug/1308805
>>
>> I’m thinking there maybe something missing in the stable/havana branch or else cells is doing something different when it comes to objects.
>> I don’t think it is a cells issue though as debugging it, it seems like it just can’t back port a 1.13 object to 1.9.
>>
>> Cheers,
>> Sam
>
> Oh. You know, it turns out that conductor API bug you found…was really not a real bug, I don’t think. The only thing that can backport is the conductor service, if the conductor service has been upgraded. Ie, ‘use_local’ would never ever work, because it was the local service that didn’t understand the new object version to begin with. So trying to use_local would still not understand the new version. Make sense? (This should probably be made to fail gracefully, however :)
Yeah I understand that now, thanks for that.
> And yeah, I think what you have going on now when you’re actually using the conductor… is that conductor is getting a request to backport, but it doesn’t know how to backport…. so it’s kicking it to itself to backport.. and infinite recursion occurs. Do you happen to have use_local=False in your nova-conductor nova.conf? That would cause nova-conductor to RPC to itself to try to backport, hehe. Again, we should probably have some graceful failing here in some way. 1) nova-conductor should probably always force use_local=True. And the LocalAPI should probably just implement object_backport() such that it raises a nice error.
Hmm I may have but I’ve just done another test with everything set to use_local=False except nova-conductor where use_local=True
I also reverted that change I put though as mentioned above and I still get an infinite loop. Can’t really figure out what is going on here.
Conductor is trying to talk to conductor and use_local definitely equals True.
(this is all with havana conductor btw)
> So, does your nova-conductor not have object version 1.13? As I was trying to get at in a previous reply, I think the only way this can possibly work is that you have Icehouse nova-conductor running in ALL cells.
OK so in my compute cell I am now running an Icehouse conductor. Everything else is Havana including the DB version.
This actually seems to make all the things that didn’t work now work. However it also means that the thing that did work (booting an instance) no longer works.
This is an easy fix and just requires nova-conductor to call the run_instance scheduler rpcapi method with version 2.9 as opposed the icehouse version 3.0.
I don’t think anything has changed here so this might be an easy fix that could be pushed upstream. It just needs to change the scheduler rpcapi to be aware what version it can use.
I changed the upgrade_levels scheduler=havana but that wasn’t handled by the scheduler rpcapi and just gave a version not new enough exception.
I think I’m making progress…..
Sam
>
> - Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140424/f3b1e145/attachment.html>
More information about the OpenStack-dev
mailing list