Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-11-15
10:04:04 gibi one more done https://review.opendev.org/c/openstack/nova-specs/+/861033 for me it does not make sense but I maybe missing something
10:07:27 bauzas fwiw, I'm fast-approving already-approved specs that were in Zed
10:07:39 gibi bauzas: ack, go for it
10:07:39 bauzas just checking if the file was modified
10:08:26 gibi except maybe with https://review.opendev.org/c/openstack/nova-specs/+/863884 where we need to check that is in sync with the new direction
10:10:09 bauzas gibi: correct, I just approved Uggla's spec, that's it
10:10:18 gibi bauzas: OK
10:10:21 bauzas gibi: I was litterally diffing on my laptop the userdata one :)
10:10:30 bauzas and I see the new direction
10:10:40 gibi cool. I will get to it eventually too
10:14:14 bauzas I'll leave my comments now
10:14:17 bauzas I'm torn
10:15:48 opendevreview Merged openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" https://review.opendev.org/c/openstack/nova-specs/+/864206
10:28:44 bauzas gibi: if you're interested, that's my thoughts on the userdata things https://review.opendev.org/c/openstack/nova-specs/+/863884
10:28:52 gibi I will check
10:29:17 bauzas tl;dr: I'd rather not want to have something specifically written while we already have os-instance-actions API
10:30:36 bauzas indeed
10:30:56 bauzas but I also need to update my CPU spec :)
10:52:15 opendevreview Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773
11:06:37 opendevreview sean mooney proposed openstack/nova-specs master: add spec for fqdn in hostname https://review.opendev.org/c/openstack/nova-specs/+/862626
11:11:04 sean-k-mooney[m] gibi sorry was reworking the fqdn spec. ill take a look at he max physical adress spec. qemu does allow you to change the adress space that is virutalised. i have not read the spec but you can have a requirement to reduce that or increase that depending on some factors. the adress space of the vm cannot exceed the hardware its on so somethime you need to reduce it to allow kvm to work such as on an m1 macbookair. qemu does not
11:11:04 sean-k-mooney[m] default to the full adress space of the host either in some cpu models so you might need to increase it to create really large vms.
11:12:21 gibi sean-k-mooney[m]: the spec only ask for increasing the address space but as far as I understand that can be done by simply change the default to be as big as the host cpu
11:12:24 sean-k-mooney[m] i assume there use case is one of those. very big vm where the default is too low or restriced hardware where the default is two high. i feel like this is one case where a host option might work or image property. if we were to do it.
11:12:44 sean-k-mooney[m] can you change teh default in libvirt already?
11:12:54 sean-k-mooney[m] if so then we can just document that
11:13:40 sean-k-mooney[m] im going to step away for 5 mins and get coffee and then ill be back soon to review it.
11:14:13 gibi the libvirt doc suggested having a default so I assumed that it is a configurable default
11:14:46 gibi anyhow if the default is not configurable today then I still would like to have that configurable in libvirt instead of exposing yet another really low level HW knob in nova
11:22:13 opendevreview Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773
11:26:24 opendevreview Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773
11:38:42 bauzas gibi: yeah, I need to update the CPU spec, I didn't had time until noon https://review.opendev.org/c/openstack/nova-specs/+/861591
11:38:56 bauzas gibi: I'll ping you later in the afternoon once I upload a new rev
11:39:04 bauzas should be an easy small spec
11:39:26 gibi bauzas: ack
13:23:20 opendevreview Merged openstack/nova-specs master: Robustify Compute Node Hostnames backlog spec https://review.opendev.org/c/openstack/nova-specs/+/853837
13:28:50 opendevreview Sylvain Bauza proposed openstack/nova-specs master: Proposes cpu power managment in libvirt https://review.opendev.org/c/openstack/nova-specs/+/861591
13:29:06 bauzas sean-k-mooney: gibi: just made modifications to the CPU mangement spec ^
13:35:30 sean-k-mooney ack it will proably be an hour or so before i get to it
13:38:58 JohnnyW Hello, just a question about nova and barbican cooperation, maybe someone faced such issue already. I have two volumes encrypted, one is using a key which was created before an upgrade of barbican from ussuri version to yoga version, so far both are OK, but if I detach volume which is using ussuri key, then I cannot attach that volume to another
13:38:58 JohnnyW instance with information in nova logs: "libvirt.libvirtError: internal error: unable to execute QEMU command 'blockdev-add': Invalid password, cannot unlock any keyslot", but if I do the same operation with a volume which is using yoga key, then everything is fine. So far I checked that I'm able to retrieve secret payload from ussuri and yoga keys
13:38:58 JohnnyW and everything looks fine, there is no error logs in barbican. So I'm wondering what can be an issue here, any ideas? Thanks in advance for suggestions!
13:40:03 sean-k-mooney JohnnyW: do you onw the key and volume
13:40:40 sean-k-mooney if you are not the user that created teh encyped volume then the key in barbican will be owned by the orginal user and you will not be able to attach it to another vm
13:41:19 sean-k-mooney encypted volume encyption keys are onwed by the user that created it not the project
13:41:29 sean-k-mooney as is the case with all secrets stored in barbican
13:41:48 JohnnyW sure, I'm owner of both keys
13:42:07 JohnnyW that is why this behavior looks strange for me
13:42:14 sean-k-mooney ok then in that case im not really sure
13:42:23 sean-k-mooney its the same version fo nova/libvirt right
13:42:35 sean-k-mooney just one was created before the upgrade and the other after
13:43:36 JohnnyW nova/libvirt are exactly the same, only barbican version changed in between...and vault as a backend and SoftHSM for keys was upgraded, but only OS not version of vault itself
13:44:59 sean-k-mooney ya thats odd. i wonder if tehere was a bug fix wehre we did nto store some metadata or similar that we require to be able to do the attach
13:45:17 sean-k-mooney i.e. a bug that affected volumes created in teh older relase that nolonger happens in the later release
13:45:22 JohnnyW openstack secret get ... are able to return all payload, for "new" and "old" secret, so that's why it looks strange. Only nova seems to have an issue with reading keys, let say old volumes which are already mounted and old are OK right now, but after reattachment I'm sure that problem with old keys will be visible
13:45:30 sean-k-mooney have you compare the metadtaa on the volume or attachment info
13:46:39 JohnnyW hmm...let me try to compare metadata or attachment info, maybe that is a good hint, I haven't tried to compare it yet
13:55:50 opendevreview Merged openstack/nova-specs master: Clarify client changes in rebuild spec https://review.opendev.org/c/openstack/nova-specs/+/856164
14:07:19 JohnnyW sean-k-mooney unfortunately or fortunately it's not up to metadata or attachment info, I already change on both sides to have similar and issue is the same. Logs from nova-compute says: https://paste.openstack.org/show/bNbPOHiQJOq8OsKZ5Gn2/
14:27:41 sean-k-mooney ya so i have not see that issue before so i cant really say. it would be good to file a bug for this as it likely is an upstream bug but im not sure of the cause
15:27:46 sean-k-mooney JohnnyW: by the way today is a spec review day so most of the cores will be focused on that so if no one else chims in bring it up tomorrow and it might get more attention
15:32:00 bauzas reminder: nova meeting in ~30 mins
15:47:15 JohnnyW sean-k-mooney ok, thank you very much, already posted a bug here: https://bugs.launchpad.net/nova/+bug/1996622 and hope that everything is placed there
16:00:19 bauzas #startmeeting nova
16:00:19 opendevmeet Meeting started Tue Nov 15 16:00:19 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 opendevmeet The meeting name has been set to 'nova'
16:00:33 bauzas howdy everyone
16:00:45 dansmith o/ (but multitasking)
16:00:52 elodilles o/
16:00:57 Uggla o/
16:00:58 bauzas dansmith: ditto
16:01:03 bauzas #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:01:03 gmann o/
16:01:07 gibi o/
16:01:12 bauzas let's try to have a quick meeting
16:01:12 sean-k-mooney o/
16:01:14 Kirill_ 0/
16:01:24 bauzas #topic Bugs (stuck/critical)
16:01:29 bauzas #info No Critical bug
16:01:34 bauzas #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 7 new untriaged bugs (+2 since the last meeting)
16:01:40 bauzas #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:01:56 bauzas melwitt: I've seen you triaging bugs, anything in particular you wanted to discuss ?
16:03:20 bauzas looks not, moving on
16:03:31 bauzas Uggla: happy with getting the baton this week ?
16:03:39 Uggla bauzas, ok
16:03:41 bauzas artom is on some PTO until dec
16:03:45 bauzas cool
16:03:51 bauzas #info bug baton is being passed to Uggla
16:03:55 bauzas moving on
16:04:00 bauzas #topic Gate status
16:04:06 bauzas #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:04:11 bauzas #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:04:22 bauzas we had a terrible week
16:04:37 bauzas yellows and reds everywhere
16:04:48 gibi I think it was a global CI outage
16:04:50 gibi at some point
16:04:55 bauzas yup
16:05:25 bauzas since all the runs happened on the same timeframe, this would explain
16:05:56 bauzas we shall check the statuses next week

Earlier   Later