| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 16:41:07 | gmann | yeah but then we lose the concept of system vs project in nova ight? at least if we end up asking giving project token a sysmte role | |
| 16:41:09 | dansmith | because then if I'm going to try to audit "who shut down my instance" and I query for a project matching that ID, there is no project, right? | |
| 16:41:15 | sean-k-mooney | its really jsut a sting as proposed today | |
| 16:41:26 | sean-k-mooney | the porject would also need to have the same string in there policy right | |
| 16:41:53 | sean-k-mooney | e.g. we would have to tag all the compute apis as part of the compute system | |
| 16:41:55 | lbragstad | today - the system scope policies don't understand that concept, but neither does keystone | |
| 16:42:06 | gmann | yeah | |
| 16:42:13 | lbragstad | again - i'm talking way down the road | |
| 16:42:56 | lbragstad | but it might be important before we get to that point and realize projects are using system by overloading it with project information | |
| 16:43:41 | lbragstad | dansmith yeah - in that case, you'd need to query the projects and service | |
| 16:43:49 | lbragstad | services* | |
| 16:44:11 | dansmith | lbragstad: well, we call it a project_id, so you just "need to know" that it could be either right? | |
| 16:44:40 | gmann | dansmith: sean-k-mooney why we cannot remove the project_id = context.project_id from here ? https://github.com/openstack/nova/blob/ab07507e5cfce6232fef373d07ff92ea704541da/nova/objects/instance_action.py#L60 | |
| 16:45:03 | lbragstad | yeah - so you're saying it could be an actual project_id or a service_id (assuming all that work actually happens in keystone) | |
| 16:45:03 | gmann | at least that will allow action APIs to eb operable form system and keep project_id in instance same as old | |
| 16:45:08 | dansmith | gmann: we have to do it everywhere | |
| 16:45:17 | dansmith | gmann: and, it hides who did the thing | |
| 16:45:20 | gmann | yeah, that is some work we have to do | |
| 16:45:45 | dansmith | gmann: that object is for auditing, and if we just lie about who shut down your instance, that's... like, bad and stuff? :) | |
| 16:46:39 | gmann | dansmith: we can add some specific field of shut_down_by= and 'system admin' if system admin does | |
| 16:46:54 | dansmith | gmann: -2 on that :) | |
| 16:47:19 | dansmith | all of this comes because we have project-scoped resources, and now we have this user that is in "no project" | |
| 16:47:20 | gmann | i mean at some stage we have to consume system admin info in resources DB or so | |
| 16:47:32 | lbragstad | would nova be opposed to a mutually exclusive group for project_id|system_id? | |
| 16:47:33 | dansmith | which is why I think we shouldn't allow you to act on project-scoped resources with out.. some sort of project scope :) | |
| 16:48:12 | gmann | but that shrink the system token use. | |
| 16:48:20 | gmann | or the overall purpose | |
| 16:48:51 | dansmith | why not just give all system admins a single project? we can still use the system-admin part to authorize, but then we have a project_id to account for things | |
| 16:49:51 | gmann | i will say system_id we should add and then do context.project_id or context.system_id | |
| 16:50:00 | gmann | or mutual exclusive as lbragstad mentioned before | |
| 16:50:46 | sean-k-mooney | i think we need 1 coffee 2 a whiteborad or virtual alternitve and 3 verbal realtime comunication | |
| 16:51:05 | sean-k-mooney | and just fix the bug to fail eailer untile ^ | |
| 16:51:05 | dansmith | yes, I would really like to do this via voice | |
| 16:51:20 | gmann | yeah, +1 on voice call | |
| 16:52:18 | sean-k-mooney | i think the main issue is what keysotn is provideign via this mechanim is not how i woudl expect RBAC to work from other systems i have looked at | |
| 16:52:52 | lbragstad | sean-k-mooney can you give me some example references for how you expect this to work? i'd like to dig into those | |
| 16:54:12 | sean-k-mooney | im not sure i can directly. i was more thinkin of a set of scope privalge delegations rather then 3 indipened types of tokens | |
| 16:55:00 | sean-k-mooney | e.g. i was still expectin git to be possibel to create a singel system token that could be used like the old admin role | |
| 16:55:19 | sean-k-mooney | but that cant be done as far as i can see | |
| 16:55:28 | dansmith | so in kerberos, | |
| 16:55:47 | dansmith | I can use my same account to get a token, an admin token, and I think a token in any group I have access to right? | |
| 16:55:56 | dansmith | it's been a long time for me, but..I think that's right | |
| 16:55:59 | sean-k-mooney | by the way i was thinking of my litel experince with oath2 | |
| 16:56:23 | sean-k-mooney | dansmith: i think so an di was expecting to be able to do something similar | |
| 16:56:35 | dansmith | I would expect that if I have sysadmin powers, I should be able to effectively newgrp my way into any project to make a request as that project, without having to add myself to that project | |
| 16:56:44 | dansmith | sean-k-mooney: right, that's how this should work IMHO | |
| 16:56:57 | dansmith | don't act like you have no affiliation, just allow system admins to have any affiliation they want that makes sense | |
| 16:57:21 | sean-k-mooney | basicaly i was hopeing for an "openstack token issue -type project -id <whatever>" | |
| 16:57:31 | dansmith | EXACTLY | |
| 16:57:38 | dansmith | EFFING EXACTLY what I've been trying to say | |
| 16:58:07 | sean-k-mooney | then my user would still be me for audinging | |
| 16:58:14 | dansmith | EFFING EXACTLY | |
| 16:58:25 | dansmith | assuming you mean "auditing" :) | |
| 16:58:25 | sean-k-mooney | but the project in the contex would be the one that was specifed | |
| 16:58:29 | dansmith | right | |
| 16:58:31 | sean-k-mooney | hehe yes | |
| 16:58:39 | sean-k-mooney | seanspeak is flexible | |
| 16:58:53 | elod | lyarwood: thank you both for checking the release patches and backporting your gate fixing patch! \o/ | |
| 16:58:54 | gmann | but how you handle for multiple project token issue needed | |
| 16:58:55 | dansmith | and I left my decoder ring in the other room | |
| 16:59:22 | dansmith | gmann: not sure what you mean.. when do you ever do one thing as two projects? | |
| 16:59:52 | gmann | i mean as system admin i want multiple project resource to operate | |
| 17:00:15 | sean-k-mooney | in one api call? | |
| 17:00:29 | gmann | no independent | |
| 17:00:33 | lbragstad | gmann like listing all instances in a deployment? | |
| 17:00:41 | dansmith | lbragstad: no that's different | |
| 17:00:51 | gmann | and without storing or passing projct_id in request | |
| 17:00:56 | sean-k-mooney | that we can support directly with a system_admin token | |
| 17:01:01 | dansmith | gmann: you get a token before each call, just like you would in unix: newgrp teamA; do thing; newgrp teamB; do thing | |
| 17:01:03 | gmann | hummm, i think let's do voice call | |
| 17:01:44 | dansmith | ++ voice call :) | |
| 17:02:01 | sean-k-mooney | lbragstad: anyway i hope you see where i was coming form | |
| 17:02:15 | sean-k-mooney | better go work on the last vdpa patch | |
| 17:02:42 | lbragstad | sean-k-mooney yep - i think i get the general idea | |
| 17:06:58 | gmann | dansmith: sean-k-mooney lbragstad added this in ptg etherpad too (L213)- https://etherpad.opendev.org/p/nova-xena-ptg | |
| 17:07:32 | gmann | when we can have voice call before ptg? | |
| 17:08:17 | sean-k-mooney | i would suggest not until after RC1 | |
| 17:09:01 | gmann | sure, | |
| 17:12:30 | dansmith | yep, a pre-call would be good | |
| 17:12:34 | dansmith | post-RC1 seems good | |
| 17:18:03 | lyarwood | elod: np :) | |
| 17:18:13 | lyarwood | elod: thanks for sorting the releases out | |
| 17:21:07 | lyarwood | gmann: https://review.opendev.org/c/openstack/tempest/+/775630 - would you mind hitting this to unblock https://review.opendev.org/c/openstack/nova/+/708701 | |
| 17:25:44 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: tests: Make mdev stubs work like vDPA https://review.opendev.org/c/openstack/nova/+/780234 | |
| 17:25:44 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Add functional test for vDPA device https://review.opendev.org/c/openstack/nova/+/780112 | |
| 17:26:26 | stephenfin | gibi: Thanks for the review. That should be good to go now ^ | |
| 17:29:37 | gmann | lyarwood: sure checking | |
| 17:33:07 | lyarwood | gmann: thanks | |
| 17:34:59 | gmann | lyarwood: +A | |
| 17:42:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Document UEFI secure boot feature https://review.opendev.org/c/openstack/nova/+/776684 | |
| 17:43:26 | stephenfin | melwitt: lyarwood: Collective nits addressed ^ | |
| 17:48:08 | lyarwood | stephenfin: ack LGTM | |
| 17:48:13 | stephenfin | thanks | |
| 17:50:12 | kashyap | stephenfin: How come emulated-tpm.rst got touched? | |
| 17:50:37 | kashyap | This bit https://review.opendev.org/c/openstack/nova/+/776684/9/doc/source/admin/emulated-tpm.rst#b41 | |
| 17:51:20 | stephenfin | kashyap: I copied the "show me the trait" snippet from that for the secure boot guide and both lyarwood and melwitt suggested changes to it, so it made sense to fix the original source also | |
| 17:51:41 | stephenfin | *suggested changes to the secure boot variant of the snippet | |
| 17:52:05 | kashyap | stephenfin: Ah, right; just now caught up w/ Mel's comments | |
| 17:52:28 | kashyap | stephenfin: Fair enough. I just rubbing my eyes twice to see if I something else | |
| 17:52:36 | kashyap | s/just/was/ | |