| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 18:54:16 | dansmith | gmann: the actual policy rule default I'm not so concerned about | |
| 18:54:36 | dansmith | I think we could probably set that rule to default to "scope:system and role:admin" or whatever, | |
| 18:54:50 | dansmith | but I just don't want that to be a constant | |
| 18:55:00 | sean-k-mooney | gmann: im not sure we really want normaly project_member to be able to call it by default | |
| 18:55:16 | frickler | sean-k-mooney: those instances are not from a job but I created them manually, so I can do further debugging as needed. "xml generated by nova" is what I can see with "virsh dumpxml"? or do I need to get it from the logs? | |
| 18:55:19 | sean-k-mooney | at least for how it work today | |
| 18:55:52 | dansmith | gmann: by the way, what do you see as being the avenue if we change the allowed scopes in the future for an interface? | |
| 18:56:02 | gmann | or I am thinking if adding new scope 'service_scope' can help in making those API to cross-service based interaction-only. | |
| 18:56:13 | dansmith | meaning, what if something is scope_types=['system'] and we add project to that? how do we signal or microversion that? | |
| 18:56:54 | gmann | dansmith: not microversion but only in releasenotes as it change the configuration only. like we do for every policy change | |
| 18:56:57 | sean-k-mooney | frickler: i was thinking if from the logs | |
| 18:57:17 | sean-k-mooney | frickler: nova prints the xml we send to libvirt at debug level | |
| 18:57:42 | dansmith | gmann: but that won't always work right? like if we go from "you have to be project scoped" to "or you can be system scoped but with a projectid override".. certainly a client needs to know that the behavior has changed right? | |
| 18:57:51 | sean-k-mooney | frickler: we will need that xml if we want to have some of our libvirt folks look at the qemu output and node if its valide or not | |
| 18:58:34 | dansmith | gmann: because that's my concern here over deciding scope for this interface now and wanting to change it later, because it seems like it's something that will be very hard to change later without confusing behavior effects | |
| 18:58:44 | sean-k-mooney | gmann: chanign policy with out a microversion has always made me uncomfortable for what its worth | |
| 18:58:54 | dansmith | if something is fundamentally system-scoped, then fine, | |
| 18:59:03 | dansmith | but if it's not, then it's just adding a layer of potential breakage later | |
| 18:59:17 | dansmith | like I keep saying, aggregates are clearly system-scoped to me, but few other things are, IMHO | |
| 18:59:33 | gmann | dansmith: yes for 'project scope'->'system with project_id' is something we need to discuss if we need to add microvesion or not. with NOTE: new policies are not microversioned. | |
| 18:59:36 | dansmith | (or at least, I have few other examples that I think are legit) | |
| 18:59:42 | gmann | but supporting both for a release or so | |
| 19:00:00 | dansmith | gmann: welp, FWIW, that makes me rather nervous :/ | |
| 19:00:16 | dansmith | especially knowing that our customers don't run adjacent releases | |
| 19:00:22 | opendevreview | Lance Bragstad proposed openstack/nova master: DNM: Attempt to expose external events API to project users https://review.opendev.org/c/openstack/nova/+/812601 | |
| 19:00:22 | opendevreview | Lance Bragstad proposed openstack/nova master: DNM: Update external events policy to allow for project-id passthrough https://review.opendev.org/c/openstack/nova/+/812602 | |
| 19:00:23 | opendevreview | Lance Bragstad proposed openstack/nova master: DNM: Update policy to allow for service-specific auth targets https://review.opendev.org/c/openstack/nova/+/812603 | |
| 19:00:28 | lbragstad | dansmith cover your eyes - fstrings on the way | |
| 19:00:32 | sean-k-mooney | gmann: new policyes i can may see as not requiring a microverson. any change in default policy behaivor for any endpoint however i kind of feell like it should be a microversion | |
| 19:00:37 | dansmith | lbragstad: *shudder* | |
| 19:00:59 | gmann | sean-k-mooney: new policy are change in default behavior too | |
| 19:01:08 | dansmith | sean-k-mooney: policies can be changed by the operators, so I don't think that means they need microversions, | |
| 19:01:20 | sean-k-mooney | e.g. if add a new policy has no visable effect then fine but if it changes the behaivor in any way by default i think it needs a microversion | |
| 19:01:32 | dansmith | sean-k-mooney: but new core unchangeable policy things like "system-scope plus project id" are different to me | |
| 19:02:27 | sean-k-mooney | dansmith: i agree that operators can certly change policy and alter behavior and that does not affect the microversion today | |
| 19:02:33 | gmann | yeah "system-scope plus project id" is completely different new thing | |
| 19:02:41 | sean-k-mooney | but im not really sure where the line is | |
| 19:03:31 | sean-k-mooney | gmann: i might be missing something but im not really convicned it is | |
| 19:03:34 | dansmith | gmann: that's my concern over deciding the fate of this event api, FWIW | |
| 19:03:45 | sean-k-mooney | what makes that different then changing an api form project member to say project admin | |
| 19:03:47 | dansmith | sean-k-mooney: it is definitely a different thing to me | |
| 19:04:03 | dansmith | sean-k-mooney: it requires you know that the thing be new enough *and* that you need a different client behavior to make it work | |
| 19:04:08 | dansmith | neither of which are discoverable from the outside | |
| 19:04:24 | dansmith | sean-k-mooney: because of the client behavior change required | |
| 19:04:57 | sean-k-mooney | is there not a client behaivor change requried with enabling scope enforce too | |
| 19:04:57 | gmann | sean-k-mooney: project member to say project admin, operator can always change it back via policy.yaml | |
| 19:04:59 | lbragstad | https://review.opendev.org/c/openstack/nova/+/812601/1/nova/policies/server_external_events.py would be example of how to expose this to project users | |
| 19:05:31 | lbragstad | but https://review.opendev.org/c/openstack/nova/+/812602/1/nova/policies/server_external_events.py would be using project id pass-through | |
| 19:05:57 | dansmith | sean-k-mooney: yep, that's definitely a change in line with the one described above, but less concerning than just a single policy change to use a different role I think | |
| 19:06:05 | sean-k-mooney | lbragstad: thats assuming we standardise an new service role? or does that already exist | |
| 19:06:27 | lbragstad | it's not standardized - just an example | |
| 19:07:10 | dansmith | lbragstad: yeah, the second is my preference | |
| 19:07:13 | sean-k-mooney | the resaond i was asking is the idea of a service role is a new construct to me adn would have to be standarised i think if we were to use it in code | |
| 19:07:39 | gmann | dansmith: added sysmte+project-id case in PTG etherpad L227 | |
| 19:07:41 | dansmith | lbragstad: and then perhaps we limit it per event, so to say "we know neutron uses system scope, so we're limiting network-* events to system scoped contexts to avoid users being able to send those" | |
| 19:07:46 | dansmith | gmann: thanks | |
| 19:07:58 | sean-k-mooney | the second i think is just the system_amdin_or_owner policy right | |
| 19:08:09 | dansmith | sean-k-mooney: no | |
| 19:08:20 | dansmith | sean-k-mooney: it's system scope WITH a project override, or a regular project token | |
| 19:08:26 | gmann | yeah | |
| 19:08:35 | sean-k-mooney | sorry not admin or owner | |
| 19:08:47 | sean-k-mooney | ok | |
| 19:08:49 | lbragstad | dansmith yeah - if nova can pack that as target data - you could do something like role:service and networking:%(event_type)s | |
| 19:08:52 | sean-k-mooney | ya i see the differnce | |
| 19:08:52 | dansmith | also, lbragstad I'm fine with the policy not allowing regular users to hit the API until/unless we have a human-oriented event | |
| 19:08:59 | dansmith | lbragstad: because it's just a default | |
| 19:09:11 | dansmith | lbragstad: oh we could do that too I guess | |
| 19:09:27 | dansmith | lbragstad: I don't think we apply the policy like that today, but we could | |
| 19:09:43 | gmann | but that need policies per event | |
| 19:09:44 | dansmith | lbragstad: I was thinking more like hard-coded python to check the scope after we look at the event type | |
| 19:09:53 | dansmith | gmann: right, I like it less, but it's an option | |
| 19:10:09 | lbragstad | o.p should generalize the target data | |
| 19:10:20 | lbragstad | s/should generalize/generalizes/ | |
| 19:10:43 | lbragstad | i'm not sure if it supports regular expressions though | |
| 19:10:53 | dansmith | I dunno what your point is | |
| 19:10:58 | gmann | dansmith: lbragstad oh or we can make check_str with OR-per-event and like what lbragstad mentioned | |
| 19:11:02 | dansmith | I'm saying I think there's something to be said for it not being in the actual rule | |
| 19:11:16 | frickler | sean-k-mooney: https://paste.opendev.org/show/809803/ , I can also give you or others access to the held nodes if you want to have a look yourselves | |
| 19:11:34 | gmann | so single policy, check str with event_x AND project OR event_y AND system | |
| 19:11:41 | dansmith | tbh, I think some of these overly complex policy rules are asking for admins to get confused, write a policy wrong and break or expose something they don't expect | |
| 19:11:46 | lbragstad | yeah - i was just throwing it out there as an option if you wanted a way to restrict some users from posting networking events | |
| 19:11:54 | dansmith | which makes me wonder if putting this in the policy rule is the right thing, but.. it's an option and I don't totally hate it | |
| 19:12:04 | dansmith | lbragstad: ack | |
| 19:12:29 | lbragstad | otherwise - if you consider it business logic, putting it in the service itself makes sense | |
| 19:12:42 | sean-k-mooney | frickler: so in both cases the nova generated xml is more or less identical as we woudl expect meanign any delta in behavior is a libvirt bug | |
| 19:12:46 | dansmith | yeah, "unless the admin could/would need to change it, put it in code" | |
| 19:13:23 | sean-k-mooney | frickler: we are simplely setting the memory with <memory>262144</memory> we are not speficying any of the advance memory backing config | |
| 19:13:45 | dansmith | lbragstad: another question: would it be rude for me to say I'm officially burned out on policy stuff for like at least 24 hours? | |
| 19:13:57 | lbragstad | join the club | |
| 19:14:01 | dansmith | haha | |
| 19:14:02 | lbragstad | :) | |
| 19:14:20 | lbragstad | it's only tuesday, too | |
| 19:14:35 | dansmith | I know, I was going to say "for the week" but realized there's a lot of week left :/ | |
| 19:15:02 | sean-k-mooney | well i for one am planning on not thining about this until the ptg | |
| 19:15:16 | dansmith | sean-k-mooney: I think you are a LIAR | |
| 19:15:19 | sean-k-mooney | lbragstad: that said im going to try and re review the latest version of your ooo changes | |
| 19:16:03 | lbragstad | every time i try *not* thinking about policy, i think about policy | |
| 19:16:19 | sean-k-mooney | dansmith: :) i still find our approch to policy to be very very non intuitive | |
| 19:16:35 | dansmith | sean-k-mooney: you just proved me right! | |
| 19:18:23 | lbragstad | going out on a limb here, but if a sub-system takes 5 years to change, it's probably more than just non-intuitive :) | |