| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-31 | |||
| 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: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 | |