| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-08 | |||
| 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 | |
| 16:35:00 | sean-k-mooney | we cnat rely on click/cliff to help use with that generically | |
| 16:35:14 | sean-k-mooney | we could do it on a per comand basis yes | |
| 16:35:21 | bauzas | AFAIK, originally nova-manage wasn't intended to be scripted | |
| 16:35:27 | bauzas | hence the poor interface | |
| 16:35:45 | auniyal | sure, I can write a spec, the output is formatted by prettytable mostly | |
| 16:35:54 | gibi | bauzas: deployment tooling needs to add cells, there is no other interface for that | |
| 16:36:05 | auniyal | which supports other format as well | |
| 16:36:19 | bauzas | gibi: I wasn't disagreeing your usecase, I was just explaining why we basically have that | |
| 16:36:51 | sean-k-mooney | auniyal: so for succsful output yes alot goes via prettytbale | |
| 16:36:52 | gibi | 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 | sean-k-mooney | error tend to just use print directly | |
| 16:37:02 | bauzas | but I agree with dansmith, there could be some concerns about ensuring that we keep the same formatted output | |
| 16:37:23 | sean-k-mooney | so lets move forward with a spec and review the proposal | |
| 16:37:28 | bauzas | agreed | |
| 16:37:29 | dansmith | 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 | dansmith | 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 | dansmith | so perhaps just do that as a one-off and spec for the json stuff? | |
| 16:38:16 | auniyal | ack | |
| 16:38:19 | gibi | we can do both but I prefer to have --cell_name as that feels easier | |
| 16:38:27 | bauzas | yeah that should be two blueprints | |
| 16:38:46 | bauzas | one for adding a new param to the command, the other one about formatting outputs | |
| 16:39:05 | dansmith | idk that we need a blueprint for a single simpleish patch for cell_name, personally, but whatever the PTL says :) | |
| 16:39:13 | bauzas | and as dansmith, I'm cool with stamping over the cell param addition bp as a specless, if that helps | |
| 16:39:36 | bauzas | then the PTL says : dude, write the patch and consider it as just a techdeby | |
| 16:39:45 | dansmith | ++ | |
| 16:39:49 | sean-k-mooney | if we want a tracker i guess we can use a wishlist bug | |
| 16:39:52 | bauzas | tech debt reduction | |
| 16:40:02 | dansmith | sean-k-mooney: sure | |
| 16:40:03 | sean-k-mooney | yep | |
| 16:40:13 | bauzas | let's not paper it, we now have a status etherpad for tracking such patches | |