| *** bauzas_ is now known as bauzas | 03:44 | |
| *** bauzas_ is now known as bauzas | 04:09 | |
| *** bauzas_ is now known as bauzas | 04:22 | |
| *** bauzas_ is now known as bauzas | 05:27 | |
| hamidlotfi_ | Hi there, | 06:05 |
|---|---|---|
| hamidlotfi_ | An instance whose volume is on CEPH, after abnormally restarting the Compute server where that instance is located, that instance does not come up and displays the following error: | 06:05 |
| hamidlotfi_ | https://www.irccloud.com/pastebin/n5z4qgB7/ | 06:05 |
| hamidlotfi_ | I checked all of those values for the disk_cachemodes parameter, | 06:05 |
| hamidlotfi_ | network=directsync | 06:05 |
| hamidlotfi_ | network=none | 06:05 |
| hamidlotfi_ | network=writethrough | 06:05 |
| hamidlotfi_ | but in all of the values, the result is the same and I had that error. | 06:05 |
| *** elodilles_pto is now known as elodilles | 07:26 | |
| *** bauzas_ is now known as bauzas | 07:46 | |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: scheduler: fix _get_sharing_providers to support unlimited aggr https://review.opendev.org/c/openstack/nova/+/921665 | 08:09 |
| *** bauzas_ is now known as bauzas | 09:17 | |
| sean-k-mooney | gibi: can you review https://review.opendev.org/c/openstack/nova/+/710848 and the proceedign repoducer again | 11:16 |
| sean-k-mooney | when you have time of course but this has been arrond for a long time and if you agree i would like to back port that to stable branches | 11:17 |
| gibi | added to my queue | 12:09 |
| *** ykarel_ is now known as ykarel | 13:10 | |
| WJeffs | Hey, I might be being blind, but is there any options for Numa placement when allocating them to a VM. Say we have a HV with 8 numa groups across 2 cpus, and I want to allocate all the cores from 2 groups, thats no issue, but it gives me 1+6, but is there a way we can make it always use numa on same physical cpu at all times? | 13:15 |
| sean-k-mooney | WJeffs: form the same cpu package no. if you have a numa affined guest and ask for 2 numa nodes we will either pack or balance the vm across the numa node depenign on a config option | 13:59 |
| sean-k-mooney | WJeffs: in the past the beahvior was to pack leading to poor performance we now default to spreading | 13:59 |
| sean-k-mooney | WJeffs: we did have a request ot supprot socket level optimiations for amd cpus in the past | 14:00 |
| sean-k-mooney | but we have not had time to implemtn that | 14:00 |
| WJeffs | sean-k-mooney: ah it is for AMD Genoa, I guess that is the same part, we are already creating the numa configuration inside the VM and that works great and gives us good performance, now we are trying to test some extra configurations and found that the numas are spread across sockets | 15:00 |
| WJeffs | I'll have a look for the request/blueprint and see if there is anything we can do to help on this. | 15:01 |
| sean-k-mooney | WJeffs: this is basicaly all contolled by https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L2449-L2511 currently | 15:05 |
| sean-k-mooney | to do what you want we would need to add the socket info int the numa toplogy | 15:05 |
| sean-k-mooney | and then add an addtional sort here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L2481 | 15:06 |
| sean-k-mooney | to sort the nodes by socket | 15:06 |
| sean-k-mooney | sorry not there just below it https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L2488 | 15:07 |
| sean-k-mooney | the les is for pinned cpus | 15:07 |
| *** bauzas_ is now known as bauzas | 15:25 | |
| WJeffs | sean-k-mooney: Thanks, I'll take a look and see if there is something can do to help | 15:38 |
| sean-k-mooney | the main gap right now is we dont track the socket id in the host numa topogy data stucture | 15:40 |
| sean-k-mooney | or the numa distance btween numa ndoes | 15:40 |
| sean-k-mooney | since that really waht you want to minimise | 15:40 |
| sean-k-mooney | libvirt provide both we jsut dont collect it right now | 15:40 |
| WJeffs | yea, thats the main thing we are trying to do. So its collect from libvirt -> use that data that needs to be added. | 15:41 |
| sean-k-mooney | ya so artom looked at this brifly a year or two ago | 15:41 |
| sean-k-mooney | we have a downstream tracker in our backlog to eventually look at this https://issues.redhat.com/browse/OSPRH-36 | 15:42 |
| sean-k-mooney | but we jsut didnt have time or custoemr ask to priories it | 15:42 |
| artom | I even have/had WIP patches up, at some point | 15:42 |
| artom | Just the basics to collect those distance from libvirt | 15:42 |
| sean-k-mooney | https://review.opendev.org/q/topic:%22bp/libvirt-smarter-cpu-placement%22 | 15:42 |
| sean-k-mooney | yep ^ | 15:42 |
| sean-k-mooney | there in merge conflict but its proably pretty trivial | 15:43 |
| sean-k-mooney | this was the bluepritn https://blueprints.launchpad.net/nova/+spec/libvirt-smarter-cpu-placement | 15:43 |
| sean-k-mooney | btu not much detail there | 15:43 |
| WJeffs | ah wow, it was pretty close then, just come work to tidy up. | 15:44 |
| sean-k-mooney | tests, ensuring this works for live mirgation that sort of thing | 15:47 |
| WJeffs | appreciate all the hard work guys | 15:47 |
| sean-k-mooney | i dont recal exactly how far artom got but its a good starting point | 15:47 |
| artom | Those two patches are literally all I had. | 15:47 |
| artom | The hard part is integrating that into the placement of VMs | 15:48 |
| bauzas | nova meeting in 5 mins here | 15:55 |
| bauzas | I could be a bit lagging, don't be afraid | 15:55 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jun 11 16:00:22 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| gibi | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| fwiesel | \o | 16:01 |
| dansmith | o/ | 16:01 |
| auniyal | o/ | 16:01 |
| bauzas | my current time : | 16:01 |
| bauzas | 64 bytes from par21s19-in-f4.1e100.net (142.250.179.68): icmp_seq=27972 ttl=112 time=193 ms | 16:01 |
| bauzas | anyway, let's start | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:02 |
| bauzas | anything to discuss ? | 16:02 |
| bauzas | looks not | 16:03 |
| bauzas | #topic Gate status | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:03 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:03 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:03 |
| bauzas | we had a nova-emulation master job failure https://zuul.openstack.org/build/2f26196745fe4cc8a93b5453317710ee | 16:03 |
| sean-k-mooney | the fix for that job is still not merged | 16:04 |
| sean-k-mooney | it keeps hitting job timeout or unrelated failures in other jobs | 16:04 |
| bauzas | because of when deleting some instance, it was not found | 16:04 |
| sean-k-mooney | i have started to look in to how to gather some data to deteimn if we should bump the timeouts in the integrated-compute jobs and its decendent jobs | 16:04 |
| bauzas | ok | 16:05 |
| sean-k-mooney | the simple solution woudl be to temporally add 30mins to the integrated comptue job while i try and figure out what a more reasonable value would be | 16:05 |
| bauzas | but it was not a timeout issue | 16:06 |
| sean-k-mooney | not in this case | 16:06 |
| sean-k-mooney | but the patch that fixes the OOM issue in that job | 16:06 |
| sean-k-mooney | is being blocked by timouts in other jobs | 16:06 |
| bauzas | ah ok | 16:06 |
| sean-k-mooney | anyway i think we can move on for now | 16:07 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:07 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:07 |
| bauzas | #topic Release Planning | 16:07 |
| bauzas | #link https://releases.openstack.org/dalmatian/schedule.html | 16:07 |
| bauzas | #info Dalmatian-2 in 3 weeks | 16:07 |
| bauzas | #info we'll have a spec review day on July 3rd | 16:08 |
| bauzas | (which is a Wednesday) | 16:08 |
| bauzas | #action bauzas to tell this in the mailing-list | 16:08 |
| bauzas | (on July 2nd I'll be off) | 16:09 |
| bauzas | would people prefer to have this day on Monday, as July 4th is some US holiday | 16:09 |
| bauzas | ? | 16:09 |
| bauzas | is it me lagging or nobody replied ? | 16:11 |
| dansmith | nobody replied | 16:11 |
| bauzas | thoughts then ? | 16:11 |
| dansmith | it's right around the american holiday | 16:12 |
| dansmith | most of us will be plotting to blow up our neighbors on the following day | 16:12 |
| sean-k-mooney | i have no real prefernce os i think tis also fine if we do it semi async | 16:13 |
| sean-k-mooney | i.e. if us folks wont be around that day and feel like doing reviews on monday then the rest of us will already have that feedback | 16:13 |
| sean-k-mooney | on wednesday | 16:13 |
| bauzas | ok, let's do this on monday and I'll explain that it can be async for the week | 16:15 |
| bauzas | moving on | 16:15 |
| bauzas | #topic Review priorities | 16:15 |
| bauzas | #link https://etherpad.opendev.org/p/nova-dalmatian-status | 16:15 |
| bauzas | nothing to report, I'm planning to review specs but my lag doesn't help much today | 16:16 |
| bauzas | hopefully my connection will come back tomorrow | 16:16 |
| * bauzas won't tell how his fiber is good | 16:16 | |
| bauzas | moving on | 16:17 |
| bauzas | #topic Stable Branches | 16:17 |
| bauzas | elodilles: please | 16:17 |
| elodilles | #info stable gates should be OK | 16:17 |
| elodilles | #info nova 29.0.2 released for 2024.1 Caracal stable series | 16:17 |
| elodilles | thanks for the review o/ | 16:17 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:17 |
| elodilles | and that's all from me about stable | 16:18 |
| bauzas | cool | 16:20 |
| bauzas | thanks | 16:20 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:20 |
| bauzas | fwiesel: anything to tell ? | 16:20 |
| fwiesel | #info Fixed bug in resolving the right branch in case of renaming from "stable/" to "unsupported/" | 16:20 |
| fwiesel | Not much, but a small change... I query now the gerrit api to find out how the actual branch name is for each project. | 16:21 |
| fwiesel | Any questions or feedback? | 16:21 |
| elodilles | (* "unmaintained" o:)) | 16:21 |
| bauzas | yeah, unmaintained is the right wording | 16:22 |
| bauzas | thanks fwiesel for that | 16:22 |
| fwiesel | Ah, sorry. Yeah, in the code it is correct :) | 16:22 |
| elodilles | :) | 16:22 |
| fwiesel | That's then from my side wrt the 3rd-party CI | 16:23 |
| bauzas | cool | 16:24 |
| bauzas | #topic Open discussion | 16:24 |
| bauzas | anything anyone ? | 16:24 |
| fwiesel | Hopefully a quick question: I have a draft for a blueprint in etherpad: https://etherpad.opendev.org/p/nova-lazy-metadata-loading | 16:24 |
| fwiesel | How do I continue from there on? | 16:24 |
| fwiesel | Register it right away and put that in the url? | 16:25 |
| fwiesel | Or ask here for feedback? (as I have done then implicitly) | 16:25 |
| bauzas | well, usually, we discuss specless blueprints in our meetings | 16:26 |
| bauzas | if you want to have it accepted, it's the right time | 16:26 |
| bauzas | or do you want to discuss the design ? | 16:26 |
| * bauzas clicks but it will take a bit of time | 16:26 | |
| bauzas | oh, that's a spec template, nevermind | 16:27 |
| bauzas | I think you can now create the blueprint, link it in the spec and upload that spec | 16:27 |
| fwiesel | in nova-specs then? | 16:28 |
| bauzas | you need to register a blueprint with https://blueprints.launchpad.net/nova/+spec/lazy-metadata-loading | 16:28 |
| bauzas | then you need to upload the file you created in the nova-specs/2024.2/approved repor | 16:28 |
| bauzas | s/repor/directory | 16:28 |
| bauzas | and then push that commit to gerrit | 16:29 |
| fwiesel | Okay, thanks. Will do | 16:30 |
| bauzas | fwiesel: pro-tip, in the commit msg (in the nova-specs repo), add a specific "blueprint lazy-metadata-loading" tag in the text | 16:32 |
| bauzas | something like "Proposes blueprint lazy-metadata-loading" | 16:32 |
| bauzas | it will automatically link the spec in the blueprint whiteboard | 16:32 |
| bauzas | ideally, create local branch from that name, so gerrit will have this topic | 16:33 |
| fwiesel | Great, I'll do that. | 16:33 |
| bauzas | okay, anything else ? | 16:36 |
| bauzas | ok, I think we can close the meeting | 16:40 |
| bauzas | thanks guys | 16:40 |
| bauzas | #endmeeting | 16:40 |
| opendevmeet | Meeting ended Tue Jun 11 16:40:52 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:40 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-06-11-16.00.html | 16:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-06-11-16.00.txt | 16:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-06-11-16.00.log.html | 16:40 |
| elodilles | thanks o/ | 16:41 |
| fwiesel | \o | 16:42 |
| *** bauzas_ is now known as bauzas | 17:46 | |
| *** bauzas_ is now known as bauzas | 19:44 | |
| *** bauzas_ is now known as bauzas | 19:57 | |
| *** bauzas_ is now known as bauzas | 20:05 | |
| *** bauzas_ is now known as bauzas | 20:50 | |
| *** bauzas_ is now known as bauzas | 20:58 | |
| *** bauzas_ is now known as bauzas | 21:06 | |
| *** bauzas_ is now known as bauzas | 23:22 | |
| *** bauzas_ is now known as bauzas | 23:55 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!