Team Meeting Agenda for November 8, 2022

[Clark Boylan]

Hello,

We will meet with this agenda on November 8, 2022 at 19:00 UTC in #opendev-meeting:

== Agenda for next meeting ==

* Announcements

* Actions from last meeting

* Specs Review

* Topics
** Bastion host (ianw 20221108)
*** https://review.opendev.org/q/topic:prod-bastion-group
*** https://review.opendev.org/q/topic:bridge-ansible-venv
*** https://review.opendev.org/c/opendev/system-config/+/863564
*** https://review.opendev.org/c/opendev/system-config/+/863568
** Upgrading Bionic servers to Focal/Jammy (clarkb 20221101)
*** https://etherpad.opendev.org/p/opendev-bionic-server-upgrades
** Mailman 3 (clarkb 20221108)
*** https://review.opendev.org/c/opendev/system-config/+/851248 Worthy of review at this point
*** https://etherpad.opendev.org/p/mm3migration
*** https://review.opendev.org/c/opendev/system-config/+/860157 Forking the upstream images due to lack of attention on issues and PRs we've filed
** Updating base python docker images to use `pip wheel` (clarkb 20221108)
*** Pip changed how it addresses wheels in its wheel cache which broke our assemble script's ability to build packages on our image builds.
*** I've filed a bug against pip for this and pushed a PR to fix it. However, upstream pip says we shouldn't rely on the wheel cache like this and should use `pip wheel` instead.
*** https://github.com/pypa/pip/issues/11527
*** https://github.com/pypa/pip/pull/11538
*** https://review.opendev.org/c/opendev/system-config/+/862152
** Etherpad docker container logs growth (clarkb 20221101)
*** Need change to log to syslog instead similar to other services.
** Quo vadis storyboard (frickler 20221107)
*** ML thread https://lists.opendev.org/pipermail/service-discuss/2022-October/000370.html
*** Many people interested in moving away from storyboard
*** No volunteers to update our installation
*** How long can we/do we want to commit to running an outdated installation on an EOL OS?
** Nova server rescue behavior in vexxhost (clarkb 20221108)
*** Clarkb has tested this and the behaviors are surprising
*** Rescuing a normal disk instance results in the instance boot with the rescue image kernel and the rescued instance's root device mounted on / instead of the rescue image mounted to /.
*** Rescuing a BFV instance fails. First with the default microversion because old Nova API doesn't support this. When using microversion 2.88 it also fails, but only after attempting to rescue.
**** The instance goes into an error state due to "cannot be rescued: Driver Error: Cannot access storage file"
**** Attempting to unrescue the instance also fails because you cannot unrescue an instance that is in an error state

* Open discussion