| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-14 | |||
| 16:14:55 | opendevreview | ribaudr proposed openstack/nova-specs master: Allow local scaphandre directory to be mapped to an instance using virtiofs https://review.opendev.org/c/openstack/nova-specs/+/861881 | |
| 19:33:21 | gmann | dansmith: can you review these specs related to RBAC (service role for nova and dropping system scope for placement) https://review.opendev.org/c/openstack/nova-specs/+/864379 https://review.opendev.org/c/openstack/placement/+/864385 | |
| 19:34:21 | gmann | dansmith: also can you help to understand placement APIs, they should be consider as internal APIs or external? I am considering later and not proposing service role to them | |
| 19:41:56 | dansmith | gmann: hmm, well, | |
| 19:42:07 | dansmith | we kinda want people to use placement for some things, mostly admin-related though | |
| 19:42:18 | dansmith | but it's very much internal other than that | |
| 19:42:34 | dansmith | nova should use an account with the service role to talk to placement I think | |
| 19:43:26 | gmann | dansmith: so we need to keep policy open for admin-or-service role. or there are few APIs we can keep only service role ? | |
| 19:44:35 | dansmith | gmann: we probably need to review.. the problem is that when something goes wrong, an admin deleting a stale allocation or something can be required, | |
| 19:44:50 | dansmith | and even things like allocation candidates can be useful for admins | |
| 19:45:14 | dansmith | so yeah I think probably admin-or-service for much of it probably makes sense, but we should probably review all the rules to be sure | |
| 19:45:52 | sean-k-mooney | so admin-or-service makes sense for things like the external events api | |
| 19:46:05 | sean-k-mooney | but things like the host-aggrates api should be admin only | |
| 19:46:28 | gmann | ok, I think spec is ok then and we can review every rule while doing code change | |
| 19:46:33 | sean-k-mooney | the os-assisated-volume-extend api would also be admin-or-service | |
| 19:46:54 | gmann | sean-k-mooney: we are making them as service role only - this is for nova https://review.opendev.org/c/openstack/nova-specs/+/864379 | |
| 19:47:14 | sean-k-mooney | service only would work but it has an upgrade impact | |
| 19:47:22 | gmann | I think I covered all internal APIs there but if anything missing please comment | |
| 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 | |