[openstack-dev] [ironic] The scenary to rolling upgrade Ironic

Dan Smith dms at danplanet.com
Wed Oct 14 23:09:07 UTC 2015

> 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.


More information about the OpenStack-dev mailing list