| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 16:21:20 | bauzas | dansmith: thanks | |
| 16:21:25 | gibi | thanks | |
| 16:21:29 | bauzas | I also need to look at the goals candidates | |
| 16:21:38 | bauzas | (if we have some of them already) | |
| 16:22:03 | dansmith | rbac, I think, at least | |
| 16:22:07 | dansmith | should be uncontentious | |
| 16:22:12 | dansmith | but the session doesn't mention specific | |
| 16:22:15 | dansmith | *specifics | |
| 16:22:46 | bauzas | I'd appreciate if we could exactly define the needed efforts for rbac into our project | |
| 16:22:57 | bauzas | but I'll take a look | |
| 16:23:19 | bauzas | one thing I wanted to stress on, | |
| 16:23:22 | bauzas | we're missing at the moment cinder, neutron and keystone cross-project discussions | |
| 16:23:22 | sean-k-mooney | i think most of the rbac effrort will be with interacting with other project | |
| 16:23:27 | artom | I thought we were done with rbac? | |
| 16:23:42 | sean-k-mooney | e.g. making sure we can call neutron with system scopted tokens | |
| 16:23:43 | dansmith | artom: we're done getting ready for rbac :) | |
| 16:23:53 | bauzas | artom: sean-k-mooney: maybe, that's why I want to exactly know the key objectives for this proposed goal | |
| 16:24:27 | artom | dansmith, right, I meant Nova is read, other projects aren't yet, hence the custom policy "workaround" that's currently up for review | |
| 16:24:29 | artom | *ready | |
| 16:24:43 | dansmith | artom: ready, but not completed, AIUI | |
| 16:24:46 | bauzas | me too | |
| 16:24:48 | sean-k-mooney | nova can be called with the secure rbac | |
| 16:25:02 | sean-k-mooney | that does not mean it can call other project properly with it | |
| 16:25:08 | sean-k-mooney | or that they can call nova with it | |
| 16:25:22 | dansmith | can you manage aggregates with a non-project-scoped admin token? | |
| 16:25:38 | bauzas | we need at least some CI job running | |
| 16:25:38 | sean-k-mooney | proably not | |
| 16:25:50 | dansmith | and my next question was, if so, is it tested? :) | |
| 16:25:50 | bauzas | to identify the potential gaps | |
| 16:25:52 | sean-k-mooney | bauzas: yes that is part of the scope of the goal | |
| 16:25:56 | gibi | also we have the specify-target-host-with-project-admin issue open | |
| 16:26:15 | sean-k-mooney | so likely we have work to do | |
| 16:26:17 | dansmith | gibi: yeah, so beyond "meh, it probably works" I expect there are lots of corner cases like that | |
| 16:26:22 | bauzas | gibi: correct, hence my "we need to understand the goal's objectives" | |
| 16:26:23 | gibi | exactly | |
| 16:26:35 | dansmith | hence, I said "done getting ready" :) | |
| 16:26:39 | gibi | :) | |
| 16:26:41 | bauzas | lol | |
| 16:26:53 | bauzas | ok, I think we're done with that for now :) | |
| 16:26:54 | gibi | we are ready to do the _real_ work :D | |
| 16:26:56 | sean-k-mooney | we can discuss more at the ptg but i think it would be nice if we aimed to have a RBAC job running by m1 | |
| 16:27:12 | sean-k-mooney | to give use time to fix the issue it will find | |
| 16:27:28 | artom | Can we do a nova-only job for that? | |
| 16:27:35 | artom | I keep hearing it's "all or nothing" | |
| 16:27:36 | gibi | sean-k-mooney: I'm not even sure tempest is ready to add RBAC testing | |
| 16:27:46 | dansmith | gibi: I think it is | |
| 16:27:48 | sean-k-mooney | lance has been working on some limited testing | |
| 16:27:54 | gibi | ahh OK | |
| 16:27:54 | artom | Actually, do we even need tempest? | |
| 16:27:55 | sean-k-mooney | with tempest | |
| 16:28:00 | sean-k-mooney | artom: yes we do | |
| 16:28:02 | dansmith | gibi: glance is testing it with its tempest plugin | |
| 16:28:03 | artom | Smells like something we can do in functional tests, no? | |
| 16:28:09 | dansmith | but it's much easier to test glance in isolation than nova | |
| 16:28:09 | sean-k-mooney | artom: no | |
| 16:28:13 | gibi | dansmith: cool, so we have an example | |
| 16:28:17 | sean-k-mooney | we need to test interservice interaction | |
| 16:28:18 | dansmith | definitely need tempest, IMHO | |
| 16:28:26 | bauzas | oh yes | |
| 16:28:28 | dansmith | functional will definitely not cut it | |
| 16:28:30 | sean-k-mooney | lances intiall testing show we cant boot with a neutron port | |
| 16:28:37 | bauzas | can't see how we could achieve this without tempest | |
| 16:28:49 | sean-k-mooney | because neturon as configured by devstack at lest currently cant send the network plugged event correctly | |
| 16:29:01 | dansmith | sean-k-mooney: is that their fault or ours? | |
| 16:29:03 | sean-k-mooney | so we definetly need to do tempeest integration testing | |
| 16:29:14 | dansmith | seems like it's likely ours | |
| 16:29:15 | bauzas | we need a job | |
| 16:29:19 | sean-k-mooney | dansmith: not sure yet proably a mix of devstack config and our policy | |
| 16:29:32 | dansmith | or maybe a combo I guess. if they use a system-scoped token but need to augment with project maybe | |
| 16:29:34 | dansmith | sean-k-mooney: ack | |
| 16:29:48 | bauzas | and first and foremost, we need people working on it, if so :) | |
| 16:29:52 | sean-k-mooney | i think it enabeld the new policy on our side but did not create the nova user with the right scope and neutron config | |
| 16:30:27 | dansmith | sean-k-mooney: honestly, I probably need to think on how that event interface should work | |
| 16:30:27 | sean-k-mooney | so we enforced scope but the token neutron used did not have system scope but was an admin token | |
| 16:30:40 | dansmith | like maybe a system-scoped token that looks up any instance on the system is okay | |
| 16:31:02 | dansmith | I would normally think that should be project-scoped, because instances are project-scoped and events are tied to instances | |
| 16:31:11 | dansmith | but it's intended to mostly be used by other services, so .. I dunno | |
| 16:31:22 | sean-k-mooney | i think it should be system scope | |
| 16:31:27 | bauzas | do we have sort of guidance from the keystone team about those events ? | |
| 16:31:33 | sean-k-mooney | becasue as you said this is for service to service interaction | |
| 16:31:38 | sean-k-mooney | but ya its tricky | |
| 16:31:39 | bauzas | or is it us just picking what we want ? | |
| 16:31:48 | dansmith | sean-k-mooney: but it's not something you can ever do without a project-scoped resource ... | |
| 16:31:56 | dansmith | bauzas: we should probably consult a bit | |
| 16:32:10 | sean-k-mooney | dansmith: yep which is why its tricky | |
| 16:32:20 | dansmith | this is kinda my problem with system scope, is that it actually doesn't apply to a lot of stuff, because almost everything is a project-scoped resource | |
| 16:32:21 | artom | Can ports ever be system-scope? | |
| 16:32:35 | artom | Instances are obviously project-scope, but Neutron external events have to do with ports as well | |
| 16:32:38 | sean-k-mooney | im a little relucted to say that api should be project-admin however | |
| 16:32:39 | bauzas | if that becomes a goal, we need some owner of this goal, just sayin' :) | |
| 16:32:43 | dansmith | aggregates are the one example of a system-scoped resource I use a lot | |
| 16:32:49 | artom | Is there some funky network topology that can have system-scoped ports? | |
| 16:32:56 | dansmith | sean-k-mooney: that's another thing, definitely doesn't need admin | |
| 16:32:57 | sean-k-mooney | dansmith: it proably shoudl be system-admin with project-ide set | |
| 16:33:13 | dansmith | sean-k-mooney: that's project-scoped, AFAIK | |
| 16:33:20 | dansmith | events don | |
| 16:33:24 | dansmith | don't need to be admin either | |
| 16:33:33 | sean-k-mooney | the event api is admin only | |
| 16:33:48 | dansmith | they don't need to be, and I don't think they initially were | |
| 16:33:49 | sean-k-mooney | since enduser including operators are not ment to call it | |