| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-14 | |||
| 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 | sean-k-mooney | so i kind of assume we did the same for placment | |
| 19:58:17 | dansmith | well, db creds are different | |
| 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 | bauzas | just checking if the file was modified | |
| 10:07:39 | gibi | bauzas: ack, go for it | |
| 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] | 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: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: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 | 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: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 | 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: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 | |