| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 18:31:14 | dansmith | gmann: exactly | |
| 18:31:36 | dansmith | btw, | |
| 18:32:04 | dansmith | I thought at one point we were supposed to get the ability for neutron to say "here's the user's token for context, and here's my token for auth" | |
| 18:32:18 | sean-k-mooney | right but the network-vif-pluged event for example is sent when but the dhcp server has configured the enttry for the ip and the l2 agent has installed flow rules ectra. so it has to create the token form a config file | |
| 18:32:23 | sean-k-mooney | it cannot use the user token | |
| 18:32:26 | dansmith | so we could scope to the user's project from their token, but elevate the ability to do systemy things with the service's token | |
| 18:32:49 | lbragstad | i think there is a policy check for that? | |
| 18:32:53 | dansmith | sean-k-mooney: it doesn't have to use the user's token | |
| 18:33:47 | dansmith | sean-k-mooney: are you saying it doesn't know anything about the project that owns the port? | |
| 18:33:53 | dansmith | because all it needs is the project_id | |
| 18:34:07 | sean-k-mooney | no the port has a project_id assocatied with it | |
| 18:34:30 | dansmith | right, so it can use an admin token generated from creds from the conf, scoped to that project yeah? | |
| 18:34:34 | sean-k-mooney | but the xproejct_override work that lbragstad has been workign on only works with system tokens | |
| 18:34:44 | dansmith | fine? | |
| 18:35:28 | sean-k-mooney | so its a system admin toke with the project_id also set which is what we started with | |
| 18:35:42 | sean-k-mooney | your just saying the project_id should come form the port | |
| 18:35:48 | sean-k-mooney | not be hardcoded in the config | |
| 18:35:49 | dansmith | what we started with was the assertion that it *has* to be that way | |
| 18:35:54 | dansmith | actuall,y | |
| 18:36:08 | dansmith | I think what we started with was "let's discuss this high-bandwidth at ptg" which is *really* what I'd like | |
| 18:38:44 | sean-k-mooney | ok sure. although this is the second deiscussion i have had on this topic as i started talking to lbragstad about it a few weeks ago | |
| 18:39:36 | dansmith | yeah, clearly he needs to be in said high-bandwidth discussion | |
| 18:39:45 | sean-k-mooney | so i was strating form an assumtion that the neutron config would have the creds for a system scoped token and possibly use the project override mechanium | |
| 18:40:24 | sean-k-mooney | im totally fine with and actully like the idea that neutron would overried the project_id with the ide of the port or network owner | |
| 18:40:48 | lbragstad | override == use the project id pass-through functinality? | |
| 18:41:01 | sean-k-mooney | but we woudl need code change to neutron to do that. today the best we can do via the config would be a system_admin token | |
| 18:41:07 | sean-k-mooney | lbragstad: yes | |
| 18:41:21 | sean-k-mooney | project_id passtough is what i mean by overried | |
| 18:41:55 | hemna | can you boot an instance on behalf of another tenant (as admin) ? | |
| 18:42:05 | sean-k-mooney | lbragstad: neutron currently uses the same nova client to send all external events to nova https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py#L84-L91 | |
| 18:43:33 | sean-k-mooney | hemna: as in server create no | |
| 18:43:38 | lbragstad | yeah - i hit that issue when i configured nova to enforce scope and worked on the project-id passthrough functionality in ksa and ksm | |
| 18:43:41 | sean-k-mooney | hemna:you can start a server | |
| 18:43:51 | hemna | ok dang. thanks | |
| 18:44:32 | sean-k-mooney | lbragstad: neutron also batchs sending events today | |
| 18:44:50 | sean-k-mooney | so i think they reuse the client for multiple events for diffeenr resouces | |
| 18:45:03 | lbragstad | ok - so that's the PUT portion of that API, right? | |
| 18:45:43 | sean-k-mooney | its a post but yes https://docs.openstack.org/api-ref/compute/#create-external-events-os-server-external-events | |
| 18:46:29 | dansmith | sean-k-mooney: they never batched before, are you sure? | |
| 18:46:49 | lbragstad | ok - nevermind, i thought i saw that API expose a PUT method | |
| 18:46:50 | sean-k-mooney | https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py#L146 | |
| 18:46:53 | dansmith | sean-k-mooney: or do you mean batches of ports for a single instance? | |
| 18:46:54 | sean-k-mooney | dansmith: ^ | |
| 18:47:36 | dansmith | okay I thought you said you didn't know the interface was intended for batches? :) | |
| 18:47:58 | dansmith | pretty sure that's new (since I last looked) because I was surprised how long after the interface was written that it was still doing singles | |
| 18:48:32 | dansmith | oh, this is network-changed I think | |
| 18:48:56 | sean-k-mooney | this was network changed yes | |
| 18:49:06 | lbragstad | ok - and the goal is to continue allowing this stuff work to work without having to refactor neutron to use system-scope? | |
| 18:49:12 | dansmith | ack, I would have been looking at vif-plugged | |
| 18:50:17 | dansmith | (which looks to be single-shot) | |
| 18:50:31 | dansmith | lbragstad: I don't think that's a goal | |
| 18:50:50 | dansmith | lbragstad: my intent on arguing here is about declaring this API as forever system-scope-only | |
| 18:51:36 | dansmith | I don't really care if neutron uses system scope for its actions here, although I think providing a project_id is a good idea so we're only hitting instances for that project in a given post | |
| 18:52:45 | lbragstad | oh - ok | |
| 18:53:02 | lbragstad | so your concern is more that we're using a really big hammer to only interact with project resources | |
| 18:53:16 | gmann | and it can be default to project-member (owner), project-admin is not needed as such | |
| 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 | |