<div dir="ltr"><div>Good to know that it is not necessary for nova to go through ALL intermediate releases and perform db-sync<br></div><div>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)</div><div><br></div><div>Thanks, Massimo</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 10, 2022 at 7:03 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2022-01-10 at 18:00 +0100, Massimo Sgaravatto wrote:<br>
> Dear all<br>
> <br>
> When we upgraded our Cloud from Rocky to Train we followed the following<br>
> procedure:<br>
> <br>
> 1) Shutdown of all services on the controller and compute nodes<br>
> 2) Update from Rocky to Stein of controller (just to do the dbsyncs)<br>
> 3) Update from Stein to Train of controller<br>
> 4) Update from Rocky to Train of compute nodes<br>
> <br>
> We are trying to do the same to update from Train to Xena, but now there is<br>
> a problem because<br>
>  nova services on the controller node refuse to start since they find too<br>
> old compute nodes (this is indeed a new feature, properly documented in the<br>
> release notes).<br>
> As a workaround we had to manually modify the "version" field of the<br>
> compute nodes in the nova.services table.<br>
> <br>
> Is it ok, or is there a cleaner way to manage the issue ?<br>
the check is mainly implemeented by <br>
<a href="https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/utils.py#L1052-L1099" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/0e0196d979cf1b8e63b9656358116a36f1f09ede/nova/utils.py#L1052-L1099</a><br>
<br>
i belive the intent was this shoudl only be an issue if the service report as up<br>
<br>
so you should be able to do the following.<br>
1 stop nova-compute on all nodes<br>
2 wait for compute service to be down then stop contolers.<br>
3 upgrade contoler directly to xena skiping all intermediary releases.<br>
(the db sysncs have never needed to be done every release we keep the migration for many releases.<br>
there also are no db change between train and wallaby and i dont think there are any in xena either)<br>
4 upgrade the nova-compute on all compute nodes.<br>
<br>
looking at the code however i dont think we ar checking the status of the services at all so it is an absolute check.<br>
<br>
as a result you can nolonger do FFU which im surpised no on has complained about before.<br>
<br>
this was implemented by <a href="https://github.com/openstack/nova/commit/aa7c6f87699ec1340bd446a7d47e1453847a637f" rel="noreferrer" target="_blank">https://github.com/openstack/nova/commit/aa7c6f87699ec1340bd446a7d47e1453847a637f</a> in wallaby<br>
<br>
just to be clear we have never actully support having active nova service wherne the version mix is greate then n+1<br>
we just started enforceing that in wallaby <br>
<br>
<br>
> <br>
> Thanks, Massimo<br>
<br>
<br>
</blockquote></div></div>