Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-05-17
18:17:18 sean-k-mooney but we dont use that for anything other the nfs
18:19:22 sean-k-mooney the problem is this logic https://github.com/openstack/nova/blob/ab3ca1e2059f951b44d723c15a5065c6532540da/nova/virt/libvirt/driver.py#L2045-L2065
18:19:36 sean-k-mooney if we have 2 vms on the same host using the same multi attach volume
18:19:46 sean-k-mooney and you delete both of them at the same time
18:19:57 melwitt ah ok
18:20:16 sean-k-mooney then because we are looking at the host's instance list until know if we should do the disconenct there is a race
18:21:18 sean-k-mooney so to fix it we either need a refence count and delete it when that hits 0 or we need to just seriase the delete
18:21:32 sean-k-mooney i think the latter is simpler and safer
18:21:54 melwitt I agree
18:23:01 sean-k-mooney ok now that i know someone else does not think this is an insane approch i think im going to call it a day
18:23:18 melwitt haha :)
18:23:54 sean-k-mooney the worst part was i didnt even thing the issue was with my fix. i was confived the issue was with my repoducer test for so long
18:24:38 melwitt I know the feeling 😝
19:26:11 opendevreview melanie witt proposed openstack/nova master: docs: Add more information about unified limits https://review.opendev.org/c/openstack/nova/+/919913
20:51:19 opendevreview melanie witt proposed openstack/nova master: Support create with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870932
20:51:19 opendevreview melanie witt proposed openstack/nova master: Consolidate vTPM and ephemeral encryption secret creation https://review.opendev.org/c/openstack/nova/+/912094
20:51:20 opendevreview melanie witt proposed openstack/nova master: libvirt: Add optional 'description' kwarg to create_secret() https://review.opendev.org/c/openstack/nova/+/919986
23:42:27 opendevreview melanie witt proposed openstack/nova master: Support (resize|cold migration) with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870933
23:42:28 opendevreview melanie witt proposed openstack/nova master: Support live migration with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/905512
23:42:29 opendevreview melanie witt proposed openstack/nova master: Support rebuild with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870939
23:42:31 opendevreview melanie witt proposed openstack/nova master: Add backing_encryption_secret_uuid to BlockDeviceMapping https://review.opendev.org/c/openstack/nova/+/907960
23:42:31 opendevreview melanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase https://review.opendev.org/c/openstack/nova/+/870936
23:42:32 opendevreview melanie witt proposed openstack/nova master: Support encrypted backing files for qcow2 https://review.opendev.org/c/openstack/nova/+/907961
23:42:34 opendevreview melanie witt proposed openstack/nova master: Validate key manager create access in API https://review.opendev.org/c/openstack/nova/+/919989
23:42:34 opendevreview melanie witt proposed openstack/nova master: Support rescue with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/873675
23:42:35 opendevreview melanie witt proposed openstack/nova master: libvirt: "Auto heal" ephemeral encryption secrets on guest launch https://review.opendev.org/c/openstack/nova/+/919991
23:42:35 opendevreview melanie witt proposed openstack/nova master: Clean up unused ephemeral encryption libvirt secrets https://review.opendev.org/c/openstack/nova/+/919990
23:42:36 opendevreview melanie witt proposed openstack/nova master: Support encrypted source images for qcow2 https://review.opendev.org/c/openstack/nova/+/919992
#openstack-nova - 2024-05-19
13:49:54 opendevreview Takashi Kajinami proposed openstack/osc-placement master: Replace simplejson by built-in json https://review.opendev.org/c/openstack/osc-placement/+/919999
14:34:57 opendevreview Dmitriy Rabotyagov proposed openstack/nova master: Handle MAC dash-addresses during migration https://review.opendev.org/c/openstack/nova/+/919760
#openstack-nova - 2024-05-20
11:56:10 wncslln hey nova o/, I was looking at some low hanging fruits bugs to solve, I've found this one https://bugs.launchpad.net/nova/+bug/2065693
11:56:32 wncslln since I'm a beginner, someone could show me where I should fix, if is possible?
11:57:35 wncslln I undestood that foreign key may does not exist in another table
12:04:14 sean-k-mooney wncslln: that might not be the best bug to start with
12:05:17 sean-k-mooney this tempest test is trying to delete an server that has not been completed spawning yet
12:06:01 sean-k-mooney what failing is recordign the delete event on the instancee because the instnace does not currently exist in the instnace table
12:06:23 sean-k-mooney that is causing the foreign key to fail
12:06:47 sean-k-mooney so this is not an issue with the db schema
12:07:44 sean-k-mooney whats broken here is that we shoudl gracefuly handle that issue and either reject the delete at the api or complete the delete without an error
12:10:56 sean-k-mooney neither are trivial to do correctly. we likely do no want to reject the request as a user should always be able to delete an insance for billing reasons
12:11:19 sean-k-mooney so while a 409 conflict could be valid in other case it woudl be undesireable in this case
12:11:58 sean-k-mooney the simplest possibel fix in this case would be ot catch the excption to record the instance action and log/ignore it then proceeed with the delete
12:13:29 sean-k-mooney that would be a valid resolution to the bug but if the instance does not exist in the cell db it also means we cant mark it as deleted which means we have no way to interup the request to spawn it.
12:13:42 sean-k-mooney which is why this is a hard thing to fix as a first bug
12:15:29 wncslln I see... I'll follow the bug updates to see the resolution and try to understand it
12:16:29 wncslln so sean-k-mooney, do you recommend any bug?
12:17:06 sean-k-mooney we do actully have a list of low hanging fruit bugs https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit i have not looked at that in a while
12:17:11 sean-k-mooney but perhaps one of those
12:18:31 sean-k-mooney perhaps https://bugs.launchpad.net/nova/+bug/2015330
12:19:40 sean-k-mooney for something perhaps more featury then bug we have this tech debt reduction bug https://bugs.launchpad.net/nova/+bug/1994139
12:22:57 wncslln I'll take a look on these. thanks!
13:36:36 stan live migrate says rolled back on the target server, what would be the appropriate logs to check for further troubleshooting?
14:36:29 opendevreview sean mooney proposed openstack/nova master: [WIP] ensure correct cleanup of multi-attach volumes https://review.opendev.org/c/openstack/nova/+/916322
14:52:12 dansmith bauzas: trivial patches to CI jobs, if you have a minute: https://review.opendev.org/c/openstack/nova/+/919738
14:52:33 dansmith first one saves us *minutes* of setup time on the affected jobs, second one goes back to regular images as we discussed
15:24:22 opendevreview Dan Smith proposed openstack/nova master: Stop using split UEC image (mostly) https://review.opendev.org/c/openstack/nova/+/919739
15:24:22 opendevreview Dan Smith proposed openstack/nova master: Enable OCaaS for several nova jobs https://review.opendev.org/c/openstack/nova/+/919738
15:24:28 dansmith melwitt: ^
15:24:35 dansmith good catch!
15:32:58 dansmith melwitt: thanks!
15:33:38 melwitt np
15:46:25 sean-k-mooney dansmith: looks like we have upgraded the version of zuul?
15:46:48 sean-k-mooney The RE2 syntax error is: invalid perl operator: (?!
15:47:23 sean-k-mooney clarkb: i rember ther was an annouchment about that a while ago but nova was not using any non RE2 regexes at the time
15:47:29 sean-k-mooney and i dont think we have added any since
15:47:50 sean-k-mooney clarkb: any idea why we are seeing https://review.opendev.org/c/openstack/nova/+/919738/1..2/.zuul.yaml#336 now
15:48:41 sean-k-mooney clarkb: is this just a warning currently?
15:50:43 sean-k-mooney looks like negitive matches are now triggering it
15:50:46 sean-k-mooney irrelevant-files:
15:50:48 sean-k-mooney - ^(?!.zuul.yaml)(?!nova/virt/libvirt/)(?!nova/privsep/).*$
15:51:19 sean-k-mooney i belive what we are trying to express in the nova-lvm jobs is
15:51:53 sean-k-mooney we should only run this on changes to .zuul.yaml nova/virt/libvirt/** and nova/privsep/**
15:52:25 sean-k-mooney so the way to fix this would be to use relevant-files: instead right?
15:52:30 sean-k-mooney gmann: ^
15:58:53 sean-k-mooney so relevent-files: "^(?:.zuul\.yaml|nova\/virt\/libvirt\/.*|nova\/privsep\/.*)$"
17:40:48 sean-k-mooney dansmith: melwitt am i correct that your preference is to move forward with https://review.opendev.org/c/openstack/nova-specs/+/907654 and then continue the converstaion in the implemenation review and loop back and update the spec if needed
17:41:25 dansmith I think I said as much, but I wasn't anticipating your most recent concern, so if we need to nail that down, we should
17:42:25 sean-k-mooney my main concenr is ensuring tha we can express if the instance is encypted (and optionally the format) and if the image is encypted (and the format) seperatly
17:42:48 dansmith yeah I know, and as I just noted, I think that's a dangerous tripwire :)
17:43:39 sean-k-mooney why so? the format so the image and root disk may not be the same.
17:44:17 sean-k-mooney are you suggesting that we shoudl require the instance to be encypted if the image is
17:44:52 dansmith yes and especially that we should not *decrypt* the image if you boot from it without that requirement
17:45:15 sean-k-mooney so i see that as being in conflict with allowing you to take an unecypted snapshot
17:45:19 dansmith that's kinda like having FDE enabled and dropping it because you upgraded to the next version of your OS and forgot to opt-in again
17:45:42 dansmith why? you're specifically asking to have it de-crypted in that case
17:45:59 sean-k-mooney and you explcitly ask to not encypt the instance in the other
17:46:05 sean-k-mooney well implictly
17:46:16 dansmith very implicitly :)
17:46:17 sean-k-mooney but unless we make it a tristate
17:46:25 sean-k-mooney i think that equivlent
17:46:58 dansmith well, the other option would be to require your hw_ to be set to either match the format of the image, or explicitly request cleartext and we refuse to boot if it's not set to match
17:47:08 dansmith but I think that's just adding an extra hoop for people
17:47:38 sean-k-mooney well i wasd thinking that you might want to upload the image in gpg format to glance
17:47:47 sean-k-mooney but boot form a vm in luks format
17:47:58 melwitt I thought the debate here is whether or not to allow a change in encryption format going from image => root disk. because otherwise afaict hw:ephemeral_encryption (the bool) provides everything else?
17:48:03 sean-k-mooney after all we cant boot form an image in gpg format right
17:48:11 dansmith as I said in my reply, I think this is getting to the point of unnecessary layers that users don't care about (i.e. the distinction between glance and nova and cinder's notion of the encrypted-ness)
17:49:11 dansmith sean-k-mooney: gpg format is useless.. it was added before and only because there wasn't userspace tooling for LUKS
17:49:22 dansmith I think they're mostly using it as an example at this point and I thought they were going to drop that anyway
17:49:31 sean-k-mooney ok but we cant boot form that

Earlier   Later