| opendevreview | Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379 | 03:35 |
|---|---|---|
| opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864274 | 03:51 |
| opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864274 | 03:53 |
| opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864275 | 03:56 |
| opendevreview | Ghanshyam proposed openstack/placement master: Policy defaults improvement spec https://review.opendev.org/c/openstack/placement/+/864385 | 05:19 |
| Uggla | Good morning nova | 08:45 |
| sahid | o/ | 08:59 |
| sahid | sean-k-mooney, bauzas anything missing regarding evacuate feature? do you think you will be able to have look on it for this release? | 09:00 |
| sahid | feel free to let me know if i can be helpful on anything | 09:05 |
| gibi | o/ | 09:32 |
| bauzas | sahid: I'll look at your spec tomorrow | 09:59 |
| * bauzas is thrown under a loaded bus today | 09:59 | |
| sahid | cool thank you bauzas | 10:02 |
| bauzas | sahid: as a reminder, we'll have our spec review day tomorrow, so just make sure to look at the new comments tomorrow afternoon if you can | 10:03 |
| sahid_ | bauzas: sure ACK | 10:49 |
| opendevreview | Takashi Natsume proposed openstack/nova master: Add a hacking rule for the setDaemon method https://review.opendev.org/c/openstack/nova/+/854653 | 13:04 |
| *** dasm|off is now known as dasm | 14:46 | |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673 | 15:19 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976 | 15:19 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Deprecate mdev creation and hardfail on reboot when missing. https://review.opendev.org/c/openstack/nova/+/864418 | 15:19 |
| 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 | 15:38 |
| 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 | 16:14 |
| 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:33 |
| 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:34 |
| dansmith | gmann: hmm, well, | 19:41 |
| dansmith | we kinda want people to use placement for some things, mostly admin-related though | 19:42 |
| dansmith | but it's very much internal other than that | 19:42 |
| dansmith | nova should use an account with the service role to talk to placement I think | 19:42 |
| 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:43 |
| 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 |
| dansmith | and even things like allocation candidates can be useful for admins | 19:44 |
| 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 |
| sean-k-mooney | so admin-or-service makes sense for things like the external events api | 19:45 |
| sean-k-mooney | but things like the host-aggrates api should be admin only | 19:46 |
| gmann | ok, I think spec is ok then and we can review every rule while doing code change | 19:46 |
| sean-k-mooney | the os-assisated-volume-extend api would also be admin-or-service | 19:46 |
| 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:46 |
| sean-k-mooney | service only would work but it has an upgrade impact | 19:47 |
| gmann | I think I covered all internal APIs there but if anything missing please comment | 19:47 |
| sean-k-mooney | so service only woudl be be the end state we woudl like | 19:47 |
| gmann | yeah | 19:47 |
| dansmith | sean-k-mooney: he's asking about placement | 19:47 |
| sean-k-mooney | im fine with service only by the way if its behind the new default falg | 19:47 |
| sean-k-mooney | oh placment | 19:48 |
| sean-k-mooney | thats a more interesting case | 19:48 |
| sean-k-mooney | im kind fo conflicted | 19:49 |
| sean-k-mooney | on one hand it would be nice to be able to use placment standalone but if we ignore that usecase | 19:49 |
| sean-k-mooney | the allcoations endpoint proaably shoudl be service only however we would stant nova-manage heal allcotions to still work | 19:50 |
| sean-k-mooney | perhaps readonly access for admin | 19:51 |
| 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:51 |
| 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:52 |
| sean-k-mooney | the reshape api proably shoudl be service only but im not sure any others fall into that | 19:53 |
| sean-k-mooney | usecase | 19:53 |
| dansmith | admins deleting stale allocations though... | 19:54 |
| dansmith | yeah, reshape can be service only I think | 19:55 |
| sean-k-mooney | without using the nova-manage command? | 19:55 |
| dansmith | I think since placement isn't as user-facing it might make sense to just leave it as admin-or-service | 19:55 |
| dansmith | at least focus on other stuff | 19:55 |
| sean-k-mooney | i think s/admin/admin-or-owner/ for everythign other then reshape | 19:55 |
| dansmith | admin or service you mean? | 19:56 |
| gmann | yeah, that is what i was thinking to leave them as admin-or-service | 19:56 |
| sean-k-mooney | sorry admin-or-service | 19:56 |
| sean-k-mooney | yes | 19:56 |
| 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 |
| sean-k-mooney | i think nova manage uses the creds in the nova.conf | 19:56 |
| sean-k-mooney | i have never actully check however but i always tought it got them form there | 19:57 |
| 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 |
| dansmith | using regular creds would make more sense to me | 19:57 |
| sean-k-mooney | i dont think we supprot clouds.yaml with nova-mange | 19:57 |
| sean-k-mooney | i can check quickly i guess | 19:57 |
| sean-k-mooney | i assuemd the config sicne we get the db creds form the config | 19:58 |
| dansmith | well, db creds are different | 19:58 |
| sean-k-mooney | so i kind of assume we did the same for placment | 19:58 |
| dansmith | but yeah I dunno I guess | 19:58 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L2356-L2360 | 19:58 |
| sean-k-mooney | so we get the admin context and then use the placment client | 19:59 |
| sean-k-mooney | so given this is reusing or normal placment code i woudl think its using the config | 19:59 |
| dansmith | that's pretty terrible for audit logging | 19:59 |
| dansmith | "a system did this automatically" is what any action by service roles should look like, but it was actually a human | 20:00 |
| 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 |
| sean-k-mooney | but what that means is if nova-comptue can work with the placment policy then nova-manage should too | 20:00 |
| dansmith | it's not that you can't tell the services apart, | 20:01 |
| dansmith | it's that you can't tell services from humans | 20:01 |
| dansmith | which is generally why you don't share passwords among humans, but often do among services | 20:02 |
| sean-k-mooney | ya | 20:02 |
| dansmith | anyway, if we use a service account in nova-manage, then those cases could be service-only for the moment, | 20:02 |
| dansmith | I just don't know that it matters as much as other things | 20:02 |
| 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:03 |
| dansmith | I'm just concerned about the audit logging for the non-rogue-admin case | 20:04 |
| sean-k-mooney | ya so im not really sure that easy to fix | 20:04 |
| sean-k-mooney | out of scope of gmann's specs in any case but we have some clint singoltons in use | 20:05 |
| 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 |
| dansmith | definitely out of scope | 20:06 |
| 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 |
| sean-k-mooney | hehe ya im fine with that too | 20:06 |
| sean-k-mooney | the usage api need to remain project_reader | 20:07 |
| sean-k-mooney | but the rest can be admin-or-service for now | 20:07 |
| gmann | ack. thanks | 20:07 |
| sean-k-mooney | dansmith: i got sidetracked with downstream stuff today but ill update the fqdn sepc in my morning | 20:08 |
| opendevreview | Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379 | 21:03 |
| opendevreview | Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379 | 21:05 |
| gmann | dansmith: ^^ updated | 21:05 |
| *** dasm is now known as dasm|off | 22:44 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!