| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 16:51:05 | dansmith | yes, I would really like to do this via voice | |
| 16:51:05 | sean-k-mooney | and just fix the bug to fail eailer untile ^ | |
| 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 | sean-k-mooney | but the project in the contex would be the one that was specifed | |
| 16:58:25 | dansmith | assuming you mean "auditing" :) | |
| 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: tests: Add functional test for vDPA device https://review.opendev.org/c/openstack/nova/+/780112 | |
| 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: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 | |
| 18:43:48 | sean-k-mooney | in the DB we will have rows of dev_type='type-PF' and dev_type='vdpa' | |
| 18:44:06 | sean-k-mooney | stephenfin: yep but we dont have VFs in the db | |
| 18:45:08 | stephenfin | Yeah, I know. Again, I'm not creating PciDevice objects here | |
| 18:45:21 | stephenfin | that's just generating libvirt XML for a number of VFs | |
| 18:45:23 | stephenfin | which we do have | |
| 18:45:32 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/770533/12/nova/virt/libvirt/host.py#1236 | |
| 18:45:41 | stephenfin | e.g. 1 PF, 4 VFS, and 1 vDPA dev per VF | |
| 18:45:59 | sean-k-mooney | is this generating the nodedev xmls | |
| 18:46:04 | stephenfin | yes | |
| 18:46:22 | stephenfin | and then we let the libvirt driver generate the PciDevice objects | |
| 18:46:32 | sean-k-mooney | ok so not the data rutrined by _get_pcidev_info or the PciDevice objects | |
| 18:46:36 | stephenfin | no | |
| 18:47:05 | stephenfin | so I'd expect to see see five devices in the database | |
| 18:47:14 | stephenfin | one with type-PF, because I'm whitelisting that | |
| 18:47:18 | stephenfin | and four with 'vdpa' | |
| 18:47:21 | sean-k-mooney | yes | |
| 18:47:38 | stephenfin | we can expand the test to verify that if you like. That would be a good addition | |
| 18:47:55 | sean-k-mooney | no i just want to fiture out how to reuse | |