| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-06-06 | |||
| 16:39:58 | dansmith | bauzas: a client can poll (or long poll) but that's much less efficient | |
| 16:39:59 | gibi | yeah I will pull out some specific use case and try to limit the scope to something very simple on our side | |
| 16:40:04 | dansmith | especially when instance actions could be days apart | |
| 16:40:21 | bauzas | but yeah, someone could provide some tool that would listen to the notification bus and scramples all the admin-only data | |
| 16:40:29 | gibi | bauzas: exactly | |
| 16:40:39 | bauzas | sorry, by client I meant something unrelated to nova | |
| 16:40:45 | sean-k-mooney | so the way to do this in the past was ceilometer put the relevetn events in AODH | |
| 16:40:51 | dansmith | they could, but that's basically re-constructing the tenant isolation that nova already has, so it's a big new surface to secure and new services to run | |
| 16:40:54 | sean-k-mooney | and then you woudl set up alarms on the events you cared about | |
| 16:41:15 | dansmith | sean-k-mooney: that's all intended to be operator-focused, not for users to get status/events on their instances right? | |
| 16:41:27 | sean-k-mooney | no | |
| 16:41:34 | gibi | if they only need a trigger to re-read the instance action API then most of of the data can be hidden from our notifications | |
| 16:41:39 | sean-k-mooney | aodh and celoimeter provided user facing events/metrics | |
| 16:41:51 | dansmith | okay I didn't realize | |
| 16:41:52 | bauzas | yeah | |
| 16:41:53 | sean-k-mooney | they didnt actully expose the full notificaiton | |
| 16:42:01 | bauzas | ceilometer was the fit | |
| 16:42:04 | sean-k-mooney | jsut instance boot started and instance boot finsined events | |
| 16:42:19 | bauzas | and that's why we never had this in nova | |
| 16:42:27 | dansmith | honestly, I feel like this is probably something nova can/should be doing | |
| 16:42:40 | dansmith | nowadays this is how stuff plugs together | |
| 16:42:51 | sean-k-mooney | ya i think its something we coudl do | |
| 16:42:56 | sean-k-mooney | but we need to think about how | |
| 16:42:58 | dansmith | making an external tool reconstruct what we already know is kinda :/ | |
| 16:43:18 | gibi | yeah | |
| 16:43:24 | dansmith | it could be a service like console that you run if you want, and scale separately to handle the amoun tof load you want to tolerate | |
| 16:43:31 | bauzas | dansmith: I'm still struggling to find how we would ensure the tenancy isolation by the message bus, but I'm open to ideas | |
| 16:43:45 | bauzas | unless we create a bus per tenant | |
| 16:43:46 | sean-k-mooney | if its in nova | |
| 16:43:47 | dansmith | bauzas: we wouldn't? | |
| 16:43:48 | sean-k-mooney | we can just filter | |
| 16:44:36 | bauzas | I'm maybe misunderstanding the proposal, but I thought we were about saying that we may emit project-related notifications | |
| 16:44:46 | dansmith | not at the rabbit level | |
| 16:44:51 | dansmith | let's let gibi collect some data, | |
| 16:44:59 | dansmith | and then we probably need a high-bandwidth conversation about options | |
| 16:45:01 | gibi | bauzas: we def need to understand their use case better | |
| 16:45:02 | bauzas | dansmith: ah ok | |
| 16:45:18 | bauzas | dansmith: then we need to construct some HTTP/2 layer with keystone auth | |
| 16:45:33 | bauzas | or something like that | |
| 16:45:38 | dansmith | bauzas: not necessarily | |
| 16:45:56 | dansmith | it just depends.. but it should be HTTP-something, either an event stream or callbacks | |
| 16:46:07 | sean-k-mooney | you would do somethign like "openstack project event subsribe (instnace.action.)*" which woudl return a websock url that would only stream the relevent events for the current project based on the keystone token | |
| 16:46:27 | dansmith | yep, could be something like that | |
| 16:46:38 | bauzas | sounds very console-ish | |
| 16:46:40 | sean-k-mooney | so like the console you woudl first create it and then get a handel for where to collect the data | |
| 16:46:42 | bauzas | but okay | |
| 16:46:44 | gibi | I can simplify it down to give me a server uuid and I stream you data about notifications affecting the server, but only with very limited data provided | |
| 16:46:58 | dansmith | bauzas: exactly.. it's the same sort of arrangement, and the same target audience | |
| 16:47:38 | bauzas | ok, then it sounds we have an agreement on the direction, let's not overpaper the technical details | |
| 16:47:42 | sean-k-mooney | and if its a seperate binary nova-event-proxy | |
| 16:47:53 | dansmith | gibi: yeah I just don't think you should need 100 websockets you have to read from if you have 100 instances in your wordpress deployment | |
| 16:47:58 | dansmith | sean-k-mooney: right | |
| 16:48:02 | sean-k-mooney | then its scalablity and wether its deployed is up ot the operator | |
| 16:48:07 | dansmith | yup | |
| 16:48:10 | gibi | dansmith: ahh true, we can do it pre project then | |
| 16:48:13 | gibi | per | |
| 16:48:18 | bauzas | yeah, devil is in the details of the productization | |
| 16:48:21 | dansmith | gibi: or even server group | |
| 16:48:42 | sean-k-mooney | anyway lets see what they actully bring up | |
| 16:48:42 | bauzas | gibi: honestly, the granularity sounds per project to me | |
| 16:48:53 | sean-k-mooney | and see if this type of solution would work for them or not | |
| 16:48:57 | dansmith | well, nfv people are all one project in some cases, so that probably won't work for them | |
| 16:49:01 | bauzas | gibi: are you done with this topic now that we drafted a solution for you ? :D | |
| 16:49:11 | gibi | I'm done | |
| 16:49:15 | bauzas | cool | |
| 16:49:16 | gibi | thanks for the discussion\ | |
| 16:49:22 | gibi | I will link this to the etherpad | |
| 16:49:27 | gibi | and I will report back from the summit | |
| 16:49:27 | bauzas | cool | |
| 16:49:37 | bauzas | I'll be back watching you at the Summit anyway | |
| 16:49:51 | bauzas | so if you promise too many things, I could yell :p | |
| 16:49:58 | gibi | bauzas: please do so | |
| 16:49:59 | gibi | :D | |
| 16:50:12 | gibi | I don't need another 3 years of "notification" work | |
| 16:50:22 | dansmith | heh | |
| 16:50:28 | dansmith | still got scars eh/ | |
| 16:50:30 | bauzas | ok, I was balancing the idea to paperwork the scaphandre and manila series but I'm exhausted of today | |
| 16:50:54 | bauzas | so, let's skip it and pretend it will be discussed in two weeks from now | |
| 16:51:01 | gibi | dansmith: time makes all these memory nicer and nicer actaully | |
| 16:51:06 | dansmith | heh | |
| 16:51:18 | gibi | so bauzas' has a good point watching me :) | |
| 16:51:32 | dansmith | gibi: https://www.youtube.com/watch?v=dLjNzwEULG8 | |
| 16:51:48 | bauzas | gibi: you're fortunate, canadians don't open carry | |
| 16:52:05 | bauzas | sorry, was a terrible joke :) | |
| 16:52:16 | gibi | dansmith: I need to check this out after the meeting :) | |
| 16:52:20 | bauzas | anyway, I think we're done for today | |
| 16:52:29 | gibi | indeed | |
| 16:52:40 | bauzas | thanks all | |
| 16:52:45 | bauzas | and thanks gibi for the chair | |
| 16:52:50 | bauzas | #endmeeting | |
| 16:52:50 | opendevmeet | Meeting ended Tue Jun 6 16:52:50 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:52:50 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-06-16.00.html | |
| 16:52:50 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-06-16.00.txt | |
| 16:52:50 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-06-16.00.log.html | |
| 16:53:02 | bauzas | gibi: there you go, you have your logs :p | |
| 16:54:11 | gibi | thank | |
| 16:54:25 | gibi | and it was the moment when my connection dropped first | |
| 16:54:34 | gibi | so it was not that flaky after all | |
| 16:55:13 | dansmith | are we canceling the nova meeting next week? | |
| 16:55:27 | bauzas | dansmith: damn shit, forgot to tell it | |