16:00:41 #startmeeting nova 16:00:41 Meeting started Tue Oct 8 16:00:41 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:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:41 The meeting name has been set to 'nova' 16:00:56 o/ 16:00:58 o/ 16:01:09 o/ 16:01:10 o/ 16:01:26 o/ 16:01:58 #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 16:02:06 sorry my internet seems to slow down 16:02:19 and I had two meetings just before 16:02:29 so I'm also slowing down 16:03:03 hah, internal error when updating the agenda 16:03:18 let's do it by hand 16:03:21 #topic Bugs (stuck/critical) 16:03:39 #info One Critical bug 16:03:46 #link https://bugs.launchpad.net/nova/+bug/2083518 16:03:56 #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster 16:04:40 tkajinam: around ? want to discuss distutils problem with py3.12 ? 16:07:00 apparently, nothing to say 16:07:33 I'm just not sure this is a critical bug per say, but we need to fix it as soon as we can 16:08:05 o/ 16:09:04 okay, moving on anyway 16:09:15 #topic Gate status 16:09:22 #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:09:27 #link https://etherpad.opendev.org/p/nova-ci-failures-minimal 16:09:35 #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status 16:09:41 #info Please look at the gate failures and file a bug report with the gate-failure tag. 16:09:48 #info Please try to provide meaningful comment when you recheck 16:10:37 we got a couple of failures on the periodics 16:10:45 but : 16:10:51 - for py38 we should remove the job 16:11:13 - we know that c9s is currently failing 16:11:23 - ditto with the fips job 16:11:41 (that's because rdo hadn't yet delivered Dalmatian) 16:11:59 so, anything else people would want to discuss about CI ? 16:12:14 I saw strange CI failure where the nova-compute complained that the cpus configured for VMs not available on the host. https://review.opendev.org/c/openstack/nova/+/928584/11#message-67b19ed6c1571b06bb03a4f24c903504521a88f4 16:12:18 Invalid '[compute] cpu_shared_set' config: one or more of the configured CPUs is not online. Online cpuset(s): [0, 1, 2, 3], configured cpuset(s): [0, 1, 2, 3, 4, 5] 16:12:22 Is this known? 16:12:53 gibi: cinder hit it too 16:13:07 I did some digging and I could only find incidence of it in rax-ord I think it was 16:13:22 yeah, looks like a node problem 16:13:26 when it occurred the product version for xen reported by ansible fact gathering is older than on successful jobs 16:13:44 I was going to followup with cardoe on it this week to see if rax has a bad hypervisor. 16:14:00 Oh also it seems to maybe only affect python3.12 so could be a combo of xen version and noble kernel 16:14:19 I'm wondering how devstack generates cpu_shared_set config, or we just keep it empty ? 16:14:58 clarkb: thanks 16:15:10 oh wait this is different 16:15:21 gibi: the problem you have is because rax-flex only has 4vcpu instead of 8 16:15:40 this is known because even with 4vcpu the jobs are running faster and there is no need to ask for an 8vcpu variant 16:16:41 then we need to change our devstack config as it is explicitly uses 0-7 pcpus for nova 16:16:56 side note: I always ask people link to the job logs it makes my life much easier when debugging if I don't have to dig through gerrit change info to find the specific build in question 16:17:26 clarkb: https://zuul.opendev.org/t/openstack/build/93e5dca3b79348e5a8d3f5fecda82382/log/controller/logs/etc/nova/nova-cpu_conf.txt 16:17:57 anyhow I think I understand the root cause now. So we can move on 16:18:24 we might need a smarter devstack config generation to take into account the available cpus 16:18:27 gibi: would you imagine some devstack check that would lookup the cpus ? 16:18:32 hah 16:18:41 yeah :) 16:18:50 that sounds a good idea to me 16:19:13 anyway, let's not solve that problem now 16:19:29 the wikipage's agenda is now updated \o/ 16:19:54 #topic Release Planning 16:20:01 #info Dalmatian GA last Wednesday 16:20:03 huzzah 16:20:08 \o/ 16:20:11 #link https://releases.openstack.org/epoxy/schedule.html 16:20:31 #info as a reminder, nova Epoxy deadlines will be defined at the PTG 16:20:48 #topic Review priorities 16:21:42 #link https://etherpad.opendev.org/p/nova-2025.1-status 16:21:50 nothing to report 16:21:56 #topic PTG planning 16:22:02 #info as a reminder, we'll meet (virtually) at the PTG on Oct 21-25 2024 16:22:10 #info Please register yourself to the virtual PTG 16:22:17 #link https://etherpad.opendev.org/p/nova-2025.1-ptg 16:22:24 the etherpad is horribly empty 16:23:13 I know some of us could wait a bit before adding topics, but maybe some people could already know things that they're sure that they could be working 16:23:14 then we will have a slow ptg week :) 16:23:34 gibi: I'm afraid this will just mean we'll have a short time for organizing ourselves 16:23:43 with a packed week 16:24:15 I also got a request from the horizon team to have a cross-project session 16:24:37 agility :) 16:24:53 I'll reply to tatiana asking her when they're available during the week 16:25:06 gibi: please, don't say gross words 16:25:48 given the current agenda, I'm cool with taking one hour from the 16 I booked 16:26:23 gibi: yes i know what causes that 16:26:29 oh, also I'll probably need to handover some Friday discussions as I would attend the TC sessions 16:26:38 i shoudl go and revert the patch that added that until i can fix the it properly 16:27:07 sean-k-mooney1: ack 16:27:09 anyway, moving on 16:27:11 ah just caught up 16:27:16 #topic Stable Branches 16:27:36 elodilles: report :) 16:27:45 not much to report actually :) 16:27:48 #info stable/202*.* gates seem to be OK 16:27:58 and that's all for now :) 16:28:38 ++ 16:28:50 #topic vmwareapi 3rd-party CI efforts Highlights 16:28:53 fwiesel: around ? 16:28:56 #info https://review.opendev.org/c/openstack/nova/+/910627 merged 16:29:07 So, in theory, we should be down to two failing tests... 16:29:31 Theory, as the pipeline is still flaky. I have a lead, but no fix yet for that. 16:29:46 After that, I tackle the last two failing tests. 16:29:56 That's from my side, unless there are any questions. 16:30:12 cool, thanks 16:30:25 (Thanks to sean-k-moonkey1 and dansmith for reviewing it) 16:30:29 #topic Open discussion 16:30:35 (tkajinam): Python 3.8 support being removed 16:30:41 is tkajinam around ? 16:31:31 oh wait, I'm burned 16:31:38 we discussed that last week 16:31:46 this just ringed a bell to my tired mind 16:31:59 moving on to the other item in the agenda 16:32:19 (auniyal) Request to approve blueprint https://blueprints.launchpad.net/nova/+spec/nova-manage-improvement 16:32:22 is auniyal here ? 16:32:26 yep 16:32:44 its an improvement in nova-manage cmd 16:33:06 to return output in more formats such as json 16:33:26 doesn't this need a spec given some of the complexities around making sure there is consistency among all the commands? 16:33:29 so that eaiser said then done 16:33:44 unlike osc we are using raw prints 16:33:51 in nova manage 16:34:42 at least on of the use case is coming from here https://github.com/openstack-k8s-operators/nova-operator/blob/7e7ba33aab515809fb23ce20cb6a55e50da3f457/templates/nova-manage/bin/ensure_cell_mapping.sh#L20-L25 and for that having a --cell_name param would be enough 16:35:00 we cnat rely on click/cliff to help use with that generically 16:35:14 we could do it on a per comand basis yes 16:35:21 AFAIK, originally nova-manage wasn't intended to be scripted 16:35:27 hence the poor interface 16:35:45 sure, I can write a spec, the output is formatted by prettytable mostly 16:35:54 bauzas: deployment tooling needs to add cells, there is no other interface for that 16:36:05 which supports other format as well 16:36:19 gibi: I wasn't disagreeing your usecase, I was just explaining why we basically have that 16:36:51 auniyal: so for succsful output yes alot goes via prettytbale 16:36:52 and my use case does not need json output per se, it needs a way to easily manipulate cells by name and not by uuid 16:36:58 error tend to just use print directly 16:37:02 but I agree with dansmith, there could be some concerns about ensuring that we keep the same formatted output 16:37:23 so lets move forward with a spec and review the proposal 16:37:28 agreed 16:37:29 gibi: ack, the cell_name thing is easy to just do without a spec, no doubt.. the json thing not so much, IMHO 16:37:52 I think we can just tuck the cell_name thing under the covers without a lot of paperwork, IMHO, if it's as easy as I expect 16:37:59 so perhaps just do that as a one-off and spec for the json stuff? 16:38:16 ack 16:38:19 we can do both but I prefer to have --cell_name as that feels easier 16:38:27 yeah that should be two blueprints 16:38:46 one for adding a new param to the command, the other one about formatting outputs 16:39:05 idk that we need a blueprint for a single simpleish patch for cell_name, personally, but whatever the PTL says :) 16:39:13 and as dansmith, I'm cool with stamping over the cell param addition bp as a specless, if that helps 16:39:36 then the PTL says : dude, write the patch and consider it as just a techdeby 16:39:45 ++ 16:39:49 if we want a tracker i guess we can use a wishlist bug 16:39:52 tech debt reduction 16:40:02 sean-k-mooney: sure 16:40:03 yep 16:40:13 let's not paper it, we now have a status etherpad for tracking such patches 16:40:25 but I'm cool with a wishlist bug 16:41:17 moving on? 16:41:23 yah 16:41:31 cool 16:41:34 that was it in the agenda 16:41:45 if I can, I'd like to beg for review of this: https://review.opendev.org/c/openstack/nova/+/930754 16:41:48 anything else or can I just take a breath before my 4th meeting ? 16:42:00 definitely could use some in-depth sanity checking of my findings 16:42:10 but it needs to go in before glance can start enforcing image formats 16:42:19 I'll 16:42:52 I already have the context 16:43:00 thanks 16:43:34 can i ask for a review of https://review.opendev.org/c/openstack/nova/+/811521 ? just need one more +2 to finally complete this BP 16:44:15 oh that ya i ment to loop back to it. im also +2 on haleyb change 16:44:33 dansmith: I just have one open question, this will change the uploaded image type, right? 16:44:35 sean-k-mooney: thanks for the +2, i figured i'd wait until we were in epoxy 16:44:51 if so, shall we document that in a relnote ? 16:45:28 bauzas: it doesn't upload an image 16:45:40 bauzas: it just creates one and then does a zero-byte upload to make it active 16:46:02 bauzas: since it claims it will be qcow2, zero bytes is not a valid qcow2 file, so glance rejects it 16:46:09 ah I see 16:46:14 we really shouldn't be doing this at all, IMHO, but alas 16:46:19 (I thought you already had context? :D) 16:46:29 we just ping glance just for the sake of flipping something on our side, naice 16:46:43 we just LIE to glance, but yeah :D 16:46:58 dansmith: I had the context, but I missed that detail 16:47:06 its not really that, we are tryign to make bfv snapshot look like boot form image snapshots 16:47:09 but they are not 16:47:12 the same 16:47:19 and trust me, I refrain myself as hard as a I can from stepping into that image mud 16:47:25 that's the reason for the lie yeah 16:48:01 okay, now I have everything I need for reviewing that patch 16:49:25 thanks 16:49:54 bauzas: gibi woudl either of ye have bandwith to review haleyb patch 16:50:10 bauzas: you have seen that before too a few months ago 16:50:23 yeah 16:50:26 I'll 16:50:27 cool 16:50:48 that's it for me 16:50:55 anything else last minute ? 16:51:08 sean-k-mooney, can you please loop back at this too https://review.opendev.org/c/openstack/nova/+/929858 16:51:31 yes i can try 16:51:42 thanks 16:51:53 i asked you to ping me if i didnt do it last week so thansk for the reminder 16:51:55 sean-k-mooney: I can try too 16:52:12 okay, that's it for the meeting then 16:52:14 thanks all 16:52:19 #endmeeting