| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-08 | |||
| 16:09:04 | bauzas | okay, moving on anyway | |
| 16:09:15 | bauzas | #topic Gate status | |
| 16:09:22 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:09:27 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:09:35 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:09:41 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:09:48 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:10:37 | bauzas | we got a couple of failures on the periodics | |
| 16:10:45 | bauzas | but : | |
| 16:10:51 | bauzas | - for py38 we should remove the job | |
| 16:11:13 | bauzas | - we know that c9s is currently failing | |
| 16:11:23 | bauzas | - ditto with the fips job | |
| 16:11:41 | bauzas | (that's because rdo hadn't yet delivered Dalmatian) | |
| 16:11:59 | bauzas | so, anything else people would want to discuss about CI ? | |
| 16:12:14 | gibi | 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 | gibi | 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 | gibi | Is this known? | |
| 16:12:53 | clarkb | gibi: cinder hit it too | |
| 16:13:07 | clarkb | I did some digging and I could only find incidence of it in rax-ord I think it was | |
| 16:13:22 | bauzas | yeah, looks like a node problem | |
| 16:13:26 | clarkb | when it occurred the product version for xen reported by ansible fact gathering is older than on successful jobs | |
| 16:13:44 | clarkb | I was going to followup with cardoe on it this week to see if rax has a bad hypervisor. | |
| 16:14:00 | clarkb | Oh also it seems to maybe only affect python3.12 so could be a combo of xen version and noble kernel | |
| 16:14:19 | gibi | I'm wondering how devstack generates cpu_shared_set config, or we just keep it empty ? | |
| 16:14:58 | gibi | clarkb: thanks | |
| 16:15:10 | clarkb | oh wait this is different | |
| 16:15:21 | clarkb | gibi: the problem you have is because rax-flex only has 4vcpu instead of 8 | |
| 16:15:40 | clarkb | 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 | gibi | then we need to change our devstack config as it is explicitly uses 0-7 pcpus for nova | |
| 16:16:56 | clarkb | 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 | gibi | clarkb: https://zuul.opendev.org/t/openstack/build/93e5dca3b79348e5a8d3f5fecda82382/log/controller/logs/etc/nova/nova-cpu_conf.txt | |
| 16:17:57 | gibi | anyhow I think I understand the root cause now. So we can move on | |
| 16:18:24 | gibi | we might need a smarter devstack config generation to take into account the available cpus | |
| 16:18:27 | bauzas | gibi: would you imagine some devstack check that would lookup the cpus ? | |
| 16:18:32 | bauzas | hah | |
| 16:18:41 | gibi | yeah :) | |
| 16:18:50 | bauzas | that sounds a good idea to me | |
| 16:19:13 | bauzas | anyway, let's not solve that problem now | |
| 16:19:29 | bauzas | the wikipage's agenda is now updated \o/ | |
| 16:19:54 | bauzas | #topic Release Planning | |
| 16:20:01 | bauzas | #info Dalmatian GA last Wednesday | |
| 16:20:03 | bauzas | huzzah | |
| 16:20:08 | elodilles | \o/ | |
| 16:20:11 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:20:31 | bauzas | #info as a reminder, nova Epoxy deadlines will be defined at the PTG | |
| 16:20:48 | bauzas | #topic Review priorities | |
| 16:21:42 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | |
| 16:21:50 | bauzas | nothing to report | |
| 16:21:56 | bauzas | #topic PTG planning | |
| 16:22:02 | bauzas | #info as a reminder, we'll meet (virtually) at the PTG on Oct 21-25 2024 | |
| 16:22:10 | bauzas | #info Please register yourself to the virtual PTG | |
| 16:22:17 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-ptg | |
| 16:22:24 | bauzas | the etherpad is horribly empty | |
| 16:23:13 | bauzas | 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 | gibi | then we will have a slow ptg week :) | |
| 16:23:34 | bauzas | gibi: I'm afraid this will just mean we'll have a short time for organizing ourselves | |
| 16:23:43 | bauzas | with a packed week | |
| 16:24:15 | bauzas | I also got a request from the horizon team to have a cross-project session | |
| 16:24:37 | gibi | agility :) | |
| 16:24:53 | bauzas | I'll reply to tatiana asking her when they're available during the week | |
| 16:25:06 | bauzas | gibi: please, don't say gross words | |
| 16:25:48 | bauzas | given the current agenda, I'm cool with taking one hour from the 16 I booked | |
| 16:26:23 | sean-k-mooney1 | gibi: yes i know what causes that | |
| 16:26:29 | bauzas | oh, also I'll probably need to handover some Friday discussions as I would attend the TC sessions | |
| 16:26:38 | sean-k-mooney1 | i shoudl go and revert the patch that added that until i can fix the it properly | |
| 16:27:07 | gibi | sean-k-mooney1: ack | |
| 16:27:09 | bauzas | anyway, moving on | |
| 16:27:11 | sean-k-mooney1 | ah just caught up | |
| 16:27:16 | bauzas | #topic Stable Branches | |
| 16:27:36 | bauzas | elodilles: report :) | |
| 16:27:45 | elodilles | not much to report actually :) | |
| 16:27:48 | elodilles | #info stable/202*.* gates seem to be OK | |
| 16:27:58 | elodilles | and that's all for now :) | |
| 16:28:38 | bauzas | ++ | |
| 16:28:50 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:28:53 | bauzas | fwiesel: around ? | |
| 16:28:56 | fwiesel | #info https://review.opendev.org/c/openstack/nova/+/910627 merged | |
| 16:29:07 | fwiesel | So, in theory, we should be down to two failing tests... | |
| 16:29:31 | fwiesel | Theory, as the pipeline is still flaky. I have a lead, but no fix yet for that. | |
| 16:29:46 | fwiesel | After that, I tackle the last two failing tests. | |
| 16:29:56 | fwiesel | That's from my side, unless there are any questions. | |
| 16:30:12 | bauzas | cool, thanks | |
| 16:30:25 | fwiesel | (Thanks to sean-k-moonkey1 and dansmith for reviewing it) | |
| 16:30:29 | bauzas | #topic Open discussion | |
| 16:30:35 | bauzas | (tkajinam): Python 3.8 support being removed | |
| 16:30:41 | bauzas | is tkajinam around ? | |
| 16:31:31 | bauzas | oh wait, I'm burned | |
| 16:31:38 | bauzas | we discussed that last week | |
| 16:31:46 | bauzas | this just ringed a bell to my tired mind | |
| 16:31:59 | bauzas | moving on to the other item in the agenda | |
| 16:32:19 | bauzas | (auniyal) Request to approve blueprint https://blueprints.launchpad.net/nova/+spec/nova-manage-improvement | |
| 16:32:22 | bauzas | is auniyal here ? | |
| 16:32:26 | auniyal | yep | |
| 16:32:44 | auniyal | its an improvement in nova-manage cmd | |
| 16:33:06 | auniyal | to return output in more formats such as json | |
| 16:33:26 | dansmith | doesn't this need a spec given some of the complexities around making sure there is consistency among all the commands? | |
| 16:33:29 | sean-k-mooney | so that eaiser said then done | |
| 16:33:44 | sean-k-mooney | unlike osc we are using raw prints | |
| 16:33:51 | sean-k-mooney | in nova manage | |
| 16:34:42 | gibi | 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 | |