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