Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-11-14
19:57:22 dansmith using regular creds would make more sense to me
19:57:36 sean-k-mooney i dont think we supprot clouds.yaml with nova-mange
19:57:44 sean-k-mooney i can check quickly i guess
19:58:00 sean-k-mooney i assuemd the config sicne we get the db creds form the config
19:58:17 dansmith well, db creds are different
19:58:17 sean-k-mooney so i kind of assume we did the same for placment
19:58:20 dansmith but yeah I dunno I guess
19:58:57 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L2356-L2360
19:59:08 sean-k-mooney so we get the admin context and then use the placment client
19:59:39 sean-k-mooney so given this is reusing or normal placment code i woudl think its using the config
19:59:46 dansmith that's pretty terrible for audit logging
20:00:05 dansmith "a system did this automatically" is what any action by service roles should look like, but it was actually a human
20:00:25 sean-k-mooney perhaps at least it would show as the nova user but your right that you would not be able to tell nova-compute vs nova-mange aprart
20:00:55 sean-k-mooney but what that means is if nova-comptue can work with the placment policy then nova-manage should too
20:01:31 dansmith it's not that you can't tell the services apart,
20:01:41 dansmith it's that you can't tell services from humans
20:02:10 dansmith which is generally why you don't share passwords among humans, but often do among services
20:02:18 sean-k-mooney ya
20:02:29 dansmith anyway, if we use a service account in nova-manage, then those cases could be service-only for the moment,
20:02:38 dansmith I just don't know that it matters as much as other things
20:03:00 sean-k-mooney although there is noting to stop a rouge admin form just using the nova user and password in the cloud.yaml but your more concerned with the fact nova-mange does not allow you to do anything else
20:04:05 dansmith I'm just concerned about the audit logging for the non-rogue-admin case
20:04:51 sean-k-mooney ya so im not really sure that easy to fix
20:05:20 sean-k-mooney out of scope of gmann's specs in any case but we have some clint singoltons in use
20:06:01 sean-k-mooney if we want to share the code between nova-manage and the rest of nova im not sure how easy it woudl be to enable you to use creds form clouds.yaml
20:06:07 dansmith definitely out of scope
20:06:31 dansmith I'm just *also* saying that placement remaining admin-or-service while we focus elsewhere seems fine, without having to even have this argument :)
20:06:50 sean-k-mooney hehe ya im fine with that too
20:07:06 sean-k-mooney the usage api need to remain project_reader
20:07:16 sean-k-mooney but the rest can be admin-or-service for now
20:07:42 gmann ack. thanks
20:08:39 sean-k-mooney dansmith: i got sidetracked with downstream stuff today but ill update the fqdn sepc in my morning
21:03:24 opendevreview Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379
21:05:18 opendevreview Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379
21:05:49 gmann dansmith: ^^ updated
#openstack-nova - 2022-11-15
02:18:30 opendevreview Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864275
08:24:59 bauzas happy Specs review day, folks
08:37:37 gibi o/
09:45:55 gibi one done https://review.opendev.org/c/openstack/nova-specs/+/855514 many to go
09:55:14 gibi sean-k-mooney: do we need https://review.opendev.org/c/openstack/nova-specs/+/850352 or https://review.opendev.org/c/openstack/nova-specs/+/862626 will cover this as well?
09:58:44 sean-k-mooney[m] oh i can abandon that the new spec will cover it. i need to adress the capitalisation and spelling nits from dan
09:58:56 sean-k-mooney[m] but ill be doning that shortly
09:58:58 gibi sean-k-mooney: cool, then lets abadon the old one
09:59:50 sean-k-mooney[m] done
10:03:45 gibi thanks!
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

Earlier   Later