Openstack nova live migration pain

hai wu haiwu.us at gmail.com
Fri Sep 10 21:19:41 UTC 2021


I am new to the current environment. I just asked around, and you are
correct: we had to use a mix of both buster-train-backports and
buster, because some of the packages were breaking systems scripts,
also there was one python-nova that caused the rabbitmq to get into an
endless loop...

Is it possible to just upgrade this package to some later package from
Train, which does not have this bug, in order to work around this
particular buggy state? we could do some tests here, we do have a test
system, which is built the same way, and it is suffering from the
exact same live migration issue ..

On Fri, Sep 10, 2021 at 3:33 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2021-09-10 15:16:46 -0500 (-0500), hai wu wrote:
> > Here is what we use for python3-nova:
> >
> > $ dpkg -l python3-nova
> [...]
> > ii  python3-nova   2:18.1.0-6   all          OpenStack Compute - libraries
> [...]
>
> In your first message you stated "this is Openstack train release,"
> but that's a version of Nova from Rocky (originally released a year
> before Train). It looks like you're using packages which come as
> part of normal Debian 10 (buster), rather than using something like
> buster-train-backports from osbpo.debian.net.
>
> What made you think it was OpenStack Train, and could this be part
> of the problem? Do you maybe have a mixed deployment with some
> components from Train and some from Rocky?
> --
> Jeremy Stanley



More information about the openstack-discuss mailing list