| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-18 | |||
| 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 | |
| 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 | |
| 18:38:22 | sean-k-mooney | gibi: one question however | |
| 18:39:25 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/870993/1/nova/tests/fixtures/nova.py#1838 | |
| 18:39:41 | sean-k-mooney | shoudl we install the filter in setUp not init | |
| 18:40:02 | sean-k-mooney | i assume the orgianl intent of doign it in init was to do it only once | |
| 18:40:13 | sean-k-mooney | for the life time of the fixture and resue the fixture | |
| 18:40:21 | sean-k-mooney | which is not how we are doign it | |
| 18:40:54 | sean-k-mooney | so if we are going to clean up in cleanup should we set it up in setUp | |
| 21:01:04 | opendevreview | Merged openstack/nova master: Use new get_rpc_client API from oslo.messaging https://review.opendev.org/c/openstack/nova/+/869900 | |
| 21:01:25 | opendevreview | Merged openstack/nova master: FUP for the scheduler part of PCI in placement https://review.opendev.org/c/openstack/nova/+/862876 | |
| #openstack-nova - 2023-01-19 | |||
| 00:41:13 | opendevreview | Ghanshyam proposed openstack/nova master: Bump openstack-placement version in functional tox env https://review.opendev.org/c/openstack/nova/+/871011 | |
| 01:27:03 | gmann | gibi: bauzas: placement is released and bumping the version in tox.ini https://review.opendev.org/c/openstack/nova/+/871011 | |
| 08:33:25 | gibi | gmann: thanks | |
| 08:37:20 | bauzas | gmann: ack, looking | |
| 09:19:26 | opendevreview | Balazs Gibizer proposed openstack/nova master: Clean up after ImportModulePoisonFixture https://review.opendev.org/c/openstack/nova/+/870993 | |
| 09:19:51 | gibi | sean-k-mooney: good point about __init__ vs setUp() in the fixture, I fixed it up ^^ | |
| 09:21:07 | gibi | sean-k-mooney: we have python test executor crashes in functional but we don't have syslog saved in functional so I cannot confirm that it is due to OOM. I see python crashes locally with functional run couple of weeks back and that wasnt OOM but segfault from the interpreter | |
| 09:21:35 | zigo | https://salsa.debian.org/openstack-team/services/ceilometer-instance-poller/-/blob/debian/zed/ceilometer_instance_poller/instance_poller.py#L133 | |
| 09:21:35 | zigo | which works well, but crashes here: | |
| 09:21:35 | zigo | https://salsa.debian.org/openstack-team/services/ceilometer-instance-poller/ | |
| 09:21:35 | zigo | We wrote this: | |
| 09:21:35 | zigo | Hi there! | |
| 09:21:37 | zigo | if we're using the Ceph backend. | |
| 09:21:39 | zigo | Does anyone of you know how to set the libvirt Ceph secret so then libvirt/libguestfs knows how to use the Ceph backend? | |
| 09:37:37 | bauzas | zigo: sorry, not a expert at all on how we integrate with ceph | |
| 09:37:54 | bauzas | maybe look at how nova attaches rdb disks | |
| 09:37:59 | bauzas | rbd* | |
| 09:38:08 | zigo | Yeah, it's smoething like that! :) | |
| 09:38:30 | zigo | Got to find out how to tell libvirt/libguestfs what username and secret to use. | |
| 09:38:50 | zigo | Obviously, I've been search for a long time before asking here ... | |
| 09:40:09 | bauzas | gibi: weirdo | |
| 09:40:46 | bauzas | gibi: I find we only take 30secs for grabbing the image which sizes 85 | |