On Mar 24, 2014, at 12:31 PM, Tim Bell <[email protected]> wrote: > > How does this interact with cells ? Can the cell API instances be upgraded > independently of the cells themselves ? > > My ideal use case would be > > - It would be possible to upgrade one of the cells (such as a QA environment) > before the cell API nodes > - Cells can be upgraded one-by-one as needed by stability/functionality > - API cells can be upgraded during this process ... i.e. mid way before the > most critical cells are migrated > > Is this approach envisaged ?
That would be my goal long term, but I’m not sure it’ll work right now. :) We did try to take care in making sure that the cells manager is backwards compatible. I think all messages going DOWN to the child cell from the API will work. However, what I could possibly see as broken is messages coming from a child cell back up to the API cell. I believe we changed instance updates to pass objects back up… The objects will fail to deserialize right now in the API cell, because it could get a newer version and not know how to deal with it. If we added support to make nova-cells always redirect via conductor, it could actually down-dev the object, but that has performance implications because of all of the DB updates the API nova-cells does. There are a number of things that I think cells doesn’t pass as objects yet, either, which could be a problem. So, in order words, I think the answer right now is there really is no great upgrade plan wrt cells other than just taking a hit and doing everything at once. I’d love to fix that, as I think it should work as you describe some day. We have work to do to make sure we’re actually passing objects everywhere.. and then need to think about how we can get the API cell to be able to deserialize newer object versions. - Chris _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
