| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-01 | |||
| 10:29:37 | bauzas | it would be simplier for a new developer to just hook their dev machines into some zuul registery so they would just run a specific zuul job for installing devstack and its knobs | |
| 10:29:52 | sean-k-mooney | i wrote an ansibel molecule senairo | |
| 10:29:59 | bauzas | yeah I remember that | |
| 10:30:00 | sean-k-mooney | that uses the upstream zuul job roles | |
| 10:30:02 | sean-k-mooney | https://github.com/SeanMooney/ard/blob/master/molecule/default/molecule.yml | |
| 10:30:15 | bauzas | ideally, I'd just use the .zuul.yaml definitions | |
| 10:30:28 | sean-k-mooney | ya that is not possibel today | |
| 10:30:46 | sean-k-mooney | there was a propoal to do that with a thing called zuul-runner | |
| 10:30:59 | sean-k-mooney | clarkb: ^ that never actully happened right | |
| 10:31:01 | bauzas | interesting | |
| 10:31:09 | bauzas | I mean, don't get me wrong | |
| 10:31:50 | sean-k-mooney | bauzas: the idea was you would point it at zuul adn give it the proejct name ectra and give it some resouce to use and well it would run the zuul executor logic locally and run the job agaist those resoucs | |
| 10:32:09 | bauzas | the usecase I see here is that if dev contributors start using zuul roles for deploying their devstacks, they could get less effort in configuring devstack and installing it, but they could also give the money back by also contributing to the roles definitions | |
| 10:32:41 | sean-k-mooney | bauzas: if you have never done it zuul is actully pretty simple to run on your laptop with a singel docker-compoes up | |
| 10:32:50 | bauzas | for a newcomer, trying to untangle devstack (if their install failed) is somewhat tricky | |
| 10:33:15 | sean-k-mooney | it is but i still think its an exersise tehy should do to understand whot things work | |
| 10:33:21 | sean-k-mooney | but thats why i create the ard stuff | |
| 10:33:30 | bauzas | the more they'd stick to 'standard validated upstream roles', the better chances they have to get their nodes ready | |
| 10:33:32 | sean-k-mooney | did you know that devstack used to have a vagrant file | |
| 10:33:36 | bauzas | yup | |
| 10:33:42 | bauzas | I remember it | |
| 10:33:55 | sean-k-mooney | it might still exist | |
| 10:34:02 | sean-k-mooney | i never got it to work for what it wanted | |
| 10:34:58 | sean-k-mooney | so the stuff i have in the ard repo can be pointed at any host and it will give you a mulit node devstack | |
| 10:35:21 | sean-k-mooney | i used it to provisin some host in china form ireland for gibi when he first joined redhat | |
| 10:36:01 | sean-k-mooney | i was looking at a zuul job yesterday when the time stamps suddely went 5 hours into the past | |
| 10:36:21 | sean-k-mooney | when i realised zuul was running in the us east coast and the vms were in europe | |
| 10:36:55 | sean-k-mooney | i was pretty churffed that zuul/ansible works that well across an ocean | |
| 12:58:46 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add libvirt connection healtcheck https://review.opendev.org/c/openstack/nova/+/907424 | |
| 13:02:04 | opendevreview | Merged openstack/nova stable/2023.2: Revert "[pwmgmt]ignore missin governor when cpu_state used" https://review.opendev.org/c/openstack/nova/+/905672 | |
| 13:02:11 | opendevreview | Merged openstack/nova stable/2023.2: cpu: make governors to be optional https://review.opendev.org/c/openstack/nova/+/905673 | |
| 13:59:34 | bauzas | sean-k-mooney: fwiw, straight devstack install with GLOBAL_VENV=False worked like a charm with Centos 9 Stream | |
| 13:59:46 | bauzas | (ovn and all the likes) | |
| 13:59:55 | bauzas | no need to tweak anything | |
| 14:00:08 | sean-k-mooney | yep | |
| 14:00:15 | sean-k-mooney | centos 9 stream is a supproted distro | |
| 14:00:18 | sean-k-mooney | rhel is not | |
| 14:00:20 | bauzas | and good news, I checked that the nvidia GRID driver correcly works with latest C9S release | |
| 14:00:30 | sean-k-mooney | a lot of the check for rpm distos explcity dont check for rhel | |
| 14:00:37 | bauzas | that was my main concern ^ | |
| 14:00:49 | sean-k-mooney | ya | |
| 14:00:56 | sean-k-mooney | the kernels are close enouch that it should install | |
| 14:01:00 | sean-k-mooney | btu you never know | |
| 14:01:02 | bauzas | with mdev live migration, you need recent qemu and libvirt versions plus a recent kernel too | |
| 14:01:22 | bauzas | so I'm doublecheckign the versions now with the 30 Janth c9s build | |
| 14:01:58 | sean-k-mooney | i think we shoudlbe fine. centos 9 stream has new version of qemu and libvirt then rhel | |
| 14:02:11 | sean-k-mooney | but if you need even newer you can enabel the fedora virt preview repos | |
| 14:02:19 | sean-k-mooney | those have c9s builds too now | |
| 14:02:42 | sean-k-mooney | https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/ | |
| 14:03:07 | bauzas | libvirt-9.10 | |
| 14:03:30 | bauzas | qemu-kvm-common-8.2 | |
| 14:03:54 | sean-k-mooney | libvirt 10 came out 2 weeks ago but 9.10 is from novemeber | |
| 14:04:14 | sean-k-mooney | libvirt 10 is in the copr repo | |
| 14:04:29 | sean-k-mooney | 10.0.0-3 | |
| 14:04:41 | sean-k-mooney | and qemu 2:8.2.0-6 | |
| 14:05:34 | sean-k-mooney | i think you should be good with the version you have to be honest | |
| 14:20:29 | gibi | elodilles_afk: sean-k-mooney: thanks for the +2s on the powermgmt backports. This is the (hopefully) last set this time to Antelope https://review.opendev.org/q/topic:%22power-mgmt-fixups%22+branch:stable/2023.1 | |
| 14:48:20 | bauzas | sean-k-mooney: sorry was in meeting but yeah we're fine https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/libvirt-mdev-live-migrate.html#dependencies | |
| 15:54:47 | opendevreview | Fabian Wiesel proposed openstack/nova master: vmware: Integer division Python 2 -> 3 fix https://review.opendev.org/c/openstack/nova/+/907444 | |
| 17:12:52 | opendevreview | Sylvain Bauza proposed openstack/nova master: Augment the LibvirtLiveMigrateData object https://review.opendev.org/c/openstack/nova/+/904175 | |
| 17:12:53 | opendevreview | Sylvain Bauza proposed openstack/nova master: check both source and dest compute libvirt versions for mdev lv https://review.opendev.org/c/openstack/nova/+/904176 | |
| 17:12:53 | opendevreview | Sylvain Bauza proposed openstack/nova master: Check if destination can support the src mdev types https://review.opendev.org/c/openstack/nova/+/904177 | |
| 17:12:54 | opendevreview | Sylvain Bauza proposed openstack/nova master: Reserve mdevs to return to the source https://review.opendev.org/c/openstack/nova/+/904209 | |
| 17:12:54 | opendevreview | Sylvain Bauza proposed openstack/nova master: Modify the mdevs in the migrate XML https://review.opendev.org/c/openstack/nova/+/904258 | |
| 17:13:04 | bauzas | dansmith: just updated my series | |
| 17:13:44 | bauzas | about the edge cases of a failing migration that would leak the dict, I'm a bit puzzled on how to correctly test that | |
| 17:14:15 | bauzas | for sure I can add another functional test that would force a migration to break, maybe that would help but that would only check the case I already planned | |
| 17:15:19 | bauzas | actually this sounds doable, I'll come up with something | |
| 17:27:08 | sean-k-mooney | gibi: dansmith: related to the health check converstation. i alrady have a time stamp for when each healthcheck result was recorded so im just going to add one more timestamp for the overall responce | |
| 17:27:32 | dansmith | sean-k-mooney: cool | |
| 17:27:35 | dansmith | bauzas: ack | |
| 17:28:05 | sean-k-mooney | you could figure that out yourslef on the client side but that seams pretty trivial to do and it allow you one extra data point as a clinet, how long did the responce take to get to me | |
| 17:29:07 | sean-k-mooney | we expect this to mainly run on localhost so that should be instant but if its not then it might be useful | |
| 17:30:31 | sean-k-mooney | melwitt: did you push an update to your series by the way. i wont get to it today but ill try and take a look again tomorrow | |
| 17:31:26 | melwitt | sean-k-mooney: no not yet :( I will later today | |
| 17:31:34 | sean-k-mooney | no rush | |
| 17:45:41 | opendevreview | Sylvain Bauza proposed openstack/nova master: check we don't leak in the func test https://review.opendev.org/c/openstack/nova/+/907465 | |
| 17:45:56 | bauzas | dansmith: made the functest, proofing we don't leak ^ | |
| 17:46:27 | bauzas | I'll rebase my series by squashing that one with the change in question | |
| 17:47:28 | opendevreview | Sylvain Bauza proposed openstack/nova master: Reserve mdevs to return to the source https://review.opendev.org/c/openstack/nova/+/904209 | |
| 17:47:28 | opendevreview | Sylvain Bauza proposed openstack/nova master: Modify the mdevs in the migrate XML https://review.opendev.org/c/openstack/nova/+/904258 | |
| 17:47:33 | bauzas | there we go | |
| 18:06:31 | clarkb | sean-k-mooney: no there isn't a good way to run zuul jobs locally | |
| 18:06:57 | clarkb | sean-k-mooney: this is why tools like tox and nox and make etc are valuable and honestly good ideas regardless of your CI system | |
| 18:23:03 | sean-k-mooney | clarkb: well we would not remove them evn if we coudl run zuul jobs locally | |
| 18:24:03 | clarkb | sure, btu if those tools work properly you reduce a lot of problems | |
| 18:24:14 | clarkb | and the problems with not disabling selinux don't go away running a zuul job locally | |
| 18:24:42 | sean-k-mooney | hehe well that is just because bauzas is using an os that is not supported by the too he was trying to od | |
| 18:25:11 | sean-k-mooney | the devstack is_fedora check i think works for centos and rhel but we have other check that check for fedora and centos by name | |
| 18:25:48 | sean-k-mooney | there are docs that tell you to use specific function in devstack to do this but perople done alwasy follow the docs even if they wrote them :) | |
| 18:28:14 | clarkb | more generally there is a balancing act between being so tied to your CI system that the software only really works there and ensuring the software is generally deployable | |
| 18:28:31 | clarkb | a common place we see this is people updating devsatck job vars rather than setting appropriate defaults in devstack proper | |
| 18:28:46 | clarkb | and we should try and avoid those tendencies and ensure the software can stand on its own | |
| 18:29:05 | sean-k-mooney | selunx disbaling is done here https://github.com/openstack/devstack/blob/5c1736b78256f5da86a91c4489f43f8ba1bce224/tools/fixup_stuff.sh#L38-L43 garded by is_fedora so that hsoudl have worked | |
| 18:30:29 | clarkb | where "run this zuul job locally" is potentially useful is determining why builds have failed | |
| 18:30:37 | clarkb | it is less useful as a "run our software" option | |
| 18:32:54 | sean-k-mooney | clarkb: so the issue is i have been using devstack for so long now that i rearly have issues and i can fix them pretty quickly when i do | |
| 18:33:53 | clarkb | yup, we end up with blinders and biases. I'm just saying that in this situation I feel ike the problem exist in devstack and not a lack of tooling in zuul | |
| 18:39:44 | sean-k-mooney | zuul jobs can be wriite so tehy are runablle locally | |
| 18:39:53 | sean-k-mooney | they are just ansible after all | |