16:00:27 <bauzas> #startmeeting nova
16:00:27 <opendevmeet> Meeting started Tue Jan 31 16:00:27 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <opendevmeet> The meeting name has been set to 'nova'
16:00:33 <bauzas> hey ho
16:00:44 <gmann> o/
16:00:56 <elodilles> o/
16:01:02 <Uggla> o/
16:01:04 <dansmith> o/
16:01:16 <gibi> o7
16:01:40 <bauzas> okay let's start
16:01:49 <bauzas> #topic Bugs (stuck/critical)
16:01:56 <bauzas> #info No Critical bug
16:02:00 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 27 new untriaged bugs (+1 since the last meeting)
16:02:04 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:02:21 <bauzas> bug baton can be passed over to artom if he wants
16:02:30 <artom> Sure
16:02:38 <artom> I feel like I've skipped.... many weeks
16:02:43 <artom> (unintentionally)
16:03:24 <bauzas> thanks
16:03:36 <bauzas> #info bug baton is being passed to artom
16:03:46 <bauzas> artom: again, this is just a temptative
16:03:52 <bauzas> don't feel that much obliged
16:04:04 <artom> Well don't say that
16:04:30 <bauzas> ok, so, before we move on, do people want to discuss about some , per say, CVE bugfix or everything is OK since we're on track ?
16:04:46 <bauzas> we know we need to progress with wallaby
16:05:06 <bauzas> but I wanted to know whether people wanted to discuss it by now ?
16:06:24 <bauzas> crickets ? ok, so, let's move on
16:06:43 <bauzas> #topic Gate status
16:06:47 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:06:52 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:07:18 <bauzas> gate is still wedgy, but tbh, I had to focus on other priorities last week and this week :(
16:07:38 <gibi> same here, I made no progress on the functional test instability
16:07:39 <bauzas> from what I see, the gate is quite difficult but still mergeable
16:07:47 <dansmith> it's better
16:07:57 <dansmith> I've been unable to reproduce any of the problems locally, unfortunately
16:07:59 <bauzas> on the functest sage ?
16:08:02 <bauzas> saga*
16:08:07 <bauzas> dansmith: that's the problem, I tried too
16:08:26 <bauzas> dansmith: running the exact same way than the gate using the testr subunits
16:08:36 <bauzas> but got nothing
16:09:13 <bauzas> hence me having pivoted, and tbh, there were people afraid of some security bug last week that diverted my attention
16:09:32 <bauzas> but ok, if things are better, that's cool
16:10:01 <bauzas> either way, I'll try to go looking at it back when I'm done with my own prios (including some feature implementation I promised)
16:10:15 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:10:19 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:11:21 <bauzas> ok, let's move on thenb
16:11:28 <bauzas> #topic Release Planning
16:11:32 <bauzas> #link https://releases.openstack.org/antelope/schedule.html
16:11:36 <bauzas> #info Antelope-3 is in 2 weeks
16:11:43 <bauzas> /o\
16:12:01 <bauzas> #link https://etherpad.opendev.org/p/nova-antelope-blueprint-status Blueprint status for 2023.1
16:12:06 <bauzas> so I created a tracking etherpad
16:12:18 <bauzas> most of the blueprints are in the 'unknown' territory
16:12:37 <bauzas> I need to investigate the crime scene and see whether the owner created some changes
16:13:20 <bauzas> so, use that etherpad as you want
16:13:41 <bauzas> ideally, blueprint owners are more than welcome to amend the etherpad with their comments, including patches to review
16:14:01 <bauzas> and cores are welcome to add comments on things they want to review or already did
16:14:58 <bauzas> I tried to add a 'API Impact' bullet on the blueprints that were actually touching the API, not exclusively by a microversion
16:15:31 <bauzas> ok, if anything else, moving on ?
16:15:43 <bauzas> if not*
16:16:30 <sean-k-mooney> sure
16:16:34 <sean-k-mooney> lets proceed
16:17:43 <bauzas> #topic Review priorities
16:17:50 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:17:59 <bauzas> #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:18:09 <bauzas> nothing to mention here
16:18:12 <bauzas> moving on
16:18:17 <bauzas> #topic Stable Branches
16:18:25 <bauzas> passing the mic to elodilles
16:18:41 <elodilles> #info stable releases from last week: nova 26.1.0 (zed); nova 25.1.0 (yoga) nova 24.2.0 (xena) -- with CVE fix
16:18:54 <elodilles> #info stable branches seem to be unblocked / OK back till xena
16:19:05 <elodilles> #info wallaby branch is blocked by tempest (thanks gmann for working on it - https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031941.html )
16:19:16 <elodilles> #info ussuri and train gates are broken broken ('Could not build wheels for bcrypt, cryptography' errors)
16:19:36 <gmann> stable/wallaby fix is not merged yet #link https://review.opendev.org/c/openstack/devstack/+/871782
16:19:51 <elodilles> ussuri/train might work with newer pip version
16:19:51 <bauzas> gmann: thanks for having worked hardly on that
16:19:51 <gmann> sdk job started failing which I need to make non voting to get first fix merged
16:20:03 <bauzas> gmann: what a pile of cards
16:20:22 <gmann> yeah tempest pin on stable EM is always like this :)
16:20:31 <elodilles> gmann: openstacksdk got released some hrs ago, isn't that fixing the gate?
16:20:57 <elodilles> just asking
16:21:01 <gmann> elodilles: need to check, it is failing on <=stable/xena only
16:21:07 <elodilles> ack
16:21:17 <gmann> #link https://zuul.openstack.org/builds?job_name=openstacksdk-functional-devstack&branch=stable%2Fxena&branch=stable%2Fwallaby&skip=0
16:21:53 <elodilles> anyway, last item from me:
16:21:57 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:22:07 <elodilles> EOM
16:22:22 <bauzas> cool
16:22:34 <bauzas> well, not so cool, but moving on
16:22:42 <bauzas> #topic Open discussion
16:22:47 <bauzas> (gmann) PyPi additional maintainers audit for Nova repo
16:22:54 <bauzas> gmann: I've seen your email
16:22:58 <gmann> ok
16:23:01 <bauzas> and I looked at nova
16:23:10 <bauzas> os-vif is impacted
16:23:53 <bauzas> os-resource-classes too
16:24:04 <bauzas> os-traits
16:24:28 <bauzas> and that's it IIRC
16:24:31 <gmann> osc-placement  also i think
16:25:30 <bauzas> oh, actually placement too
16:26:00 <gmann> ah yes. its 'openstack-placement'
16:26:07 <bauzas> gmann: can you summarize the issue and what's requested for each of the projects ?
16:26:13 <bauzas> not for me, but for others
16:26:18 <gmann> sure
16:27:04 <gmann> TC discussed about those additional maintainers in PyPi which can get released without OpenStack knowing about it or more additional maintainers can be added
16:27:15 <gmann> which is nothing but security issue
16:28:14 <gmann> TC decided to clean that  but wanted projects to audit their additional maintained first to check if they can be removed (if they  are inactive or agreed to) or the package maintenance can be handover to them (then retire it from openstack)
16:28:56 <gmann> xstatic-font-awesome repo from horizon is one example of handing over maintenance to additional external maintainers and use it in horizon as one of the user
16:29:59 <bauzas> gmann: so I amended the tracking etherpad https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L141
16:30:02 <gmann> but mostly packages are openstack initiated one and who setup the PyPi initially are in additional maintainers list which should be easy to clean up
16:30:19 <bauzas> I'm personnally OK with removing all marked people on those
16:30:36 <bauzas> they are no longer active contributors on the projects
16:30:48 <bauzas> do people disagree with this ?
16:30:58 <bauzas> pasting it
16:30:59 <gmann> here in nova, we can check if any of those maintainers are active (in OpenStack or in PyPi maintenance) and we need to talk to them first
16:31:00 <bauzas> novaos-vif has berrange and jaypipes as maintainers.os-resource-classes has cdent as maintainerplacement has cdent as maintainerosc-placement has malor as maintaineros-traits has o-tony as maintainer
16:31:10 <dansmith> bauzas: fine with me
16:31:38 <gibi> fine by me too
16:31:39 <bauzas> tbh I even don't know malor
16:31:47 <bauzas> which is a bit of a security risk
16:32:10 <elodilles> +1
16:32:18 <gmann> +1
16:32:29 <sean-k-mooney> i tought i got os-vif moved over to me at some point but sure
16:32:35 <bauzas> gmann: OK, I'll just leave a comment in the etherpad saying that the nova community agrees on removing those names
16:32:46 <gmann> bauzas: perfect. thanks
16:33:01 <bauzas> sean-k-mooney: tbh, I'm OK with leaving only openstackci as the sole maitainer
16:33:14 <sean-k-mooney> ya thats fine
16:33:19 <bauzas> from a security pov, I understand the concerns
16:34:00 <bauzas> and that reminds me the beam accelerator security issue
16:34:09 <sean-k-mooney> oh it was more we need to fix somehting but it was launchpad i got them to amend
16:35:00 <bauzas> can we then consider this done ?
16:35:56 <sean-k-mooney> i think so at least form our part
16:36:03 <gmann> yes, that is needed from project side. adding audit result in etherpad
16:36:04 <sean-k-mooney> the maintainer need to actuly be updated
16:36:26 <bauzas> I mean, are we done discussing this topic now ?
16:36:39 <bauzas> if so, nothing left on the agenda
16:37:14 <bauzas> except maybe documing the volume detach issues but since they are actually unrelated to our releases, I think I'll just drop this iteam
16:37:17 <bauzas> item
16:37:36 <bauzas> so
16:37:42 <bauzas> any other item to raise by now ?
16:38:31 <Uggla> Can you quickly discuss about :https://review.opendev.org/c/openstack/nova/+/868089/8
16:39:19 <Uggla> I would like to know if we would like to backport it and to which version.
16:40:43 * bauzas looks
16:41:34 <bauzas> isn't it changing the logic ?
16:41:37 <gibi> based on the impl it is backportable
16:41:52 <bauzas> wait
16:42:09 <gibi> it has a dependency on https://review.opendev.org/q/topic:bug%252F1628606 which is being backported
16:42:14 <bauzas> this is post_live_mig_at_dest()
16:42:27 <bauzas> which is run on the dest
16:42:54 <bauzas> my question is, in a rolling upgrade scenario with operators moving workloads from old compute to new compute
16:43:08 <bauzas> would that break them ?
16:43:27 <gibi> bauzas: the bug is ther until the dest is upgraded
16:44:00 <bauzas> we say we gonna rely on https://review.opendev.org/c/openstack/nova/+/791135
16:44:26 <bauzas> but correct me if I'm wrong, this won't happen for a A to B livemig if A is old, nope ?
16:44:56 <bauzas> this chit-chat limbo dance between two hosts is confusing
16:45:09 <bauzas> I never know which compute runs which codepath
16:45:11 <gibi> this patch trying to fix a bug that happens on the dest after the live migration finished
16:45:27 <gibi> at that point there is no return to the source host
16:45:56 <gibi> Amit fixed that in this case we set the instance to point to the dest host so a hard reboot can recover the instance
16:46:24 <bauzas> but we backported Amit's patch, right?
16:46:29 <gibi> yes
16:46:36 <bauzas> ok, so we're safe
16:46:46 <gibi> Uggla had a case where a very similar failure could leave the instance in Migarting state
16:47:00 <gibi> this fix is putting the instance in error in this case too
16:47:12 <bauzas> I see
16:47:35 <bauzas> ok, then to answer Uggla's question, I don't see any controversy to backport such change once we merge it
16:47:58 <gibi> yepp
16:48:24 <Uggla> down to ?
16:48:34 <gibi> the same version as Amit's
16:48:40 <bauzas> yup
16:48:48 <gibi> I think that is proposed back to train
16:48:49 <bauzas> which is train iirc
16:48:52 <bauzas> yup
16:49:04 <bauzas> but as we said, we're on hold on wallaby
16:49:13 <bauzas> nothing prevents us to do the work tho
16:50:23 <bauzas> can we end the meeting then ?
16:50:55 <Uggla> ok 4 me.
16:51:08 <gibi> nothing else from me
16:51:57 <bauzas> then
16:51:59 <bauzas> thanks all
16:52:04 <bauzas> #endmeeting