| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-18 | |||
| 16:54:10 | bauzas | https://stestr.readthedocs.io/en/latest/MANUAL.html#test-scheduling | |
| 16:54:29 | gibi | bauzas: we just shouldn't load the whole image data in memory at once | |
| 16:54:29 | bauzas | tempest exposes the worker configs from stestr | |
| 16:54:57 | gibi | as in general image size can be way bigger than memory size | |
| 16:55:10 | bauzas | gibi: that's true | |
| 16:55:20 | bauzas | caching the metadata seems ok to me | |
| 16:55:34 | bauzas | caching the data itself seems unnecessary | |
| 16:55:44 | bauzas | unless you want to compare bytes per bytes | |
| 16:55:46 | gibi | yeah meatadata is bound by glance API | |
| 16:55:59 | gibi | image size is unbound | |
| 16:56:05 | bauzas | but agreed you could and should compare streams and not objects | |
| 16:56:15 | bauzas | for the dataz | |
| 16:56:28 | dansmith | it's just a naive test not thinking about the world outside a 16MB image | |
| 16:56:30 | bauzas | glance team is added on the bug report | |
| 16:56:38 | dansmith | anyone using this for verification of a real cloud likely has an even larger image, | |
| 16:56:41 | dansmith | so it's clearly not okay to do this | |
| 16:56:45 | bauzas | agreed | |
| 16:56:55 | bauzas | whoami-rajat: hey, happy new year :) | |
| 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 | |