| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-01 | |||
| 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 | |
| 18:40:26 | sean-k-mooney | the only thing tha tmakes that hard with our devstack ones is bascilly a meta palybooks to run all the pre/post playbooks in the write order | |
| 18:41:00 | sean-k-mooney | if you coud trivially gerneate that you and the inventory you could jus tupdate the ips and run it agaisnt your own vms | |
| 18:41:53 | sean-k-mooney | in the molecule senario and playbooks i worte in my ard repo i basically just did that | |
| 18:42:30 | sean-k-mooney | i reused the roles and statically combined themn to give me somethign pretty close to the upstream jobs | |
| 18:48:27 | clarkb | right. I'm basically asserting that needing to resort to that for users to run devstack is a bug though | |
| 18:48:36 | clarkb | and we should try and make the tool easier to use rather than make CI a stand in | |
| 19:21:25 | sean-k-mooney | right but devstack is not hard to use | |
| 19:22:13 | sean-k-mooney | all the issue bauzas hit where tyring to use it in unsupproted ways (an os that is not supproted after starting in a mode that is not supproted on its nearest supproted cousin) | |
| 19:42:55 | sean-k-mooney | dansmith: i have a terible idea. | |
| 19:43:03 | dansmith | yeah? | |
| 19:43:16 | sean-k-mooney | the dbcounter uses a plugin https://opendev.org/openstack/devstack/src/branch/master/tools/dbcounter/dbcounter.py | |
| 19:43:50 | sean-k-mooney | do you think i could create one for the healthchecks to detect if a conenction resets and is reestablished | |
| 19:44:35 | sean-k-mooney | would that be an insane thing to do even look into or something to condier | |