| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 17:14:03 | sean-k-mooney | it looks too much like an estate and the sharp line remind me of the telsla pickup | |
| 17:15:28 | bauzas | I don't like the interior and the trunk is small | |
| 17:15:38 | bauzas | I tested it tho, nice to drive | |
| 17:15:47 | bauzas | the EV6 is on its way | |
| 17:15:55 | bauzas | but it costs nearly the TMY without the fun | |
| 17:16:15 | bauzas | and... that's a Kia | |
| 17:19:36 | sean-k-mooney | kia at least has a 7 year warrenty | |
| 17:20:26 | sean-k-mooney | i much prefer the ev6's styling but i dont need a car that size | |
| 17:21:27 | sean-k-mooney | im cosidering a peugeot e-208 but not sure i can justify the price gien how little i drive | |
| 17:22:23 | sean-k-mooney | the 6 speed petrol is about 5-7k cheaper for similar specs | |
| 17:22:50 | bauzas | sean-k-mooney: Sophie drives a e208 | |
| 17:23:15 | bauzas | we got a 7k€ incentive for buying it | |
| 17:23:39 | bauzas | so yeah, without this, I totally agree with you on the fact this is horribly expensive | |
| 17:26:34 | sean-k-mooney | does sophie like the e208 was it worht the investment | |
| 17:26:53 | sean-k-mooney | we can get part of the veical registration tax back and there is an ev grant too | |
| 17:27:27 | sean-k-mooney | but even with that factored in its still several grand more to get teh e versions | |
| 17:27:56 | bauzas | let's discuss this off this topic | |
| 17:28:10 | bauzas | tl;dr: yes she likes it | |
| 17:28:14 | sean-k-mooney | hehe sure :) | |
| 17:34:22 | dansmith | sean-k-mooney: you know that I *wrote* the external events API right? :) | |
| 17:43:46 | sean-k-mooney | dansmith: yes i do | |
| 17:43:59 | sean-k-mooney | i was adding that cotext for other reading it | |
| 17:44:21 | dansmith | sean-k-mooney: okay just trying not to be offended by you 'splaining what it was originally intended for on the etherpad :) | |
| 17:44:25 | dansmith | mkay | |
| 17:44:29 | sean-k-mooney | you orginally worte it for the dhcp server race when using quantum instead of nova network right | |
| 17:45:09 | sean-k-mooney | the reason i put the "must not be called by humans part is really the warnign we have in the api ref by the way" | |
| 17:45:58 | sean-k-mooney | mainly the last line | |
| 17:46:00 | sean-k-mooney | "Unless you are writing Neutron, Cinder or Ironic code you should not be using this API." | |
| 17:46:29 | dansmith | sean-k-mooney: yeah I know, and that's what is making me think maybe just saying that network-* events come only from system-scoped things, but I dunno | |
| 17:47:10 | sean-k-mooney | ya althoght we have had a usecase propsed int he past where an operator might want to send a network-changed event to referesh the network info cache | |
| 17:47:42 | dansmith | well, we used to have a dedicated API for that, but yes, that's kinda what I mean... those sorts of things | |
| 17:47:49 | sean-k-mooney | its an interesting problem. i dont think we have any other cases where we might want to very the policy based on a sub feild of the request body | |
| 17:48:06 | sean-k-mooney | in this case the event type | |
| 17:48:11 | dansmith | well, I think we can just manually enforce that in code | |
| 17:48:44 | dansmith | I dunno, I just don't want to call this system scope only and eliminate the possibility to use it for human-triggered things in the future | |
| 17:48:51 | sean-k-mooney | i dont think oslo policy can do this today so ya we would have to do it on the nova side | |
| 17:49:28 | sean-k-mooney | well if we assume it remaind amin only the the operator could create a system scoped token ot interact with it | |
| 17:49:40 | sean-k-mooney | but its not exactly a user freindly approch | |
| 17:50:13 | dansmith | but that's not necessarily always an admin thing | |
| 17:50:49 | gmann | default value or scope cannot by handle dynamically in oslo but yes a new policy enforcement based on request field can be added in code | |
| 17:51:00 | sean-k-mooney | this is one api that is currently not usable by nova client or osc by the way | |
| 17:51:07 | dansmith | I know | |
| 17:51:27 | sean-k-mooney | the reason i bring that up is i have wondered if we should close that gap in the past | |
| 17:51:52 | sean-k-mooney | but i have never actully looked at doing that since right now we have no usage that is human trigggered | |
| 17:52:39 | lbragstad | could you rewrite the policy to be service specific? | |
| 17:52:44 | lbragstad | instead of system-specific? | |
| 17:53:21 | sean-k-mooney | lbragstad: how woudl we tell which service called it? do you mean make ti depened on the event type | |
| 17:53:49 | gmann | is that mean the very original design of having multiple system and system_id in enforcement ? | |
| 17:54:03 | gmann | like system per service or so | |
| 17:54:03 | dansmith | sean-k-mooney: I think novaclient has an api for this, you just mean there's no CLI right? | |
| 17:54:20 | sean-k-mooney | dansmith: yes no cli but we likely have the python bindigns for it | |
| 17:54:26 | dansmith | yeah okay | |
| 17:54:40 | dansmith | no CLI makes sense while there's no CLI-able event I think | |
| 17:54:41 | sean-k-mooney | i would expect neutron to just deletagte to novaclinet internally | |
| 17:56:16 | lbragstad | sean-k-mooney does nova need to know which service called that API/ | |
| 17:56:29 | dansmith | no | |
| 17:56:40 | artom | Though currently only Neutron does, IIRC | |
| 17:56:47 | dansmith | it doesn't need to know that neutron only sends network events, but... that's kinda the point | |
| 17:56:49 | artom | And it's obvious that neutron does from the ebent name | |
| 17:57:03 | sean-k-mooney | artom: cinder and cyborg also call it | |
| 17:57:07 | dansmith | it's waiting for a thing, doesn't really need to know that neutron sent it, it just only really works if that's the case :) | |
| 17:57:27 | sean-k-mooney | artom: cinder for swap volume i think and cybrog for the arq binding completion | |
| 17:57:44 | artom | sean-k-mooney, I thought cinder swap volume was another "proper" API? | |
| 17:57:49 | artom | volume-update... | |
| 17:58:01 | sean-k-mooney | perhaps but there are cinder volume event | |
| 17:58:19 | sean-k-mooney | dansmith: so ya neutron is using cinder client https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py#L84-L91 | |
| 17:58:26 | sean-k-mooney | *novaclient | |
| 17:58:27 | artom | Yeah https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attachment-detail#update-a-volume-attachment | |
| 17:59:25 | sean-k-mooney | artom: it uses for volume extetnions not swap sorry | |
| 17:59:42 | artom | Anyways, we're off point here | |
| 18:00:02 | sean-k-mooney | artom: this is the list of events currently https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/objects/external_event.py#L18-L36 | |
| 18:00:11 | dansmith | currently neutron is using a project token to send these, | |
| 18:00:30 | artom | "power-update" is weird | |
| 18:00:35 | artom | When/how does that happen? | |
| 18:01:02 | dansmith | is that because that's the token and client that neutron uses to interact with nova or other things in a sensible way, or just because it has no knowledge that a system scoped token would be right? | |
| 18:01:07 | dansmith | artom: ironic, IIRC | |
| 18:01:17 | dansmith | artom: it's not just neutron :) | |
| 18:01:59 | lbragstad | yeah - i think it's using the nova service user, which has the admin role | |
| 18:02:15 | lbragstad | and we haven't really gone through that migration yet, from a policy perspective | |
| 18:03:47 | dansmith | lbragstad: meaning it's just naive and not like that user/client is project-scoped for other stuff? | |
| 18:05:06 | dansmith | even still, if neutron is sending an event for an instance or group of ports or something, having it be project-scoped in that call to the event thing also helps to prevent any missteps in sending events to other instances | |
| 18:05:23 | dansmith | like if there was some port change thing going on, during ownership transfer, or anything else | |
| 18:05:43 | dansmith | this goes back to my "the interface is specific to project-scoped resources, so it feels like it too should be project-scoped" | |
| 18:07:24 | lbragstad | iiuc - it's using the nova service user, which just happens to have the admin role (probably for legacy reasons) and that's why it works | |
| 18:07:52 | lbragstad | so - because the nova user has the 'admin' role on the service project, it can update external server events for instance 'foo' in project bar... | |
| 18:07:53 | dansmith | yeah, well the default policy makes the api admin-only anyway | |
| 18:08:57 | sean-k-mooney | yes so its relyin gon haveing a user with admin rights | |
| 18:09:13 | sean-k-mooney | that can be the nova user or a common service user | |
| 18:09:14 | lbragstad | correct - but it's not enforcing tenancy in any way - from what i can tell | |
| 18:09:33 | sean-k-mooney | i dont think it is either today | |
| 18:09:59 | sean-k-mooney | since this is mainly a service to service api | |
| 18:10:04 | dansmith | the api? | |
| 18:11:44 | dansmith | it uses the context to look up the instances it creates the events for, so it should be scoped to the project of the token | |
| 18:11:48 | sean-k-mooney | the external events api does not assert that the user that created teh event is a has any relationship with the project reosuce that is being modified | |
| 18:12:00 | dansmith | or I guess if you're admin then it lets you see them all, but it should still be tight if you're not admin | |
| 18:12:32 | dansmith | you won't be able to look up instances you don't have access to, and you'll fail with a 404 I think | |
| 18:12:58 | sean-k-mooney | well this has been admin only for as long as i can rememebr it exsiting | |
| 18:13:02 | dansmith | or just not send those events, I guess, I'm not sure, but.. | |
| 18:13:22 | dansmith | sean-k-mooney: by default you mean :) | |
| 18:13:31 | sean-k-mooney | yes by default | |