| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-14 | |||
| 19:47:26 | sean-k-mooney | so service only woudl be be the end state we woudl like | |
| 19:47:31 | gmann | yeah | |
| 19:47:55 | dansmith | sean-k-mooney: he's asking about placement | |
| 19:47:59 | sean-k-mooney | im fine with service only by the way if its behind the new default falg | |
| 19:48:04 | sean-k-mooney | oh placment | |
| 19:48:34 | sean-k-mooney | thats a more interesting case | |
| 19:49:09 | sean-k-mooney | im kind fo conflicted | |
| 19:49:56 | sean-k-mooney | on one hand it would be nice to be able to use placment standalone but if we ignore that usecase | |
| 19:50:44 | sean-k-mooney | the allcoations endpoint proaably shoudl be service only however we would stant nova-manage heal allcotions to still work | |
| 19:51:02 | sean-k-mooney | perhaps readonly access for admin | |
| 19:51:39 | sean-k-mooney | i dont know. admin-or-service could be applied ot all the admin apis as a first step but i dont knwo if we want to prevent an admin form doing some things | |
| 19:52:45 | sean-k-mooney | like im tempeted to say the rp and invetory create/update apis shoudl be service only but we allow admins to add traits via the api or tweak the allcoation ratios | |
| 19:53:25 | sean-k-mooney | the reshape api proably shoudl be service only but im not sure any others fall into that | |
| 19:53:31 | sean-k-mooney | usecase | |
| 19:54:49 | dansmith | admins deleting stale allocations though... | |
| 19:55:13 | dansmith | yeah, reshape can be service only I think | |
| 19:55:14 | sean-k-mooney | without using the nova-manage command? | |
| 19:55:39 | dansmith | I think since placement isn't as user-facing it might make sense to just leave it as admin-or-service | |
| 19:55:44 | dansmith | at least focus on other stuff | |
| 19:55:44 | sean-k-mooney | i think s/admin/admin-or-owner/ for everythign other then reshape | |
| 19:56:05 | dansmith | admin or service you mean? | |
| 19:56:05 | gmann | yeah, that is what i was thinking to leave them as admin-or-service | |
| 19:56:15 | sean-k-mooney | sorry admin-or-service | |
| 19:56:17 | sean-k-mooney | yes | |
| 19:56:23 | dansmith | I assume that when you do things through nova-manage we still use the environment's creds, not the service ones right? | |
| 19:56:40 | sean-k-mooney | i think nova manage uses the creds in the nova.conf | |
| 19:57:03 | sean-k-mooney | i have never actully check however but i always tought it got them form there | |
| 19:57:12 | dansmith | hmm, it just means you might have to have nova.conf and service creds on your workstation if that's where you fix things from | |
| 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. | |