| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 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/ | |
| 18:20:19 | openstackgerrit | Merged openstack/nova master: apidb: Compact Stein database migrations https://review.opendev.org/c/openstack/nova/+/759406 | |
| 18:21:41 | openstackgerrit | Merged openstack/nova master: pci: implement the 'socket' NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779 | |
| 18:22:31 | artom | \o/ | |
| 18:38:42 | sean-k-mooney | oh finally | |
| 18:41:14 | sean-k-mooney | stephenfin: why are you creating device of dev_type='VF' | |
| 18:41:16 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/780112/4/nova/tests/functional/libvirt/test_pci_sriov_servers.py#738 | |
| 18:42:08 | stephenfin | cos each vDPA device is associated with a VF? | |
| 18:42:13 | sean-k-mooney | for a start that should be dev_type='type-VF' no if you wanted VFs but in this case it should be dev_type='VDPA' | |
| 18:42:41 | stephenfin | no, that's not creating a PciDevice object | |
| 18:42:46 | stephenfin | that's creating fake libvirt xml | |
| 18:42:47 | sean-k-mooney | right | |
| 18:42:58 | sean-k-mooney | we dont have VF object for the VDPA devices | |
| 18:43:41 | stephenfin | each vdpa device has a '<parent>' element | |