[ops][nova] How to update from N to N+3 (and manage nova services that don't start because they find too old compute nodes...)
smooney at redhat.com
Mon Jan 10 19:45:46 UTC 2022
On Mon, 2022-01-10 at 10:50 -0800, Dan Smith wrote:
> > Good to know that it is not necessary for nova to go through ALL
> > intermediate releases and perform db-sync The question is if this is
> > true for ALL openstack services (in our deployment the controller node
> > is used for all services and not only for nova)
> Actually, Sean is wrong here - we do expect you to go through each
> release on the controller, it's just that it's rare that it's actually a
> problem. We have had blocker migrations at times in the past where we
> have had to ensure that data is migrated before changing or dropping
> items of schema. We also recently did a schema compaction, which
> wouldn't tolerate moving across the releases without the (correct)
> intermediate step.
dan is correct. you should run each on the contoler back to back.
between train and wallaby specifical and we are in a special
case where we just happen to not change the db in those releases.
xena we started doing db compation yes and moving to alembic instead of
from a cli point of view that is transparent at the nova manage level but
it is still best to do it each release on the contoler to ensure that tanstion happens
> We definitely should fix the problem related to compute records being
> old and causing the controllers to start. However, at the moment, you
> should still assume that each intermediate release needs to be db-sync'd
> unless you've tested that a particular source and target release
> works. I expect the same requirement for most other projects.
we have not tested skiping them on the contolers but i bevile in this case it woudl work ok
to go directly from train to the wallaby code base and do the db sync. train to xena may not work.
if the start and end version were different there is not guarentted that it woudl work due to the
blocker migration, online migrations and eventual drop of migration code that dan mentioned.
but ya unless you have tested it better to assume you cant skip.
More information about the openstack-discuss