| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-06-06 | |||
| 16:24:18 | bauzas | so lemme add his points | |
| 16:24:31 | bauzas | #info stable gates should be OK (from stable/2023.1 to stable/train) | |
| 16:24:37 | bauzas | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:24:42 | bauzas | huzzah for this | |
| 16:24:51 | bauzas | and my point | |
| 16:24:57 | bauzas | #info train-eol patch proposed https://review.opendev.org/c/openstack/releases/+/885365 | |
| 16:25:10 | bauzas | I'd appreciate if nova-cores could comment it ^ | |
| 16:25:19 | dansmith | I will | |
| 16:25:31 | dansmith | I noticed the cinder people are taking a more aggressive approach | |
| 16:25:40 | bauzas | gibi: okay, then -1 my patch and I'll modify it to await for your backport merge | |
| 16:25:47 | bauzas | dansmith: yup, saw it too | |
| 16:25:53 | gibi | bauzas: I think I'm OK to drop that backport | |
| 16:26:05 | gibi | I did that to see if the patch works | |
| 16:26:12 | bauzas | gibi: as you want, just tell me your insights in the train-eol patch | |
| 16:26:18 | gibi | ack | |
| 16:26:44 | bauzas | dansmith: fwiw I'm afraid of EOLing the whole EM branches | |
| 16:27:09 | dansmith | shrug.. my argument for train applies to all the EM ones too | |
| 16:27:16 | dansmith | maybe we wait and see how it goes for cinder ;) | |
| 16:27:38 | bauzas | but since we haven't backported the os-brick CVE fix in Ussuri and Victoria, I could understand | |
| 16:28:01 | bauzas | but yeah, let's see what it's happening for cinder :D | |
| 16:28:26 | bauzas | anyway, moving on | |
| 16:28:35 | bauzas | #topic Open discussion | |
| 16:28:45 | bauzas | none in the agenda | |
| 16:28:54 | bauzas | anything that someone wants to tell ? | |
| 16:30:01 | gibi | one thing | |
| 16:30:05 | bauzas | shoto | |
| 16:30:11 | bauzas | shoot even | |
| 16:30:34 | gibi | there was a request for opinion about openstack on k8s | |
| 16:30:40 | gibi | let me find the link | |
| 16:30:55 | sean-k-mooney | its a thing that people do | |
| 16:31:36 | bauzas | okidoki, let's wait | |
| 16:32:15 | gibi | 13:01 < mdbooth> I'll be running a forum session on Kubernetes on OpenStack in Vancouver next week. It's for users and developers of all related projects to talk to each other. Etherpad is here if there's anything you'd like to discuss: https://etherpad.opendev.org/p/openinfra-2023-kubernetes-on-openstack | |
| 16:32:20 | gibi | 13:01 < mdbooth> I'll be running a forum session on Kubernetes on OpenStack in Vancouver next week. It's for users and developers of all related projects to talk to each other. Etherpad is here if there's anything you'd like to discuss: https://etherpad.opendev.org/p/openinfra-2023-kubernetes-on-openstack | |
| 16:32:30 | gibi | sorry for the duplicate | |
| 16:32:47 | sean-k-mooney | im wondering why mdboot is runnign that session but ok | |
| 16:32:51 | dansmith | that's k8s on openstack not what you said right? | |
| 16:32:57 | gibi | sorry I mixed up | |
| 16:32:59 | sean-k-mooney | that k8s on openstack | |
| 16:33:01 | sean-k-mooney | ya | |
| 16:33:05 | bauzas | ok, so lemme add the link | |
| 16:33:17 | sean-k-mooney | that makes more sense why mdbooth is involved | |
| 16:33:26 | bauzas | #link https://etherpad.opendev.org/p/openinfra-2023-kubernetes-on-openstack OpenInfra Forum session for discussing about k8s on openstack | |
| 16:33:37 | bauzas | gibi: the other way btw. :) | |
| 16:33:41 | gibi | there is some nova related question in the etherpad | |
| 16:34:24 | gibi | about getting notified if anything changed with servers | |
| 16:34:30 | gibi | I offered the nova notification inteface | |
| 16:34:35 | bauzas | yeah and it's a public API :) | |
| 16:34:38 | gibi | but apperantly they want something public | |
| 16:34:58 | gibi | the API is documented but the message bus access then to be non public | |
| 16:34:58 | sean-k-mooney | the notifcation are the only interface we have currently | |
| 16:35:03 | bauzas | since someone worked on notifications objects like 6 years ago (guess who :p ) | |
| 16:35:14 | gibi | bauzas: hah :D | |
| 16:35:24 | bauzas | gibi: are you sure that the message bus can't be public ? | |
| 16:35:33 | dansmith | it shouldn't be | |
| 16:35:39 | gibi | yeah | |
| 16:35:43 | dansmith | we have instance events.. that's what they want I think | |
| 16:35:48 | sean-k-mooney | the notification bus is semi privladged | |
| 16:35:50 | gibi | and our notifications tend to contain infra information | |
| 16:35:52 | dansmith | I think they just need an async way to get those | |
| 16:35:58 | sean-k-mooney | the notifications can have private infor in them | |
| 16:36:02 | sean-k-mooney | depening on what you configure | |
| 16:36:04 | sean-k-mooney | like the bdms | |
| 16:36:30 | gibi | yeah, bottom line the notification API is designed for consumed by admins or other openstack service not endusers | |
| 16:36:43 | dansmith | right, it would leak bad things between tenants for sure | |
| 16:36:43 | bauzas | ah they want it to be consumable by endusers ? | |
| 16:36:47 | dansmith | not just infra things | |
| 16:36:52 | gibi | yeah | |
| 16:36:58 | bauzas | urth | |
| 16:37:01 | sean-k-mooney | you could have a multi tentant service that converts the notificaton in to a webhook callback or similar | |
| 16:37:01 | bauzas | urgh | |
| 16:37:09 | dansmith | instance events/actions is the right thing I think, it's just only polling currently | |
| 16:37:13 | sean-k-mooney | but that still not greate | |
| 16:37:28 | sean-k-mooney | dansmith: ya the event stream would work but im not sure that | |
| 16:37:37 | gibi | yeah, a websocket around instance actions wouldbe nice | |
| 16:37:41 | sean-k-mooney | even if it was event based they woud lwant ot liste per instance | |
| 16:37:53 | sean-k-mooney | more liek open a websocket and get all instance events for a project? | |
| 16:38:09 | dansmith | they probably want to be able to register a handler with a scope (one instance, all my instances) that lives for a period of time that we call when there's a new event | |
| 16:38:14 | sean-k-mooney | or that you are allowed to see based on teh scope of the keystone token | |
| 16:38:17 | bauzas | I think everytime someone asks us to monitor some instance action, we tell them 'lookup the notifications' | |
| 16:38:25 | bauzas | but this is for admin usage | |
| 16:38:29 | dansmith | websocket will require a lot of standby resources that I think would be hard for us to manage | |
| 16:38:45 | dansmith | anyway, | |
| 16:38:45 | gibi | true | |
| 16:38:58 | bauzas | so, they want some enduser public subscription mechanism for asynchronously being notified on my instance state changes ? | |
| 16:39:00 | dansmith | not sure how many people will be there to make any sort of headway on that topic, since I think those people are likely here :) | |
| 16:39:11 | dansmith | bauzas: yeah | |
| 16:39:24 | bauzas | sounds a client thing to mre | |
| 16:39:26 | bauzas | me | |
| 16:39:31 | gibi | dansmith: I will be there hence collecting ideas here now :) | |
| 16:39:32 | sean-k-mooney | lets see if they acan at least expand on the usecases | |
| 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? | |