Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-01-31
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 )
17:04:22 elodilles so i guess, in fedora this is needed in xena as well
17:16:15 opendevreview Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858384
17:16:45 sahid addressed minor comments from Rajesh Tailor, thank you !
18:32:32 dansmith sean-k-mooney: gibi bauzas: Things like this https://review.opendev.org/c/openstack/nova/+/872204 are incredibly difficult to make "work" in the functional tests because of all the ways and patterns we start and restart multiple fake computes

Earlier   Later