Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-01-31
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
16:51:59 bauzas thanks all
16:52:04 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-31-16.00.log.html
16:52:04 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-31-16.00.txt
16:52:04 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-31-16.00.html
16:52:04 opendevmeet Meeting ended Tue Jan 31 16:52:04 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:52:04 bauzas #endmeeting
16:55:40 elodilles thanks o/
16:56:15 kashyap sean-k-mooney: Running the stable/xena locally gives me this yak to shave - https://paste.opendev.org/show/bsRpOt3yk8k6LUw5D9P0/
16:57:50 elodilles kashyap: maybe i'm wrong but this can be fixed by updating/installing explicitly setuptools?
16:58:07 kashyap Probably; I'm on Fedora 36
16:58:25 kashyap elodilles: I'm trying to see if this erroneous failure of stable/xena related to my backport or not (it doesn't seem so)
16:58:28 kashyap https://zuul.opendev.org/t/openstack/build/796a6b05d72c4bbd87a3375028d43a1f
16:58:39 kashyap This one: nova.tests.unit.virt.libvirt.test_driver.LibvirtConnTestCase.test_check_can_live_migrate_dest_numa_lm [0.046959s]
16:58:43 kashyap (And that's the backport - https://review.opendev.org/c/openstack/nova/+/851205)
16:59:22 sean-k-mooney oh thats a known issue
16:59:51 elodilles yes, a known one and fixed in upstream gate i think
16:59:55 sean-k-mooney use_2to3 was remvoed in a setuptools verison
17:00:29 kashyap elodilles: Ah, thx. gibi also pointed that there's a rename, hence the fail: https://review.opendev.org/c/openstack/nova/+/871975
17:00:32 kashyap Thanks, gibi!
17:00:35 sean-k-mooney https://github.com/gibizer/openstack-tox-docker/blob/main/ussuri/Dockerfile
17:00:38 gibi I thiunk the yoga container from here https://github.com/gibizer/openstack-tox-docker work on xena too
17:00:52 sean-k-mooney gibi: yes it does
17:01:10 sean-k-mooney kashyap: we swapped form the unmaintained suds_junko repo to a differnt one
17:01:26 sean-k-mooney but that is not your issue
17:01:53 sean-k-mooney you will need to clamp your pip/virtualevn and tox version
17:03:49 elodilles yepp. in upstream xena has newer versions (ubuntu) that's why we needed this up till ussuri ( https://review.opendev.org/c/openstack/nova/+/810461 )

Earlier   Later