Hi Brett,
Thanks for the debdiffs!
I just reviewed them, and there are changes that should be made.
I could do those myself, but that wouldn't be an opportunity to
learn/practice some details for SRUs for you, so I'll add notes.
*However*, if you're too busy and can't do that, do let me know.
cheers,
Mauricio
...
qemu.git
$ git describe --contains 552de79bfdd5e9e53847eb3c6d6e4cd898a4370e
v7.1.0-rc0~136^2
ubuntu archive:
$ rmadison -a source qemu
...
qemu | 1:2.11+dfsg-1ubuntu7 | bionic | source
qemu | 1:2.11+dfsg-1ubuntu7.40 | bionic-security | source
qemu | 1:2.11+dfsg-1ubuntu7.40 | bionic-updates | source
qemu | 1:4.2-3ubuntu6 | focal | source
qemu | 1:4.2-3ubuntu6.23 | focal-security | source
qemu | 1:4.2-3ubuntu6.23 | focal-updates | source
qemu | 1:6.2+dfsg-2ubuntu6 | jammy | source
qemu | 1:6.2+dfsg-2ubuntu6.2 | jammy-security | source
qemu | 1:6.2+dfsg-2ubuntu6.5 | jammy-updates | source
qemu | 1:7.0+dfsg-7ubuntu2 | kinetic | source
qemu | 1:7.0+dfsg-7ubuntu2 | lunar | source
0) Development release
The development release (lunar) still doesn't have the patch.
That is required for SRU / stable releases.
We'll need a debdiff for lunar, slightly different than kinetic
(release name and greater version string for the upgrade path).
I just checked w/ Christian and we shouldn't wait on qemu 7.1
merge from Debian (sid), which would include the patch, since
the merge from Debian should happen in January to get qemu 7.2.
1) Oldest LTS in standard support
Would Bionic benefit from this fix on the long run as well,
just before it goes into expanded/out of standard- support?
Apparently, some deployments/clouds still use Bionic on kvm
compute nodes.
If so, the backport targets qmp_query_migrate()/same file,
per commit 65ace0604551 ("migration: add postcopy total blocktime into
query-migrate").
2) Debdiffs:
- version strings: the 'lp*' version suffix is fine for
test builds, but for official packages usually (see [1]):
just increment '.1' on stable releases, and '1' on dev.
example:
kinetic (sru): 1:7.0+dfsg-7ubuntu2 -> ubuntu2.1
luanr (devel): 1:7.0+dfsg-7ubuntu2 -> ubuntu3
- changelog: mostly good! (d/p/file.patch; LP: #number?; releases).
The LP bug number 1982284 refers to another/openstack bug,
but the Ubuntu SRUs are coming through this bug, apparently.
Since this is the bug where Ubuntu Archive/Cloud Archive
have packages/series on, to be closed when SRUs land in
-proposed and -updates (and UCA), we should change:
1) the LP bug number in the changelog
2) and patch file names
3) also, it's a good idea to link to other LP bug
in the SRU template '[Other Info]' section.
(you could also just move the SRU template/packages/
series/tracks to the other LP bug, I guess. Up to you.)
- quilt patch: add DEP3 headers [2] (Origin:/Bug-Ubuntu:)
- quilt series: missing 'ubuntu/' dir on k/j (not on f)
- duplications: jammy has duplicated messages, and focal
has that plus duplicated changelog entries? -- for HA? x)
[1] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[2] https://dep-team.pages.debian.net/deps/dep3/
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
** Description changed:
- While live-migrating many instances concurrently, libvirt sometimes return
internal error: migration was active, but no RAM info was set:
- ~~~
- 2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver
[req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance:
af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal
error: migration was active, but no RAM info was set: libvirt.libvirtError:
internal error: migration was active, but no RAM info was set
- ~~~
-
- From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205
-
[Impact]
- * Effects of this bug are mostly observed in large scale clusters with a lot
of live migration activity.
- * Has second order effects for consumers of migration monitor such as
libvirt and openstack.
+ * While live-migrating many instances concurrently, libvirt sometimes
+ return `internal error: migration was active, but no RAM info was set:`
+
+ * Effects of this bug are mostly observed in large scale clusters with
+ a lot of live migration activity.
+
+ * Has second order effects for consumers of migration monitor such as
+ libvirt and openstack.
[Test Case]
Steps to Reproduce:
1. live evacuate a compute
2. live migration of one or more instances fails with the above error
N.B Due to the nature of this bug it is difficult consistently
reproduce.
[Where problems could occur]
- * In the event of a regression the migration monitor may report an
inconsistent state.
+ * In the event of a regression the migration monitor may report an
inconsistent state.
+
+ [Original Bug Description]
+
+ While live-migrating many instances concurrently, libvirt sometimes return
internal error: migration was active, but no RAM info was set:
+ ~~~
+ 2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver
[req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance:
af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal
error: migration was active, but no RAM info was set: libvirt.libvirtError:
internal error: migration was active, but no RAM info was set
+ ~~~
+
+ From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205
--
You received this bug notification because you are a member of SE SRU
("STS") Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1994002
Title:
[SRU] migration was active, but no RAM info was set
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive ussuri series:
New
Status in qemu package in Ubuntu:
Incomplete
Status in qemu source package in Focal:
New
Status in qemu source package in Jammy:
New
Status in qemu source package in Kinetic:
New
Bug description:
[Impact]
* While live-migrating many instances concurrently, libvirt sometimes
return `internal error: migration was active, but no RAM info was
set:`
* Effects of this bug are mostly observed in large scale clusters
with a lot of live migration activity.
* Has second order effects for consumers of migration monitor such as
libvirt and openstack.
[Test Case]
Steps to Reproduce:
1. live evacuate a compute
2. live migration of one or more instances fails with the above error
N.B Due to the nature of this bug it is difficult consistently
reproduce.
[Where problems could occur]
* In the event of a regression the migration monitor may report an
inconsistent state.
[Original Bug Description]
While live-migrating many instances concurrently, libvirt sometimes return
internal error: migration was active, but no RAM info was set:
~~~
2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver
[req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance:
af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal
error: migration was active, but no RAM info was set: libvirt.libvirtError:
internal error: migration was active, but no RAM info was set
~~~
From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1994002/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : [email protected]
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
