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