Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-06-06
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
16:55:43 bauzas unless people wanna run it, which I'm cool wiht
16:56:29 geguileo dansmith: sean-k-mooney last week I mentioned the os-brick idempotency and we talked about reconstructing the disk XML on some operations. I've just opened a bug (#2023078) where Nova is not rebuilding the disk XML after block migration. Don't know nova enough to know if this would be fixed with the changes to the os-brick idempotency thingy.
16:57:14 sean-k-mooney the xml for live migration is built on the souce node based on info passed back form the destination host
16:57:22 sean-k-mooney for cold migration it build on the dest host
16:57:52 sean-k-mooney i assume you are refering to live-migration local block devices?
16:57:58 geguileo sean-k-mooney: the XML after live migration is wrong
16:58:18 sean-k-mooney that xml must be generated on the source host
16:58:20 geguileo sean-k-mooney: it doesn't have the right discard=unmap value even when the destination is saying that it is supported
16:58:38 sean-k-mooney is it enabeld on the source
16:59:11 geguileo sean-k-mooney: but if the source didn't support it and now it does? Then it cannot be supported until reboot?
16:59:28 geguileo Because then I think Cinder should start reporting that everything supports discard...
16:59:57 sean-k-mooney geguileo: correct
17:00:12 sean-k-mooney so this is not somethign that should be chnaging durign a live migrate

Earlier   Later