Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-01-18
16:57:03 opendevreview Aaron S proposed openstack/nova master: Add further workaround features for qemu_monitor_announce_self https://review.opendev.org/c/openstack/nova/+/867324
16:58:53 opendevreview Aaron S proposed openstack/nova master: Add further workaround features for qemu_monitor_announce_self https://review.opendev.org/c/openstack/nova/+/867324
16:59:49 opendevreview Merged openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650
17:01:08 bauzas hmmm, stackalytics.io is fone
17:01:10 bauzas gone*
17:01:57 gibi what do you mean by gone?
17:02:00 gibi it loads for me with
17:02:01 gibi Last updated on 18 Jan 2023 12:44:21 UTC
17:02:06 bauzas I got a timeout
17:02:16 bauzas oh this works now
17:04:20 gibi gmann, dansmith: was there some policy change recently that can cause that the nova functional test locally gets 403 from placement?
17:04:33 gibi {'errors': [{'status': 403, 'title': 'Forbidden', 'detail': 'Access was denied to this resource.\n\n placement:allocations:list ', 'request_id': 'req-c5c03029-ba79-4e4a-8ec8-03deadb24ded'}]}
17:04:43 dansmith gibi: reliably?
17:04:46 gibi yes
17:04:51 dansmith oof, then probably
17:04:51 gibi this is pure nova master functional test
17:04:53 gmann gibi: yeah we changed the default and placement fixture needed fix whihc is merged i think
17:05:00 bauzas gibi: yeah
17:05:09 gmann gibi: can you rebase the placement repo?
17:05:12 bauzas gibi: we switched to new RBAC policies
17:05:28 gibi it is just my nova repo locally
17:05:32 gmann this one https://review.opendev.org/c/openstack/placement/+/869525
17:05:58 gmann gibi: because nova functional test use placement fixture from placement repo
17:06:17 bauzas which we pull as a dependency, right?
17:06:31 gmann yes
17:06:57 gibi openstack-placement>=1.0.0
17:06:57 gibi so nova's tox.ini has
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 gmann yeah not released yet, we should do
17:08:17 gibi so nova's tox.ini pulls placement from pypi
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 artom There might be something else exposed there, like the 'trusted' param for NICs
17:54:14 mnaser volume uuid? i remember there is a place where it does come from though i think
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

Earlier   Later