Open Stack

On Thu, 2023-04-06 at 12:44 +0100, wodel youchi wrote:
> Hi,
> 
> This is what documentation says about updating kolla-ansible : "Inside a
> series, it is usually sufficient to just update the kolla-ansible package,
> rebuild (if needed) and pull the images, and run kolla-ansible deploy
> again. Please follow release notes to check if there are any issues to be
> aware of."
> 
> So to summarize, the procedure is like this :
> 1 - update kolla-ansible
> 2 - Download the latest containers of the used version
> 3 - In my case publish them in the local registry
> 4 - launch kolla-ansible deploy
> 
> My question :
> Can I do the update directly , especially on the compute nodes, or do I
> have to empty some of them by moving VMs and execute the update on the
> empty nodes only, then proceed with the same logic with the rest of the
> nodes?
in general yes. however depending on the option you selected there can be some downtime.
for example recreating the libvirt/nova-comptue contaienr will not cause teh vm to stop running.
the libvirt contaienr runs with pid=host so the qemu process is not actully runing in the contaienr.
obvioulsy if you have started using the host installed libvirt feature then that is also true.

if you are using kernel ovs then restart the ovs contaienr to update it does not impact the datapath
since that is runningin the ovs kernel module your are just updating the contol plane when you upgrade the
contianer.


stateless services like nova-api will also just work

where you have to be careful is any contaienr that is in the datapath.

for example if you are using iscsid to export cinder lvm
since cinder lvm is not HA the restart of iscsid can cause the vms to loose access to storage.

if your using ceph that is not a problem.


if your using ovn you may similar have some connectiv issue while the distributed contoelrs are recomputing
ther flows.
in general the flow cache in ovs is enough to hide that but new connections wont be establised until the new contaienr starts up properly.

that is why its imporant to pull the images first to keep that start up time as short as possible.

i dont know how many users of kolla actully use the inplace upgrade with production workload.
you can obviouly drain a compute of vms and use --limit to update only empty comptues and live migrate workloads around too.

but in principal i belive inplcae upgrade should be possible.

the kolla team can confirm but when i used to use kolla for an internal dev cloud in my previous job (with ceph) i did not move instances
when i upgraded the cluster.
> 
> Regards.