> Conductors will always need to talk to the database. APIs may not need > to talk to the database. I think we can just roll conductor > upgrades through, and then update ironic-api after that. This should > just work, as long as we're very careful about schema changes (this is > where the expand/contract thing comes into play). Different versions of > conductors are only a problem if the database schema is not compatible > with one of the versions.
Yep, this seems like it's probably the right approach, assuming that your API depending on RPC is still reasonable, performance-wise. It might be confusing for people to hear that ironic's conductor goes last, but nova's goes first. In reality, it was probably not a great idea to have these named the same thing as they're not very similar, but oh well. If you expand your DB schema separate from contract, it's not hard to just have a flag that controls the online migration activity in your objects so that it doesn't start happening until everything is upgraded that needs to care. With that, you could upgrade all the conductors one by one, and when the last one is upgraded, there is some indication that it's okay to start actually writing things into the new column(s), or whatever else. This is something I want nova's conductor to do so that we don't have to upgrade all the conductors at once, which is currently a requirement. We now have a global service_version counter in the database that will provide us the info necessary to control this change. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev