Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-01-18
17:06:31 gmann yes
17:06:57 gibi so nova's tox.ini has
17:06:57 gibi openstack-placement>=1.0.0
17:07:06 gibi that should pull in the latest openstack-placement
17:07:12 gibi in the functional venv
17:07:35 bauzas tox -r ?
17:07:42 gibi I have openstack-placement==8.0.0
17:07:44 gibi in the venv
17:07:56 gibi I guess we merged the fix in placement but we haven't released it
17:08:04 gmann i do not think we released placement with that
17:08:17 gibi so nova's tox.ini pulls placement from pypi
17:08:17 gmann yeah not released yet, we should do
17:08:25 gibi ^^ yepp
17:08:43 gibi or change nova's tox.ini to pull placement from github
17:08:55 gmann yeah for now this can be workaround
17:08:57 gmann let me push it today unless bauzas you want to do?
17:10:15 gmann I feel placement fixture import from placement in functional test should be changed like we do for cinder/glance fixture otherwise we need new placement release for any change in there
17:11:11 bauzas gmann: do the push and I'll +1
17:11:30 gmann bauzas: ok
17:12:22 gibi gmann: based on the constraint in tox.ini openstack-placement>=1.0.0 this is the first time we need such a release due to the fixture
17:13:37 bauzas gibi: gmann: shall we consider to pull from gh ?
17:13:57 gibi I would keep pypi
17:14:07 gmann gibi: yeah because this actually change the things like default policy. but this can occur if change in default for policy or config unless we change nova functional test to move to those new defaults. for example
17:14:12 gibi if this becomes a frequent problem then I would change the placemnet fixture in nova
17:14:25 gmann placement policy need different token default than what nova is using for access
17:19:33 gibi I just confimed switching to gh locally in the tox.ini fixes the problem. Still I vote for release a new placement version and bumping the constarint in nova's tox.ini
17:21:06 gmann ok. yeah once released we should bump the constraint if we wan to use it from pypi
17:21:21 gmann I will push the release
17:21:25 gibi yepp
17:21:27 gibi and thanks
17:27:35 bauzas gmann: I need to disappear soon
17:28:08 gmann bauzas: https://review.opendev.org/c/openstack/releases/+/870989
17:31:43 bauzas gmann_afk: gibi: that's where I'm struggling to consider 8.1.0 as a correct number
17:32:03 bauzas placement is cycle-with-rc
17:32:44 gibi bauzas: you mean 8.0.0 was Zed, so 8.1.0 should come from stable/ze?
17:33:04 bauzas gibi: yup
17:33:20 bauzas but we have tools for creating YAMLs
17:33:33 gibi yeah I'm not sure either if we can relase 8.1 from placement master
17:33:36 gibi elodilles: ^^?
17:34:02 bauzas https://releases.openstack.org/reference/using.html#using-new-release-command
17:36:24 bauzas so, I'd say we should call out this release using the tool with "new-release antelope placement milestone"
17:37:40 bauzas elodilles: right?
17:38:33 elodilles we could just release beta from cycle-with-rc projects
17:39:04 gibi that would be 9.0.0 beta I assume
17:39:11 elodilles answering in #openstack-release
17:39:24 elodilles gibi: yes, 9.0.0.0b1
17:39:59 bauzas elodilles: using new-release, I guess this is 'milestone' arg I presume ?
17:41:39 gmann i see, you are right. 8.1.0 is not right
17:43:40 elodilles bauzas: yes, 'milestone' generates 9.0.0.0b1 (to answer it here as well :))
17:43:56 bauzas ack, gtk
17:48:11 mnaser is there a reason why nova only generates device: [] metadata for tagged bdms only?
17:49:03 mnaser https://github.com/openstack/nova/blob/702dfd33bb93b7cee8c76e117e26bfe56f637460/nova/virt/libvirt/driver.py#L12092
17:49:14 mnaser and then https://github.com/openstack/nova/blob/702dfd33bb93b7cee8c76e117e26bfe56f637460/nova/virt/libvirt/driver.py#L12107-L12108
17:49:40 mnaser which then https://github.com/openstack/nova/blob/702dfd33bb93b7cee8c76e117e26bfe56f637460/nova/virt/libvirt/driver.py#L12020-L12024
17:50:00 mnaser and if its supposed to be with way™, how could one figure out whats attached to the system?
17:50:00 mnaser and if its supposed to be with wayâ„¢, how could one figure out whats attached to the system?
17:51:41 bauzas mnaser: sorry, calling it a day
17:52:03 elodilles bauzas gibi : fyi, tox.ini might need an update to allow to install beta releases of placement. that can be done via adding >1.0.0.0b1 instead of >1.0.0 ... if i remember correctly
17:52:12 mnaser bauzas: lol, was that enough nova for you? :p
17:52:22 bauzas mnaser: that :)
17:52:24 bauzas :D
17:52:38 bauzas one day of CI issues, and I quit.
17:52:56 bauzas mnaser: maybe artom could help you
17:53:30 bauzas artom: tl;dr: mnaser is wondering why we only generate the device metadata for tagged bdms
17:53:42 artom mnaser, that's by design IIRC, every other bit of information there is already visible to the guest
17:53:52 artom mnaser, it's only the tag that comes from the user
17:54:00 artom Without the tag it's pointless
17:54:14 mnaser volume uuid? i remember there is a place where it does come from though i think
17:54:14 artom There might be something else exposed there, like the 'trusted' param for NICs
17:54:28 artom mnaser, that should show up as the disk serial number
17:54:59 mnaser ah yes
18:06:25 gibi elodilles: I will do the tox.ini change once the package is on pypi
18:17:24 sean-k-mooney mnaser: artom with that said we coudl generate the metadata if we wanted too
18:17:38 sean-k-mooney it just wont add extra info as artom mentioned
18:17:53 sean-k-mooney you can use lsblk lsusb and lspci to discover it already in the guest
18:17:56 artom sean-k-mooney, we could... I just don't see the point? It's already all info the guest has access to
18:18:00 artom With lspci, `ip`, etc
18:18:17 sean-k-mooney the point woudl jsut to make that part of the metadta nolonger optional
18:18:36 sean-k-mooney so you woudl not have to check if its aviabel or not in the ugest it will be
18:18:43 sean-k-mooney even if you could get that info elsewhere
18:24:07 opendevreview Balazs Gibizer proposed openstack/nova master: Clean up after ImportModulePoisonFixture https://review.opendev.org/c/openstack/nova/+/870993
18:24:51 gibi bauzas: while it is part of the the functional instability it is not the case and therefore this is not the fix for it, but it is related and it is a cleanup ^^
18:25:10 gibi s/it is not the case/it is not the root cause/
18:27:03 sean-k-mooney hum interesting
18:27:07 sean-k-mooney what were we leaking
18:27:18 sean-k-mooney ah the filter
18:28:04 sean-k-mooney ok so we were leakign the filters which could increae memory usage
18:28:17 sean-k-mooney but it is not sharing state or caussing ither issues
18:28:30 gibi yeah
18:28:33 sean-k-mooney it does proably contribute to the oom issues
18:28:51 gibi it is part of the functional instability realted to https://bugs.launchpad.net/nova/+bug/1946339
18:29:14 gibi as in the recent case it is that import poison that get called by the late eventlet
18:33:33 gibi so I looked at the poision and found a global state
18:34:05 sean-k-mooney ya so each executor has what about 1000 tests per worker
18:34:52 sean-k-mooney i would guess this is addign 1-2MB per run
18:34:59 sean-k-mooney at most
18:35:44 gibi yeah it is not realted the OOM case we saw in tempest
18:35:54 sean-k-mooney i have not check but i would be surpried if adding a filter allocates more then a KB or memory it should jsut be a few fucntion pointer and python objects
18:36:22 sean-k-mooney well didnt we also have OOM issues in teh funtional tests
18:36:47 sean-k-mooney wll not OOM python interpreter crahses

Earlier   Later