| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-11 | |||
| 16:03:20 | dansmith | sean-k-mooney: gmann: can we get this landed? | |
| 16:03:55 | dansmith | this makes us actually use a raw image for ceph like we're supposed to do, and also inflates it to the larger size | |
| 16:04:18 | dansmith | which already pressurized something that works fine with 16MB images (swap on the worker) | |
| 16:04:45 | dansmith | glance is planning a new locations API this cycle and I want to make sure we're testing that with a non-trivial-sized real image | |
| 16:05:58 | sean-k-mooney | dansmith: link? | |
| 16:06:09 | dansmith | lol paste fail | |
| 16:06:10 | dansmith | https://review.opendev.org/c/openstack/nova/+/860864 | |
| 16:18:12 | sean-k-mooney | ya that looks fine to me | |
| 17:30:37 | gmann | dansmith: +A, lgtm. i was waiting for devstack patch but ok with doing it in playbook itself | |
| 17:30:48 | dansmith | thanks | |
| 19:12:17 | opendevreview | Merged openstack/nova master: Test ceph-multistore with a real image https://review.opendev.org/c/openstack/nova/+/860864 | |
| #openstack-nova - 2022-11-12 | |||
| 06:12:48 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for qcow2 with LUKS https://review.opendev.org/c/openstack/nova/+/772273 | |
| #openstack-nova - 2022-11-14 | |||
| 03:35:35 | opendevreview | Ghanshyam proposed openstack/nova-specs master: Policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/864379 | |
| 03:51:09 | opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864274 | |
| 03:53:20 | opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864274 | |
| 03:56:52 | opendevreview | Jorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update https://review.opendev.org/c/openstack/nova/+/864275 | |
| 05:19:59 | opendevreview | Ghanshyam proposed openstack/placement master: Policy defaults improvement spec https://review.opendev.org/c/openstack/placement/+/864385 | |
| 08:45:31 | Uggla | Good morning nova | |
| 08:59:43 | sahid | o/ | |
| 09:00:46 | 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:05:52 | sahid | feel free to let me know if i can be helpful on anything | |
| 09:32:07 | gibi | o/ | |
| 09:59:19 | bauzas | sahid: I'll look at your spec tomorrow | |
| 10:02:41 | sahid | cool thank you bauzas | |
| 10:03:15 | 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:49:40 | sahid_ | bauzas: sure ACK | |
| 13:04:06 | opendevreview | Takashi Natsume proposed openstack/nova master: Add a hacking rule for the setDaemon method https://review.opendev.org/c/openstack/nova/+/854653 | |
| 15:19:49 | opendevreview | Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673 | |
| 15:19:49 | opendevreview | Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976 | |
| 15:19:50 | 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:38:47 | 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: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 | |