| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-26 | |||
| 16:59:06 | melwitt | the code as-is in the patch will just move on after the timer expires and leave the worker thread | |
| 16:59:10 | sean-k-mooney | but that feels even more hacky | |
| 16:59:48 | sean-k-mooney | i could use a process pool but that feels a bit heavy weight. if people are ok with that its easy to do i think | |
| 17:00:08 | sean-k-mooney | process pools are ok provide the funciton does not try to modify any shared sate | |
| 17:00:35 | sean-k-mooney | i dont think this code does but thats somethign we would need to be careful of | |
| 17:00:44 | melwitt | yeah. with my patch the review just kept going around in circles with nobody happy with anything so I hopefully you will have better luck | |
| 17:01:13 | sean-k-mooney | im feelign like i might be better off moving that patch to later in the series | |
| 17:01:52 | sean-k-mooney | however i see value in makeing the api eventlet free first | |
| 17:02:08 | sean-k-mooney | since otherwise its the simplest service to do that with | |
| 19:17:50 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 19:19:19 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 19:20:54 | sean-k-mooney | melwitt: by the way this is somehting i was playing with https://github.com/SeanMooney/os-vol | |
| 19:30:08 | melwitt | sean-k-mooney: that is very different :) | |
| 19:30:21 | sean-k-mooney | yep kind of intentionally | |
| 19:30:57 | sean-k-mooney | i was playing with the idea of storage backends abstracting how the storage is provisioned and allocating volumed which are then consumed | |
| 19:31:31 | sean-k-mooney | with the connection between a volume and a backend indirect though a storage pool | |
| 19:32:07 | sean-k-mooney | so you would not create a file or rbd volume | |
| 19:32:21 | sean-k-mooney | you would ask the storage pool to allocate a volume of a given size from its backend | |
| 19:33:09 | sean-k-mooney | that volume object is the logical handel to the backing storage | |
| 19:33:25 | melwitt | hm ok | |
| 19:34:10 | sean-k-mooney | my idea was you could have multiple backend and have adaptor that can take data form diffen sources and import it into a volume | |
| 19:35:04 | sean-k-mooney | i have not really fleshed out the interface much as i said i was just playing with that desgin to see what it looked like | |
| 19:35:38 | melwitt | that's cool | |
| 19:36:45 | sean-k-mooney | im not saying you should not consinue with your experiments by the way, the design im going for might be overly generic for what we want | |
| 19:37:09 | sean-k-mooney | on the other hand i kind of like the idea of having this in a self contianed lib or module with a stict inteface | |
| 19:37:58 | sean-k-mooney | the reason i have host_attach in the interafce for example is so we can allocate a file (lvm volume, rbd volume) | |
| 19:38:09 | sean-k-mooney | attach it to the host | |
| 19:38:17 | sean-k-mooney | call makefs on it and unmount it | |
| 19:38:34 | sean-k-mooney | without having to care where the data is stored | |
| 19:39:00 | melwitt | sure. where I was coming from is I wondered if we can pare down/simplify imagebackend as a baby step and whether or not it could make image format tracking easier in some way | |
| 19:39:13 | sean-k-mooney | yep | |
| 19:39:23 | sean-k-mooney | i think that would be valueable to do in anycase | |
| 19:40:11 | melwitt | I was thinking priority one is getting the format tracking done and I thought maybe removing some of the confusing layers of indirection could help facilitate that | |
| 19:40:34 | sean-k-mooney | yep i agree | |
| 19:42:15 | sean-k-mooney | i dont know if you looked at some of the tests i created https://github.com/SeanMooney/os-vol/blob/master/os_vol_tests/unit/backends/test_flat_file.py#L38-L63 but as i said this is just something im toying with form time to time | |
| 19:42:38 | sean-k-mooney | i have not considered how you could use this in nova really | |
| 19:43:04 | sean-k-mooney | having a simplifed code path would help if we were ever going to consider going this way | |
| 19:44:54 | melwitt | dansmith: I tried a minimalistic refactor of imagebackend things with the goal of helping somehow with the image format tracking we want to do https://review.opendev.org/c/openstack/nova/+/925635 I dunno if something like that could help with the ideas you had for the format tracking | |
| 19:45:35 | dansmith | melwitt: ah cool, I'll queue up a look | |
| 19:46:14 | melwitt | sean-k-mooney: ah yeah, I didn't see the tests. that does make it easier to understand | |
| 19:47:25 | sean-k-mooney | i defintly have some bugs but im going to keep playing wiht it on and off and see if i can build it out to be something more useful but its just a toy for now. | |
| 21:01:58 | opendevreview | Merged openstack/nova stable/2024.1: Functional test test_boot_reschedule_with_proper_pci_device_count https://review.opendev.org/c/openstack/nova/+/926556 | |
| 21:07:38 | opendevreview | Merged openstack/nova stable/2024.1: Fix PCI passthrough cleanup on reschedule https://review.opendev.org/c/openstack/nova/+/926557 | |
| 21:31:43 | opendevreview | Merged openstack/nova master: Deprecate AMI image formats https://review.opendev.org/c/openstack/nova/+/926144 | |
| #openstack-nova - 2024-08-27 | |||
| 07:03:17 | gibi | sean-k-mooney: I have no preference between eventlet an healthcheck. I will take a look at the healthcheck series today | |
| 07:09:30 | gibi | sean-k-mooney: on the timer, I will reply in the review | |
| 10:09:19 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: functional: Handle multiple networks https://review.opendev.org/c/openstack/python-novaclient/+/927249 | |
| 10:09:20 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: Fix Python 3.12 compatibility https://review.opendev.org/c/openstack/python-novaclient/+/927251 | |
| 10:09:20 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: tox: Add Python-specific functional envs https://review.opendev.org/c/openstack/python-novaclient/+/927250 | |
| 10:44:16 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927254 | |
| 15:11:23 | bauzas | that's been a while but we'll have a nova meeting here in 50 mins | |
| 15:15:06 | stephenfin | sean-k-mooney: Here's the fix for the novaclient issue https://review.opendev.org/c/openstack/python-novaclient/+/927249/ I know you were saying that should test the default configuration of auto-configuring a network, but that will never work with multiple possible networks. If we want to test that properly we'll need a separate job that removes e.g. the share network, but that seems like overkill | |
| 15:15:26 | stephenfin | So hopefully the bit of logic I've copied in there if sufficient | |
| 15:15:33 | sean-k-mooney | the legacy test is testing before the auto network feature was added | |
| 15:16:04 | sean-k-mooney | so ya the issue here is that the job is not conigured to allw the test to run | |
| 15:16:19 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: tox: Add Python-specific functional envs https://review.opendev.org/c/openstack/python-novaclient/+/927250 | |
| 15:16:19 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: functional: Handle multiple networks https://review.opendev.org/c/openstack/python-novaclient/+/927249 | |
| 15:16:20 | opendevreview | Stephen Finucane proposed openstack/python-novaclient master: Fix Python 3.12 compatibility https://review.opendev.org/c/openstack/python-novaclient/+/927251 | |
| 15:16:32 | stephenfin | (just spotted so leftover print statements) | |
| 15:16:42 | sean-k-mooney | i saw them | |
| 15:16:49 | stephenfin | s/so/some/ | |
| 15:16:51 | sean-k-mooney | but my point it this is ment to be testing when we do not specify a nic | |
| 15:16:57 | sean-k-mooney | so adding a nic invaldiates the test | |
| 15:17:15 | stephenfin | so do we add a skipTest if self.multiple_networks? | |
| 15:17:18 | sean-k-mooney | it would be better to use the skip test funciontion if we detect multiple networks | |
| 15:17:32 | sean-k-mooney | yep that was one of the opetions | |
| 15:17:46 | sean-k-mooney | i was also lookig at modifyitg the job to remove the share network | |
| 15:18:07 | stephenfin | though I'll note there's nothing in the test name or docstring that says this needs to rely on being able to auto-configure a network | |
| 15:18:18 | stephenfin | so what makes you say that we're testing that? | |
| 15:18:18 | sean-k-mooney | its not | |
| 15:18:30 | sean-k-mooney | auto configuring the network is an diffent feature then we are testing | |
| 15:18:41 | stephenfin | right, but we're testing the '--image-with' falg | |
| 15:18:43 | stephenfin | *flag | |
| 15:18:46 | sean-k-mooney | this is testing the bahvior or there is only one network | |
| 15:19:02 | stephenfin | having to/not to pass the '--nic' option is secondary to the main test, from the looks of things? | |
| 15:19:06 | sean-k-mooney | which is diffent then auto config which will create it if there is none | |
| 15:19:27 | stephenfin | right, but do we care? that's not the aim of this test | |
| 15:19:49 | sean-k-mooney | it is the aim to ensure that the old command line argument work as openstack evolves | |
| 15:20:02 | sean-k-mooney | at least fo the legacy version that is testin 2.1 | |
| 15:20:46 | sean-k-mooney | stephenfin: if we have a sperate test case for this then im fine with changing this one | |
| 15:20:50 | stephenfin | Again, right, but the test is testing the '--image-with' option, not the '--nic' option (or lack thereof). My change proves the '--image-with' option works on both 2.1 and 2.latest | |
| 15:20:59 | stephenfin | okay, lemme see | |
| 15:21:33 | sean-k-mooney | i think this is the only test without a nic specifed | |
| 15:21:36 | stephenfin | that was easy. It's a short file. None there. Do we add one (with the skip)? | |
| 15:22:23 | stephenfin | relying on there only being one test seems fairly fragile and would prevent us running said tests against a local devstack (at least without doing what CI does and e.g. deleting the 'shared' network) | |
| 15:22:30 | stephenfin | *one network | |
| 15:24:21 | sean-k-mooney | so i think this regression was intoduced by https://github.com/openstack/devstack/commit/24b65adc9cedff9c7a8ab412fb39613ef5d4a627 | |
| 15:24:50 | stephenfin | Hardly. That's there since yoga | |
| 15:24:57 | stephenfin | per the GitHub UI anyway | |
| 15:25:27 | sean-k-mooney | maybe not but was srbac enabeld in neutron by default for that long | |
| 15:26:06 | sean-k-mooney | ok im torn personally i want to remvoe the cli testing and the shell module | |
| 15:26:20 | sean-k-mooney | on the other hand while its there we shoudl nto reduce test coverage | |
| 15:26:36 | sean-k-mooney | so if you want to add a test taht will skip if multiple networks i guess that fine | |
| 15:26:43 | sean-k-mooney | but it also kind of useless without fixing the ci | |
| 15:26:49 | stephenfin | agreed | |
| 15:26:59 | stephenfin | maybe we just merge that and move on with our lives? 🤷 | |
| 15:27:16 | stephenfin | undoubtedly better than making the whole thing non-voting | |
| 15:27:21 | sean-k-mooney | if we do then i think we need to delete the cli next cycle | |
| 15:27:26 | stephenfin | perfect is the enemy of the good | |
| 15:27:28 | stephenfin | etc. etc. | |