| opendevreview | Takashi Kajinami proposed openstack/nova-specs master: tox: Drop envdir https://review.opendev.org/c/openstack/nova-specs/+/941184 | 04:25 |
|---|---|---|
| opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing image properties in server show response https://review.opendev.org/c/openstack/nova/+/939649 | 06:10 |
| mikal | sean-k-mooney: I just pushed an updated tempest patch to address review comments, so I guess we have to retry at some point regardless. | 07:09 |
| *** ralonsoh_ is now known as ralonsoh | 10:21 | |
| opendevreview | Vasyl Saienko proposed openstack/nova master: WIP: Implement trunk subports for ironic driver https://review.opendev.org/c/openstack/nova/+/941227 | 10:22 |
| Uggla | vGPU meeting : https://meet.google.com/tek-noky-eca | 13:31 |
| *** ralonsoh_ is now known as ralonsoh | 14:00 | |
| MengyangZhang[m] | <sean-k-mooney> "so we woudl need to have the..." <- understood, just curious in reality when we will see a cloud have hosts on different version of openstack? | 14:08 |
| sean-k-mooney | MengyangZhang[m]: its quite common for larger clouds to do rolling uprgardes potentially over the course of several mantiance window over a period of months | 14:14 |
| sean-k-mooney | i.e. where the operatrion team need to work with the teants to organise outages | 14:14 |
| sean-k-mooney | not all feature in nova allow live migration for example vgpus or pci passthough | 14:15 |
| sean-k-mooney | so depenidng on the constraitnt the admin has they may not be able to upgrade all host ot the same version at once | 14:15 |
| sean-k-mooney | MengyangZhang[m]: https://github.com/openstack/governance/blob/master/resolutions/20220210-release-cadence-adjustment.rst describe the skip level upgrade requirments that all project must support | 14:17 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Replace oslo_utils.encodeutils.exception_to_unicode https://review.opendev.org/c/openstack/nova/+/940619 | 14:51 |
| gmann | bauzas: can you please check this rbac spec, need 2nd +2. I would not be able to attend the meeting, in case it needs to be discussed as feature freeze exception but I think you know the context of it. I started the code change also in parallel https://review.opendev.org/c/openstack/nova-specs/+/937650 | 15:30 |
| bauzas | #startmeeting nova | 16:01 |
| opendevmeet | Meeting started Tue Feb 11 16:01:09 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| fwiesel | o/ | 16:01 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| sp-bmilanov | hello! | 16:01 |
| elodilles_pto | o/ | 16:02 |
| Uggla | o/ | 16:02 |
| bauzas | I guess we can softly starty | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:04 |
| bauzas | #info No Critical bug | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:04 |
| bauzas | any bugs people wanna discuss ? | 16:04 |
| bauzas | apparently not | 16:05 |
| bauzas | moving on | 16:06 |
| bauzas | #topic Gate status | 16:06 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:06 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:06 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:06 |
| bauzas | all periodics seem to be green | 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 | any gate failures to discuss ? | 16:07 |
| bauzas | I have one actually | 16:08 |
| bauzas | when looking at https://review.opendev.org/c/openstack/nova/+/940642, even by rechecking, I got the same exceptions on nova-next and nova-multi-cell jobs | 16:08 |
| bauzas | for the same test | 16:08 |
| bauzas | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ba0/940642/5/check/nova-next/ba009c2/testr_results.html | 16:09 |
| bauzas | https://6ae015e4c924496dfda3-74c26bb67ca36871e200d07f3210a3f0.ssl.cf1.rackcdn.com/940642/5/check/nova-multi-cell/c2a2f68/testr_results.html | 16:09 |
| bauzas | have people seen the same failure ? | 16:09 |
| bauzas | last time I looked, I saw nova-next failing once over 5 times | 16:09 |
| bauzas | this would create some problems later in the week | 16:10 |
| bauzas | so I wonder whether we should skip that specific test | 16:10 |
| Uggla | @bauzas, the one I pushed yesterday pass the tests | 16:11 |
| bauzas | hmmm | 16:12 |
| bauzas | okay, will wee | 16:12 |
| bauzas | see* | 16:12 |
| * gibi joining late | 16:12 | |
| Uggla | maybe you were not unlucky. | 16:12 |
| bauzas | oh, nvm found the root case, PEBKAC | 16:13 |
| bauzas | https://6ae015e4c924496dfda3-74c26bb67ca36871e200d07f3210a3f0.ssl.cf1.rackcdn.com/940642/5/check/nova-multi-cell/c2a2f68/controller/logs/screen-n-sch.txt | 16:13 |
| bauzas | this is because of my patch | 16:14 |
| bauzas | so we can move on | 16:14 |
| bauzas | any other failure to discuss ? | 16:14 |
| bauzas | #topic Release Planning | 16:15 |
| bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:15 |
| bauzas | #info Nova deadlines are set in the above schedule | 16:15 |
| bauzas | #info 2 weeks before Feature Freeze | 16:15 |
| bauzas | so maybe we should go straight to the next topic | 16:16 |
| bauzas | #topic Review priorities | 16:16 |
| bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:16 |
| bauzas | I'll be honest, I was swamped by other priorities but I want to review a long list of changes this week | 16:16 |
| bauzas | that becomes super urgent | 16:16 |
| dviroel | fyi, I added at line 131 links to the blueprint and gerrit topic wrt scheduler-hints-in-server-details | 16:17 |
| dviroel | please take a look when you folks have some time :) | 16:17 |
| bauzas | noted, appreciated | 16:18 |
| bauzas | given my on-off presence on IRC, I appreciate any way to discuss async | 16:18 |
| bauzas | #topic PTG planning | 16:18 |
| bauzas | well, I won't run that PTG by myself but this is a reminder that we'll have a PTG | 16:19 |
| bauzas | #info Next PTG will be held on Apr 7-11 | 16:19 |
| bauzas | I started to draft some etherpad for that PTG | 16:19 |
| bauzas | #link https://etherpad.opendev.org/p/nova-2025.2-ptg | 16:19 |
| bauzas | feel free to add your topics worth of interest into it ^ | 16:19 |
| bauzas | #topic Stable Branches | 16:21 |
| bauzas | elodilles_pto: oh he's not here | 16:21 |
| bauzas | no worries, let's skip it for this week | 16:21 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:21 |
| *** elodilles_pto is now known as elodilles | 16:21 | |
| bauzas | fwiesel: anything to talk ? | 16:21 |
| fwiesel | Hi, yes... some progress on the last outstanding failure. | 16:21 |
| elodilles | (sorry, i'm here, just forgot to change my nick o:) but stable gates seems to be healthy, fwiw) | 16:22 |
| fwiesel | I suspect I do have a possible patch for that, but now I run into a bug into Cinder. I've created a bug report for it (https://bugs.launchpad.net/cinder/+bug/2097771) and want to fix that. | 16:22 |
| bauzas | elodilles: noted. | 16:22 |
| bauzas | fwiesel: ack, thanks for the reporting | 16:22 |
| fwiesel | If that works out, I will ask you to review my solution for nova making use of that. | 16:22 |
| fwiesel | That's from my side. | 16:23 |
| bauzas | thanks | 16:24 |
| bauzas | #topic Open discussion | 16:24 |
| bauzas | we have one topic to discuss today | 16:25 |
| bauzas | sp-bmilanov -- 927474: libvirt: Fetch the available vCPUs from the respective cgroup | 16:25 |
| bauzas | sp-bmilanov: around ? | 16:25 |
| sp-bmilanov | hi! yep | 16:25 |
| bauzas | #link https://review.opendev.org/c/openstack/nova/+/927474 | 16:25 |
| bauzas | sean-k-mooney: are you here ? | 16:26 |
| sean-k-mooney | yes | 16:26 |
| sp-bmilanov | the topic is about how to handle the case where Nova is running in a hyperconverged setup where the are CPUs that are not available to Nova | 16:26 |
| sean-k-mooney | i do not belive nova should do that but ill let sp-bmilanov explain | 16:26 |
| sp-bmilanov | I was hoping to crowd-source alternatives | 16:26 |
| sean-k-mooney | perhaps some context will help | 16:27 |
| sp-bmilanov | the fundamental problem IMO is with libvirt -- it assumes all online CPUs == schedulable CPUs, and does not provide an API to query actually schedulable CPUs | 16:27 |
| gibi | > CPUs that are not available to Nova < that feels like the existing cpuset config can handle | 16:27 |
| sean-k-mooney | its possible to use the cgroups api to subdevied the host and mark some host as reserved for exclusive use fo a slice/partion | 16:27 |
| sean-k-mooney | gibi: it can | 16:28 |
| sean-k-mooney | sp-bmilanov would like nova to parse the cgroups toplogy and try and auto comput eit | 16:28 |
| sean-k-mooney | one of my bigest issues with that is libvirt and nova-comptue might have diffent view of the cgroups | 16:28 |
| sean-k-mooney | i.e. nova is deployed in a podman container and livbirt is installed on the host | 16:28 |
| sp-bmilanov | sean-k-mooney: that was our initial approach, but we trying to solve the issue of Nova not using CPUs that are not availble for it | 16:29 |
| gibi | what is the problem then setting the cpuset config option to only allow nova to use the CPUs the deployer wants? | 16:29 |
| sean-k-mooney | sp-bmilanov: we have config options ot specify which cpu nova can use | 16:29 |
| sean-k-mooney | but you explcitly do not want to use the mechanisume we provide for this | 16:29 |
| sp-bmilanov | yep, we'd like to find a way in which Nova can handle this itself | 16:30 |
| sp-bmilanov | else it's a runtime error on VM "creation" | 16:30 |
| gibi | sp-bmilanov: why the cpuset config is not enough? | 16:31 |
| sean-k-mooney | gibi: it does work but sp-bmilanov does not like the ux as they precive it as overly complex to have to configure it | 16:31 |
| gibi | what is the reason you want more automatic discovery of available cpus? | 16:31 |
| sean-k-mooney | nova has supported specifying which cpus can be used for guest via config since the intoduction of vcpu_pin_set in essex ish | 16:32 |
| sean-k-mooney | we currently declare it to be the isntaller responcablity to configure nova for the host it is deployed on | 16:33 |
| sp-bmilanov | yes, partly UX, and that we think it might be possible to do automatically | 16:33 |
| sean-k-mooney | i dont think it really is, not without libvirt changes IMO | 16:34 |
| sean-k-mooney | i think we would need libvirt to provide an api that told nova which cpus could be used | 16:34 |
| sean-k-mooney | we currently use the capablitis api to discuver this info from libvirt | 16:35 |
| sean-k-mooney | that provides us the cpu toplogy, numa affintity ectra | 16:35 |
| sean-k-mooney | it does not tell use which cpus are reserved for exlisve use and cannot be used by libvirt to spawn a vm | 16:36 |
| sp-bmilanov | I agree that this is ultimately an issue in libvirt, but I am concerned that I am not sure how long it would take this to propagate to OpenStack, and in which releases | 16:37 |
| sp-bmilanov | and if there is something adequate we can do in Nova in the meantime, why not | 16:38 |
| sean-k-mooney | i dont think it wold be a good idea to make nova discover this via parsing /sys or /proc | 16:38 |
| bauzas | that's a good question. Usually we ask the reporter to first engage with the libvirt community to see their thoughts | 16:38 |
| dansmith | I don't even understand how that _could_ be a thing | 16:38 |
| sean-k-mooney | the poc patch looks at a particalar part fo /sys to get the cpu set allowed by nova's cgroup | 16:38 |
| sp-bmilanov | dansmith: the use case is hyperconverged setups where there is a e.g. storage service with reserved CPUs installed on the hypervisor | 16:38 |
| sean-k-mooney | but as i noted above that is nto the same as libvirts | 16:39 |
| dansmith | if we need to know what libvirt has available for us and we can't ask it, I don't really see what options we have for discovering it | 16:39 |
| sean-k-mooney | so it would be the wrong info | 16:39 |
| dansmith | sp-bmilanov: I get the use-case totally | 16:39 |
| dansmith | sean-k-mooney: does /sys's view of available CPUs change by cgroup? I had assumed not | 16:39 |
| sean-k-mooney | the patch was going ot look at cgroup specific subpaths | 16:40 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/927474/10/nova/virt/libvirt/host.py#93 | 16:40 |
| dansmith | but either way, that doesn't seem like a solution because we don't know that our cgroup is the same (or configured the same) as libvirt's | 16:40 |
| sean-k-mooney | /sys/fs/cgroup/cpuset/machine.slice/cpuset.cpus', | 16:40 |
| dansmith | ah I see | 16:40 |
| sp-bmilanov | yep, that's not ideal, but we can simplify or extend the checks as much as deemed necessary | 16:41 |
| bauzas | last time we tried to look at sysfs for CPU management, it created some problems | 16:41 |
| sean-k-mooney | sp-bmilanov: in general we try to aovid parsing /sys or /proc if at all posible | 16:42 |
| bauzas | so I'm afraid some OSes couldn't support that | 16:42 |
| sean-k-mooney | it create mantaince issues for us | 16:42 |
| dansmith | a feature that works "sometimes" if a bunch of assumptions are made (i.e. libvirt and nova in the same slice) seems worse than no feature to me, in a lot of cases | 16:42 |
| sean-k-mooney | if we were to do it i could maybe see doing if and only if you provide the path or slice as a config option | 16:43 |
| sean-k-mooney | and only if you configure it | 16:43 |
| sean-k-mooney | i.e. opt in | 16:43 |
| sean-k-mooney | not on by default | 16:43 |
| sp-bmilanov | sean-k-mooney that sounds good | 16:43 |
| sp-bmilanov | an opt-in, if-set -like option | 16:43 |
| sp-bmilanov | a bit like the CPU pinning, but more autonomous | 16:44 |
| sean-k-mooney | mostly but im not sure how other feel about that | 16:44 |
| bauzas | seems yet another knob to me | 16:44 |
| dansmith | can we see all the slices in sysfs or only ours? | 16:45 |
| bauzas | with a fragile interface and many ways to get it wrong | 16:45 |
| sean-k-mooney | that depends | 16:45 |
| sean-k-mooney | if your in a contianer you cant see the host one by default | 16:45 |
| dansmith | if we can see all of them, then passing the name/path to the one libvirt is in so we can inspect it would be better, but idk.. seems fragile to me like bauzas says | 16:45 |
| dansmith | sean-k-mooney: right, so we likely can't see libvirt's either right? | 16:46 |
| sean-k-mooney | not thte way tripleo or kolla deploys nova | 16:46 |
| sean-k-mooney | or our new instaler | 16:46 |
| dansmith | yeah | 16:46 |
| sp-bmilanov | sean-k-mooney mentioned in the change that kolla and tripleo are working around it... sean-k-mooney, where do you "not typiclaly run the nova-comptue binary with | 16:46 |
| sp-bmilanov | cgroupns_mode: "host"" | 16:46 |
| sean-k-mooney | right so exisitng installer only set that on libvirt | 16:47 |
| sean-k-mooney | not on nova | 16:47 |
| sean-k-mooney | so nova-comptue has a restricted view | 16:47 |
| sp-bmilanov | ah, right.. but which installer is that? | 16:47 |
| sp-bmilanov | (I might be missing Nova context) | 16:47 |
| sp-bmilanov | (btw, there's the other side of the discussion, if we were to treat that currently Nova can start and schedule VMs with this misconfiguration, what would be the fix so it does not start at all (as sean-k-mooney suggested in the change comments)) | 16:48 |
| sean-k-mooney | libvirt has it in kolla https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/defaults/main.yml#L11 | 16:49 |
| sean-k-mooney | but not nova-compute https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/defaults/main.yml#L55 | 16:49 |
| sean-k-mooney | adn its the same in tripleo and the new isntaller redhat wrote | 16:49 |
| sean-k-mooney | sp-bmilanov: what installer do you use | 16:50 |
| bauzas | time check : 10 mins before end of meeting | 16:50 |
| sean-k-mooney | dansmith: bauzas am i right in thinking you agree this is out of scope fo nova | 16:50 |
| sean-k-mooney | and in scope fo the installer | 16:50 |
| sp-bmilanov | we have seen a few, but yes, kolla and no installer (opereating system packages) | 16:51 |
| dansmith | I mean, that's kinda my point that this seems like us introspecting the system to dynamically configure ourselves, but in a way that can only work in certain situations | 16:51 |
| bauzas | I'd tend to say yes, this sounds a tooling mechanism that could set the config correctly | 16:51 |
| sean-k-mooney | i would be less agaisnt this if libvirt provided an api for this | 16:51 |
| bauzas | the concern I have is that this approach doesn't sound generic at all and very targeted to a specific case | 16:51 |
| sean-k-mooney | also those config options we use are ment to be virt dirver independent | 16:52 |
| dansmith | right, if libvirt exposes it, that's totally different | 16:52 |
| dansmith | in that case, configuring libvirt is the job of the installer, and nova can maybe even lose some config, right? or at least, not always require it to be set | 16:53 |
| gibi | also it opens the question what if the cgroups config changes while nova-compute is running | 16:53 |
| sean-k-mooney | fun times :) | 16:53 |
| gibi | at least the current config nova has is validated at nova-compute startup | 16:53 |
| sean-k-mooney | yep it wont actully catch this specific case | 16:54 |
| sean-k-mooney | i.e. we validate the cpu are in the info provided by libvirt | 16:54 |
| sean-k-mooney | and if they are online ectra | 16:54 |
| sean-k-mooney | but we dont have visablity into cgroups at all really | 16:54 |
| sean-k-mooney | at least not in this context | 16:54 |
| sean-k-mooney | we have some basic check to know if its cgroups v2 vs v1 | 16:55 |
| bauzas | time check : 4 mins left. | 16:56 |
| gibi | this is complexity that either lives in the installer or lives in nova, as nova is big enough already I rather see this complexity added in the installer. Sure we have multiple installers so that duplicates some effort. | 16:57 |
| dansmith | ++ | 16:57 |
| sp-bmilanov | I was wondering if there is also a way to know this outside of reading cgroups that might be more robust | 16:57 |
| sean-k-mooney | if there is im not aware of one | 16:57 |
| dansmith | there is actually | 16:58 |
| dansmith | ....and it's talking to libvirt :D | 16:58 |
| sean-k-mooney | :) | 16:58 |
| sp-bmilanov | :D | 16:58 |
| bauzas | I guess we can't solve that question now | 16:58 |
| bauzas | sp-bmilanov: could you at least talk to the libvirt community and see their toughts about that ? | 16:59 |
| sp-bmilanov | in any case, it sounds like a good idea to initiate a discussion with libvirt devs as well | 16:59 |
| bauzas | and then come back to us ? | 16:59 |
| sp-bmilanov | bauzas: yep | 16:59 |
| bauzas | cool | 16:59 |
| bauzas | thanks then | 16:59 |
| sp-bmilanov | you're welcome | 16:59 |
| sp-bmilanov | thanks for the input, all | 17:00 |
| bauzas | if you're OK, I think we're done for today | 17:00 |
| bauzas | thanks all | 17:00 |
| bauzas | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Tue Feb 11 17:00:17 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.log.html | 17:00 |
| elodilles | thanks o/ | 17:00 |
| Uggla | thx o/ | 17:00 |
| sean-k-mooney | bauzas: dansmith gibi outside the meeting i have a general question for ye | 17:00 |
| sean-k-mooney | https://termbin.com/de4d | 17:01 |
| sean-k-mooney | that virsh capablites form a centos host | 17:01 |
| sean-k-mooney | i jsut noticed they started reporting whcih machine types are deprecated | 17:01 |
| sean-k-mooney | <machine maxCpus='710' deprecated='yes'>pc-q35-rhel8.5.0</machine> | 17:01 |
| sean-k-mooney | i dont know if they do this for cpu models as well | 17:01 |
| sean-k-mooney | is this something we shoudl be proxying to our logs as a warning? | 17:02 |
| sean-k-mooney | i.e. if you create a vm with a deprecated machine type | 17:02 |
| sean-k-mooney | should not log a warning for that? | 17:02 |
| sean-k-mooney | qemu/libvirt will in the libvirt qemu instance log | 17:02 |
| gibi | sean-k-mooney: do you mean nova logs a warning at startup for each instance using a deprecated type? or just warning if nova default type is deprecated? | 17:02 |
| sean-k-mooney | well either i guess. | 17:03 |
| gibi | not a bad idea | 17:03 |
| sean-k-mooney | it could get noisy | 17:03 |
| gibi | if it is startup only then it is not a constant noise | 17:03 |
| sean-k-mooney | but i dotn belive we have any openstack level log about this | 17:03 |
| sean-k-mooney | liek it almost a nova-status thing | 17:03 |
| sean-k-mooney | but we dont run that on computes | 17:03 |
| sean-k-mooney | oh so on start up check the current isntances and log a warning? | 17:04 |
| sean-k-mooney | something liek that | 17:04 |
| dansmith | yeah not a bad idea, but I wouldn't warn too often | 17:04 |
| sean-k-mooney | <model usable='yes' deprecated='yes' vendor='Intel' canonical='core2duo-v1'>core2duo</model> | 17:05 |
| dansmith | warning only on startup is maybe not that great either.. once per deprecated use would be nicer.. can we leverage the warnings module perhaps? | 17:05 |
| sean-k-mooney | ok os domain caps also has this info now for the cpu models | 17:05 |
| sean-k-mooney | so if you cofnigured a custom cpu model and its deprecated we could perhaps warn on startup | 17:05 |
| sean-k-mooney | the implication of it being deprecated is it may be removed in the next major release of your OS | 17:06 |
| sean-k-mooney | or i guess technially the next major release of libvirt/qemu but realisticaly i think distros would not do the removal in a minor release | 17:06 |
| sean-k-mooney | so proably only on major release of the distro | 17:07 |
| gibi | dansmith: yeah we can be smart and log one warning per deprecated type with a list of instance uuid using it | 17:08 |
| dansmith | gibi: ack, but I also think it would be nice to log on instance boot if we haven't complained about that type yet | 17:08 |
| dansmith | in which case the list would only be one (so far) | 17:09 |
| sean-k-mooney | i dont knwo if livbirt supprt thsi deprecation annochment for other things | 17:10 |
| sean-k-mooney | like is deprecated valid for the supprot video models in teh domcaps api for example | 17:10 |
| gibi | dansmith: yeah why not both :) | 17:11 |
| sean-k-mooney | it might be good for us to reach out and see what there advice is for management applications to consume this info | 17:11 |
| sean-k-mooney | ok we dont have to design this now but maybe somethign for the ptg or next cycle | 17:13 |
| gibi | I'm supportive | 17:14 |
| bauzas | dansmith: thanks for your comments, WDYM by mirroring dict.items() ? https://review.opendev.org/c/openstack/nova/+/940642/5/nova/objects/base.py#183 | 17:19 |
| dansmith | bauzas: you're returning [(key, value), (key,value)] right? | 17:19 |
| bauzas | yeah but by a set | 17:20 |
| dansmith | right, so my point is that's exactly like what dict.items() returns, so you might just name the property (or use a method) "items" for parity/consistency | 17:20 |
| bauzas | ahah OK | 17:21 |
| dansmith | just an idea, not critical | 17:21 |
| bauzas | also, I think I'll use obj_to_primitive() for that, as I got https://6ae015e4c924496dfda3-74c26bb67ca36871e200d07f3210a3f0.ssl.cf1.rackcdn.com/940642/5/check/nova-multi-cell/c2a2f68/controller/logs/screen-n-sch.txt due to the fact I'd also want to modify a list | 17:22 |
| dansmith | ack | 17:22 |
| opendevreview | Merged openstack/nova stable/2024.2: ironic: Fix ConflictException when deleting server https://review.opendev.org/c/openstack/nova/+/940836 | 18:10 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add a new ImagePropertiesWeigher https://review.opendev.org/c/openstack/nova/+/940642 | 18:18 |
| mikal | sean-k-mooney: did you end up having any joy on your tempest SPICE thing? I tweaked the tempest test last night to address review comments, but I am not sure where exactly we're up to now. | 19:14 |
| mikal | Also melwitt if you're around, I'd appreciate a quick re-review on https://review.opendev.org/c/openstack/os-traits/+/940418. I think its good to go and it has a +2 from sean-k-mooney already. | 19:15 |
| gmann | mikal: I am going to check tempest/devstack changes soon after TC discussion | 19:29 |
| mikal | gmann: thanks | 19:31 |
| mikal | gmann: I assume you don't want to actually merge that tempest change until the microversion merges in nova though? | 19:31 |
| gmann | mikal: not strong opinion, as tests are capped with microversion those going to be skipped/not failed. I am ok to merge tempest test before nova change also or after whatever make things easy. | 19:36 |
| mikal | gmann: ok cool | 19:36 |
| gmann | I know you have made tempest change depends-on on nova change so that test results can be seen while review which is good dependency/ | 19:36 |
| mikal | What's the best way in the zuul output to verify the test actually run? I'm not entirely which file I should be searching for that. | 19:47 |
| MengyangZhang[m] | <MengyangZhang[m]> "understood, just curious in..." <- I may need some help with implementing the min version check. I have two ideas: | 19:51 |
| gmann | mikal: commented here, we need to change the tempest test regex in this job https://review.opendev.org/c/openstack/nova/+/940873/5/.zuul.yaml#173 | 19:54 |
| gmann | log/job-output.txt is where you can see the test running and how much time it takes https://zuul.opendev.org/t/openstack/build/afeee7c92cce46348341232a188427b3/log/job-output.txt | 19:54 |
| gmann | or testr_results.html for quick ref https://e287b5846f894c7179f4-83ee41d1d15b6e7c94a25488c54501c9.ssl.cf1.rackcdn.com/924844/34/check/nova-ovs-hybrid-plug/afeee7c/testr_results.html | 19:55 |
| MengyangZhang[m] | <sean-k-mooney> "the min compute service check is..." <- I may need some help with implementing this min version check. I have two ideas to do this:... (full message at <https://matrix.org/oftc/media/v1/media/download/Ae0l5EhUbL8JUTeIDS5kp_UoSmlV3GrnEtLP-mZf1daDKwZ50jd2VmhsVYhYto94LzR25EzQz3ob4XDZRrMgDthCeVPrH4jAAG1hdHJpeC5vcmcvVXVaelVtZEp1aU94WllHaU10Q0FlcndG>) | 20:00 |
| mikal | gmann: so yeah, either I am looking in the wrong place or the spice test isn't running in the job yet then... https://e287b5846f894c7179f4-83ee41d1d15b6e7c94a25488c54501c9.ssl.cf1.rackcdn.com/924844/34/check/nova-ovs-hybrid-plug/afeee7c/testr_results.html | 20:01 |
| mikal | That's the nova-ovs-hybrid-plug https://zuul.opendev.org/t/openstack/build/afeee7c92cce46348341232a188427b3 job for https://review.opendev.org/c/openstack/nova/+/924844 | 20:01 |
| mikal | I feel like 30 tests is a really low number too, like there's some test filtering happening that I haven't found yet or something. | 20:02 |
| mikal | Oh sorry, that's your regex comment above! | 20:03 |
| gmann | yeah, we need to change the regex | 20:03 |
| mikal | sean-k-mooney: do we feel like we should rename the nova-ovs-hybrid-plug job if it now does more than that/ | 20:04 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | 20:11 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | 20:11 |
| opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | 20:11 |
| sean-k-mooney | mikal: we can, that kind of my semi personal job. i created specifically to test non default deployment configuraiton focusing on ml2/ovs coverage wehn we change teh default in devstack to ovn | 20:27 |
| sean-k-mooney | mikal: so we can add spice or otherwise rename it if you like | 20:27 |
| sean-k-mooney | mikal: i choose that job becuase its the one i expected other to object to the least in terms of altering its scope | 20:28 |
| sean-k-mooney | mikal: i.e. other might be uncofrotabel movign the ceph job to debian but i didnt htink anyone would obejct to that one havign spcie in stead of vnc or debain ectra | 20:29 |
| sean-k-mooney | it also test live migration and cold migration ensurign that at least at the qemu level enablign spice does nto break that | 20:29 |
| mikal | Cool. I have to run for a bus now, but it sounds like I could propose a more generic name for that job when I get a chance. | 20:52 |
| sean-k-mooney | gmann: mikal oh it was the regex that skipped it | 20:58 |
| sean-k-mooney | ya we can change that but its currently diabling some test to keep the job time short | 20:59 |
| sean-k-mooney | and because we didn need to test them for the previous job scope | 20:59 |
| sean-k-mooney | thats why cidner and swift are disabled i did not want to deal with the cinder volume test flakynes | 21:00 |
| sean-k-mooney | the job is currenlty mainly to test move operations with ml2/ovs as i said but feel free to expand the test set to anyting you consider useful but ideally dont add addtioanl services unless its really needed | 21:01 |
| MengyangZhang[m] | <MengyangZhang[m]> "I may need some help with..." <- oh i think we can use the get_minimum_version function in service.py to find the min version of all hosts. | 21:10 |
| MengyangZhang[m] | <MengyangZhang[m]> "oh i think we can use the..." <- Do we know what would be the version number of 2025.2 release? | 21:48 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!