The problem here is that Havana is not going to know how to backport the Icehouse object, even if had the conductor methods to do so… unless you’re running the Icehouse conductor. But yes, your nova-computes would also need the code to understand to hit conductor to do the backport, which we must not have in Havana?
This also means that if you don’t want your computes on Icehouse yet, you must actually be using nova-conductor and not use_local=True for it. (I saw the patch go up to fix the objects use of conductor API… so I’m guessing you must be using local right now?) So, I think an upgrade process could be: 1) Backport the ‘object backport’ code into Havana. 2) Set up *Icehouse* nova-conductor in your child cells and use_local=False on your nova-computes 3) Restart your nova-computes. 4) Update *all* nova-cells processes (in all cells) to Icehouse. You can keep use_local=False on these, but you’ll need that object conductor API patch. At this point you’d have all nova-cells and all nova-conductors on Icehouse and everything else on Havana. If the Havana computes are able to talk to the Icehouse conductors, they should be able to backport any newer object versions. Same with nova-cells receiving older objects from nova-api. It should be able to backport them. After this, you should be able to upgrade nova-api… and then probably upgrade your nova-computes on a cell-by-cell basis. I don’t *think* nova-scheduler is getting objects yet, especially if you’re somehow magically able to get builds to work in what you tested so far. :) But if it is, you may find that you need to insert an upgrade of your nova-schedulers to Icehouse between steps 3 and 4 above…or maybe just after #4… so that it can backport objects, also. I still doubt this will work 100%… but I dunno. :) And I could be missing something… but… I wonder if that makes sense? - Chris On Apr 16, 2014, at 12:42 AM, Sam Morrison <sorri...@gmail.com> wrote: > I’ve been playing with having an Icehouse API cell and a Havana compute cell > to see how it goes and to plan how we upgrade to Icehouse. > > Most things actually work out of the box, booting etc works which I would > think is the hard one. > Unfortunately some of the simple ones fail, after some brief testing reboot, > pause and unpause are affected. > These require the object_backport() method of the conductor rpcapi that only > came in Icehouse. > > Error you get is below, I’m wondering if this method could be back ported to > Havana to allow this to work? > Anyone else been working in this area? > > > Traceback (most recent call last): > File "/opt/nova/nova/openstack/common/rpc/amqp.py", line 461, in _process_data > **args) > File "/opt/nova/nova/openstack/common/rpc/dispatcher.py", line 172, in > dispatch > result = getattr(proxyobj, method)(ctxt, **kwargs) > File "/opt/nova/nova/cells/rpc_driver.py", line 184, in process_message > message = self.msg_runner.message_from_json(message) > File "/opt/nova/nova/cells/messaging.py", line 1553, in message_from_json > message_dict['ctxt'], v) > File "/opt/nova/nova/objects/base.py", line 566, in deserialize_entity > entity = self._process_object(context, entity) > File "/opt/nova/nova/objects/base.py", line 536, in _process_object > e.kwargs['supported']) > File "/opt/nova/nova/conductor/api.py", line 331, in object_backport > return self._manager.object_backport(context, objinst, target_version) > File "/opt/nova/nova/conductor/rpcapi.py", line 502, in object_backport > target_version=target_version) > File "/opt/nova/nova/rpcclient.py", line 85, in call > return self._invoke(self.proxy.call, ctxt, method, **kwargs) > File "/opt/nova/nova/rpcclient.py", line 63, in _invoke > return cast_or_call(ctxt, msg, **self.kwargs) > File "/opt/nova/nova/openstack/common/rpc/proxy.py", line 126, in call > result = rpc.call(context, real_topic, msg, timeout) > File "/opt/nova/nova/openstack/common/rpc/__init__.py", line 139, in call > return _get_impl().call(CONF, context, topic, msg, timeout) > File "/opt/nova/nova/openstack/common/rpc/impl_kombu.py", line 824, in call > rpc_amqp.get_connection_pool(conf, Connection)) > File "/opt/nova/nova/openstack/common/rpc/amqp.py", line 574, in call > rv = list(rv) > File "/opt/nova/nova/openstack/common/rpc/amqp.py", line 539, in __iter__ > raise result > RemoteError: Remote error: UnsupportedRpcVersion Specified RPC version, 1.62, > not supported by this endpoint. > > > (also note that this is hard coded to use conductor so if you don’t use > conductor you’ll just get an RPC timeout.) > I think this is a bug but not my first concern. > > > > > Thanks, > Sam > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
