| opendevreview | Merged openstack/nova master: Follow ironic job rename https://review.opendev.org/c/openstack/nova/+/983080 | 01:05 |
|---|---|---|
| tafkamax | Hi gurus, arm64 computes are possible, but is it possible to use macos host as an nova-compute node? I can't seem to find any info on this. | 07:49 |
| tafkamax | or would that fall under the "baremetal" category? | 07:49 |
| tafkamax | https://wiki.openstack.org/wiki/HypervisorSupportMatrix | 07:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/2026.1: Follow ironic job rename https://review.opendev.org/c/openstack/nova/+/983166 | 07:56 |
| gibi | elodilles: ^^ | 07:56 |
| sean-k-mooney | gmaan: we ca actually juse create a repo local variant of the job in the check pipeline definition | 07:58 |
| sean-k-mooney | gmaan: but it pased on a recheck and the job otersize looks ok so lets just keep an eye on it for now | 07:59 |
| sean-k-mooney | if we see the heat test being an issue going forward we can look to disable them | 07:59 |
| sean-k-mooney | tafkamax: no but it is possible to use debian on apple silicon and install openstack on taht | 08:00 |
| sean-k-mooney | tafkamax: macos is not supproted regardless fo the architecture | 08:00 |
| sean-k-mooney | tafkamax: but i have run devstack on an m1 mac book air with 8GB of ram on baremetal with debina and ran tempest | 08:01 |
| sean-k-mooney | so if you have a bunch of mac minis or ultras you coudl use them as compute if you install linux on them | 08:02 |
| sean-k-mooney | we obviously dont test that however | 08:02 |
| tafkamax | ok thanks for the quick response :)! | 08:07 |
| tafkamax | but m1 doesnt support nested virt, so each node would be tied to like a single resource, correct? | 08:11 |
| tafkamax | or like a single instance in that sense? | 08:11 |
| sean-k-mooney | no on m1 you end up just using qemu without kvm | 08:17 |
| sean-k-mooney | on later apple silicon you can use full kvm i belive | 08:17 |
| sean-k-mooney | we have no supprot for macos guest in nova or using the macos viruatliation like utm or paralles | 08:18 |
| sean-k-mooney | part of the issues macos ships a version of python that is too old | 08:18 |
| sean-k-mooney | you can install a diffevent version via nix or brew | 08:19 |
| sean-k-mooney | but we do not have a virt driver that woudl work on macos today since i dont think libvirt supprot macos | 08:19 |
| sean-k-mooney | hum well https://libvirt.org/macos.html | 08:20 |
| sean-k-mooney | maybe | 08:20 |
| sean-k-mooney | tafkamax: you proably could get it to work with a littel effort | 08:20 |
| sean-k-mooney | although your next problem woudl be neutron | 08:21 |
| sean-k-mooney | ovs wont work on macos | 08:21 |
| sean-k-mooney | litrally before we added python 3 supprot there as an effort to make freebsd work but that died out 10 years ago | 08:22 |
| sean-k-mooney | the only neutron driver that might work woudl be the macvtap driver | 08:23 |
| sean-k-mooney | and that effectivly unmaintaiend | 08:23 |
| sean-k-mooney | so unless you go linux on m2+ i dont see a path to kvm/hardware virt supprot | 08:24 |
| tafkamax | ok thx for info | 08:24 |
| opendevreview | Kamil Sambor proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | 10:03 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet with threading in novncproxy https://review.opendev.org/c/openstack/nova/+/976089 | 10:03 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Change nova-alt-configurations job https://review.opendev.org/c/openstack/nova/+/983179 | 10:03 |
| opendevreview | Kamil Sambor proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | 10:05 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet with threading in novncproxy https://review.opendev.org/c/openstack/nova/+/976089 | 10:05 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Change nova-alt-configurations job https://review.opendev.org/c/openstack/nova/+/983179 | 10:05 |
| *** lumir is now known as shaolin_ | 11:50 | |
| gibi | JayF: o/ would NoVNCConsoleTestJSON tempest tests work in an job with ironic virt driver, like in ironic-tempest-bios-ipmi-autodetect ? https://github.com/openstack/tempest/blob/9307558eb0a4248fbbc02b9489132b6156ffef61/tempest/api/compute/servers/test_novnc.py#L26 | 14:28 |
| gibi | I'm asking this as we are touching stuff in that codepath here https://review.opendev.org/c/openstack/nova/+/955915 and it would be nice to see if this does not break ironic novnc integration | 14:29 |
| JayF | gibi: stevebaker or TheJulia might know a thing about that | 14:59 |
| JayF | gibi: I ping'd steve in the Ironic channel | 15:00 |
| TheJulia | I’m basically out today, but I can look tomorrow. I think Steve is out due to the holiday as well. | 15:01 |
| gibi | thanks. it is not urgent. | 15:02 |
| TheJulia | That being said, I think we exercise it in the gate job now so changes shouldn’t break it, but I can look deeply when not sitting in a doctors waiting room | 15:02 |
| gibi | enjoy your time off | 15:02 |
| TheJulia | Eh, not a fun day off :( | 15:02 |
| gibi | ohh, sorry :( | 15:03 |
| TheJulia | But thanks! | 15:03 |
| gibi | so far I haven't find an ironic job where the result contained the vnc test cases but mabye I'm looking at the wrong way | 15:03 |
| JayF | gibi: I'd say this, especially this early in the cycle: put up a depend-on change in Ironic, if our CI passes and you broke us, that's an us problem and we have months to unearth it | 15:07 |
| gibi | JayF: OK, I can do that easily. Thanks for the idea | 15:11 |
| sean-k-mooney | gibi: do we have new resulte with teh autotest job | 15:44 |
| sean-k-mooney | *autodetect job | 15:44 |
| sean-k-mooney | when i was review ign the nova patch i had to manually trace it as it was not easy to prove that it worked otherwise | 15:45 |
| gibi | sean-k-mooney: yes we have | 15:45 |
| gibi | but that job does not include the tempest vnc test | 15:45 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/build/0a8f54843e134d21afe261089421c5ad | 15:45 |
| gibi | hence my above disucssion with th eironic folks | 15:45 |
| sean-k-mooney | that sound like a regression becuase it used too | 15:47 |
| sean-k-mooney | maybe that was before we dorped the depns on ectra | 15:48 |
| sean-k-mooney | i did review at least one tempet run which i tough was on th enova patch wit it workign end ot end before | 15:49 |
| sean-k-mooney | gibi: https://review.opendev.org/c/openstack/ironic/+/983219/1 did you push an entirly empty commit? | 15:56 |
| sean-k-mooney | in gerrit that litcally only has a commit message for me | 15:56 |
| sean-k-mooney | it did tirgger jobs in anycase im jsut wonderign if that is a gerrit rendering bug | 15:57 |
| gibi | sean-k-mooney: it is an empty commit yes | 15:58 |
| gibi | I can update that to have some change in it | 15:58 |
| sean-k-mooney | no need | 15:58 |
| sean-k-mooney | i just didnt know you coudl have entirly empty commits | 15:59 |
| gibi | git by default rejectes it but you can use --allow-empty :) | 15:59 |
| sean-k-mooney | oh ok | 15:59 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/942528/comments/42b2fbf7_78b47e56 was where i taced this before by th eway | 16:00 |
| sean-k-mooney | so in the past tempest was callign the console | 16:01 |
| sean-k-mooney | no matches in the autodetect version | 16:02 |
| sean-k-mooney | gibi: ok https://github.com/openstack/ironic-tempest-plugin/commit/29cd41eb3659138baa8d3eab06797fe2189ac7dc | 16:07 |
| sean-k-mooney | the test was reverted so we need ot unrevert it | 16:07 |
| sean-k-mooney | or rever tthe nova feature for partity :P | 16:07 |
| gibi | :P | 16:08 |
| sean-k-mooney | so you shoudl be able to test it with a ~DNM to nova with a depens-on to https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/982077 | 16:10 |
| sean-k-mooney | or a dnm on that repo with a depens on agains the nova change either way works | 16:11 |
| sean-k-mooney | actully no | 16:13 |
| sean-k-mooney | well. that does not appre to currenlty be runign the test as a sperate test | 16:13 |
| sean-k-mooney | it might be part of ironic_tempest_plugin.tests.scenario.test_baremetal_basic_ops.BaremetalBasicOpsAndRescue | 16:14 |
| sean-k-mooney | as a sideffect | 16:14 |
| sean-k-mooney | ill check but this shoudl be a sperate test so its clearly visabel in the tempest report | 16:14 |
| sean-k-mooney | ok its embded in the largere test not its own thing... | 16:15 |
| sean-k-mooney | which was partly why it was so hard to debug before | 16:15 |
| sean-k-mooney | gibi: on second tought this sound like a next week us problem. i left a -1 on the ironic-tempst-patch since it currenly not actully validating the console works | 16:22 |
| gibi | Thanks. | 16:24 |
| gibi | It is definitely not earlier than next week us problem for me ow | 16:24 |
| gibi | now | 16:24 |
| sean-k-mooney | im checkign ont thing while im at it | 16:25 |
| sean-k-mooney | we had 2 jobs in diffent pipelien one was testign with ironic sharding | 16:25 |
| sean-k-mooney | and the other was testing without it to make sure both work | 16:26 |
| sean-k-mooney | ok this one does not have the shared key defiend so hopefully our other ironic job still does | 16:26 |
| opendevreview | Clif Houck proposed openstack/nova master: [WIP] perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup (B6) https://review.opendev.org/c/openstack/nova/+/980676 | 16:27 |
| sean-k-mooney | ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa | 16:27 |
| opendevreview | Clif Houck proposed openstack/nova master: perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup (B6) https://review.opendev.org/c/openstack/nova/+/980676 | 16:28 |
| sean-k-mooney | ah its ironic-tempest-ipa-wholedisk-direct-tinyipa-multinode-shard | 16:29 |
| clif | JayF: sean-k-mooney ^ I cleaned up that commit a bit and now tests pass for me locally. The change looks reasonable to me and I'm somewhat convinced that it provides a speedup | 16:29 |
| sean-k-mooney | and that in the weekly perodic | 16:29 |
| sean-k-mooney | ack so you pulled that out onto master directly cool | 16:31 |
| clif | yep | 16:31 |
| clif | unit tests needed a small change to pass due to new arguments to expected calls | 16:31 |
| clif | my caveat is I'm still very new to the nova codebase in general | 16:32 |
| sean-k-mooney | ah makes sense | 16:32 |
| sean-k-mooney | this likely need more test coverage but did you have a chace to do any manual testing of this with a real or simulated ironic? | 16:32 |
| sean-k-mooney | jay mention there is a db simulator thing in ironic but i didnt have a change to dig into it | 16:33 |
| clif | I haven't done manual testing with it no, I can take a closer look at test coverage | 16:33 |
| sean-k-mooney | we liekly dont need/want the simulator in this change but we might want to add some simpel unit test that create a repesteive provide tyree cache with 1, 10, 100 nodes and do some very simple scale tests | 16:35 |
| JayF | going from "working ironic devstack" -> "working ironic devstack with lots of fake driver nodes" is trivial by hand | 16:36 |
| JayF | I am actually working today on hooking it up via devstack config | 16:36 |
| sean-k-mooney | oh cool | 16:36 |
| sean-k-mooney | so that should be simpler to tst we litclly jsut need to stop and start nova and see how long it take to compelte if so | 16:37 |
| sean-k-mooney | nova -> the nova-compute | 16:37 |
| JayF | yeah | 16:37 |
| JayF | honestly the culture here has always seemed to only count proof if it runs in CI | 16:38 |
| JayF | so I wans't even going to attempt a manual test | 16:38 |
| sean-k-mooney | well yes if its not in ci we assume its broken | 16:38 |
| sean-k-mooney | but i jsut wanted to be sure we saw a speedup before we spent too much time on this | 16:38 |
| sean-k-mooney | i.e. to make sure it really not a test artifact | 16:38 |
| sean-k-mooney | so a one of manual test to confirm build confindence in the aproch | 16:39 |
| clif | I don't mind attempting manual testing, I will say the change logically makes sense to me. Doing less work should *almost* always result in a speed increase | 16:42 |
| sean-k-mooney | clif: yep what im hoping the manaul test will show is how big or small this is to the overall tiem | 16:42 |
| sean-k-mooney | in a real system | 16:42 |
| sean-k-mooney | the next speed up to try woudl be hte mutli threading patch | 16:43 |
| sean-k-mooney | those are where i think most of it will come form | 16:43 |
| sean-k-mooney | out of the inifally few | 16:43 |
| clif | yep, thats the one I want to look at next | 16:43 |
| JayF | my downstream wanted to pull down that multithreading patch yesterday and I told em to wait for clif :D | 16:43 |
| JayF | event-based updates for ironic node provision state is apparently a real need for them; it can take 20-30 minutes post-cleaning for a node to return to inventory | 16:44 |
| clif | yea that's... not ideal to say the least | 16:44 |
| sean-k-mooney | clif: for what its worth we often do add context like this to commti message if we have the data | 16:46 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/427145 | 16:46 |
| sean-k-mooney | its not really ment to be a rigorus test jsut indicitive | 16:46 |
| sean-k-mooney | JayF: i need ot understand the delay there more but not today | 16:47 |
| JayF | that periodic has to complete | 16:48 |
| JayF | one of the big ones that are kinda awful on ironic | 16:48 |
| sean-k-mooney | well it shoudl not really depend on that | 16:48 |
| JayF | that's what I wanna fix :D | 16:48 |
| sean-k-mooney | so i want to understand why | 16:48 |
| JayF | same, I haven't gotten there yet | 16:48 |
| JayF | and mostly am asking clif to get there :D | 16:48 |
| sean-k-mooney | becuase when a node is cleanign it placement recouse provider shoudl jsut have reserved=total for the baremetal resocue class | 16:48 |
| sean-k-mooney | but ironic can just set reserved back to 0 directly in placment when its done cleaning and its in the aviable state | 16:49 |
| JayF | yeah, we don't do ANYTHING with placement now | 16:49 |
| sean-k-mooney | so i just want to make sure we are not doing somethign dumb like recreating the RP and deleteing it based on the state | 16:50 |
| sean-k-mooney | oh ok | 16:50 |
| sean-k-mooney | so it relying on nova to poll ironic exclusivly | 16:50 |
| JayF | yeah this is the stuff I was talking about for fixing for Ironic | 16:50 |
| JayF | yep | 16:50 |
| sean-k-mooney | and notice that the state has moved to avaible and we update it | 16:50 |
| JayF | there are lots of opportunities for ironic to push via nova events api and/or talk to placement directly | 16:50 |
| sean-k-mooney | ack ya | 16:50 |
| sean-k-mooney | we can talk about that more whewn we both have more time | 16:50 |
| sean-k-mooney | there defintly ways to short circut the perodic | 16:51 |
| melwitt | dansmith, sean-k-mooney: I dunno if one of yall could help but there are a couple of patches needing a second +2 to start vtpm live migration testing in CI, devstack https://review.opendev.org/c/openstack/devstack/+/958254 and nova https://review.opendev.org/c/openstack/nova/+/978841 | 16:54 |
| melwitt | on the devstack one mdevctl is included and IIRC it was something maybe sean had suggested on IRC to include but I don't think it's needed for vtpm. I can remove it if desired | 16:55 |
| sean-k-mooney | sure i can look at them now | 16:56 |
| sean-k-mooney | im pretty sure i have looked at or asked you about hte devstack one before | 16:56 |
| melwitt | yeah same. thanks | 16:57 |
| sean-k-mooney | do we also need https://review.opendev.org/c/openstack/devstack/+/968114 ? | 17:02 |
| melwitt | oh hm, checking, I forgot about this one | 17:03 |
| sean-k-mooney | https://review.opendev.org/c/openstack/devstack/+/968114/comment/fdbb7370_567faacf/ | 17:05 |
| sean-k-mooney | so that will work but only on single node | 17:05 |
| melwitt | I can't remember why I did that, must have been before I realized it wasn't needed | 17:05 |
| melwitt | I don't find any patches that depends-on this | 17:05 |
| sean-k-mooney | if we want to be able to enable this on a compute (without barbican) we woudl have to have a flag | 17:05 |
| sean-k-mooney | ack | 17:05 |
| sean-k-mooney | so the nova job you worte | 17:06 |
| sean-k-mooney | is using barbican on the contoler | 17:06 |
| sean-k-mooney | but disbaeld on the compute as we would expect | 17:06 |
| sean-k-mooney | i wonder are we using the castalan optiosn or something for the key manager | 17:06 |
| sean-k-mooney | melwitt: meta question is there a reason not to put this into nova-next or nova-alt-config? | 17:07 |
| melwitt | it is using castellan but I don't remember where it's defaulted to that | 17:07 |
| sean-k-mooney | we can move this testing later by the way im jsut confiming | 17:08 |
| melwitt | sean-k-mooney: it requires nested virt in order to work, so I think I was likely thinking to make as small and short a job as possible to not have as much contention | 17:08 |
| sean-k-mooney | ok i was thinking of movign the nova-next job ot use nested virt a while back | 17:09 |
| melwitt | i.e. a longer job that requires nested virt will tie up the limited CI nodes that support nested virt | 17:09 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/build/82adf7b225984621891eae9f930ba6ab/log/compute-host/logs/etc/nova/nova-cpu_conf.txt#59 | 17:09 |
| sean-k-mooney | so i can see the backend is set correctly | 17:09 |
| sean-k-mooney | but we do not have a barbican section defiend | 17:10 |
| sean-k-mooney | oh | 17:10 |
| sean-k-mooney | i know why | 17:10 |
| sean-k-mooney | melwitt: so today we are usign the user token to talk to barbican | 17:10 |
| sean-k-mooney | we only need that config secton for the deployment mode | 17:11 |
| sean-k-mooney | and that not merged yet | 17:11 |
| sean-k-mooney | my expection is we are currently just lookign up the barbican endpoing form teh tokens service catalog | 17:12 |
| melwitt | I think maybe it was that we settled on using the [service_user] config section instead | 17:12 |
| sean-k-mooney | an no | 17:12 |
| sean-k-mooney | well as a fallback | 17:12 |
| sean-k-mooney | but not as the primay | 17:12 |
| melwitt | because there are no patches currently depends-on it so it's not being used by the patches I have up that are testing deployment mode | 17:12 |
| melwitt | it is the primary, there was a lot of discussion on it and that's where we ended up | 17:13 |
| sean-k-mooney | have we merged that because i feel like i have have proably be -1.5 on that if i was invoveld | 17:14 |
| melwitt | comment thread here https://review.opendev.org/c/openstack/nova/+/942021/45/nova/context.py | 17:14 |
| melwitt | yeah it's merged | 17:14 |
| sean-k-mooney | we shoudol not be suign the service_user section to tlak to barbicn or any ohter service in my opinion | 17:14 |
| melwitt | why do I always work on the most controversial stuff (haha) this and ephemeral encryption I swear everyone has a different opinion | 17:15 |
| sean-k-mooney | we cant assume that barbican is in the same region for one | 17:15 |
| melwitt | I mean ... if [service_user] is meant to talk to all of the services, how can it do that if the region isn't the same? that section is used for all the service token stuff | 17:17 |
| sean-k-mooney | its not | 17:17 |
| melwitt | "send_service_user_token = True" ? | 17:17 |
| sean-k-mooney | service user is for one thing and one thinkg only generating a service token to do lifetime exstions fo the user/admin token | 17:17 |
| sean-k-mooney | yes | 17:18 |
| melwitt | yeah, I know. I think all of that is discussed in the thread | 17:18 |
| sean-k-mooney | right so usign it to create a user token for nova is not ok | 17:18 |
| melwitt | personally, I don't really care which section it was but I tried re-using the other ones and it failed massively. so it's either [service_user] or we make a new [barbican] section | 17:19 |
| sean-k-mooney | yep we shoudl have a new barbican section | 17:19 |
| sean-k-mooney | that expclity what im suggeting | 17:19 |
| melwitt | yeah, and I did propose that but I can't remember how it got disagreed about | 17:19 |
| sean-k-mooney | i would prefer if that was also a hard requiremt to use this | 17:20 |
| sean-k-mooney | i.e. make it an error to have deployment enable and not ahve the barbican section defiend if the backend is set to barbican | 17:20 |
| melwitt | I guess we could still change it given that we don't support 'deployment' live migration yet and so it's left out of the docs for now | 17:21 |
| sean-k-mooney | its not to late to fix this we dont ahve any code usign yet right looking at the serises | 17:21 |
| melwitt | but I really need people to get on the same page and agree because this majorly sucks for me | 17:21 |
| melwitt | I'll add it as a ptg topic, since that's happening soon anyways | 17:22 |
| sean-k-mooney | i was also talkign to gmaan about incorrect use fo service tokens in other project | 17:22 |
| sean-k-mooney | we caught an unintiall issue with glance/cidner very close to the ff | 17:23 |
| sean-k-mooney | we also need to envutaly clean up the workaroudn we have in cinder for voluem attafchments | 17:23 |
| sean-k-mooney | i think gmaan wanted to write ups some docs on this to calrify a few thing but i might be miss rememebrign | 17:24 |
| melwitt | ack | 17:24 |
| sean-k-mooney | we do have a barbical sectionin our cofnig by the way | 17:46 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#barbican | 17:46 |
| gmaan | sean-k-mooney: here is summary on that but yes as melwitt said we can discuss it in PTG also and I can work on document on what to use when (once we all agree on it) | 17:50 |
| gmaan | keystone_authtoken: is used only at API layer so vTPM usage is from nova compute so it is not possible to use in this case. | 17:50 |
| gmaan | barbican user: if i am not wrong here, vTPM secrets are owed by nova service user not barbican service user so user configured in barbican section is not suitable to use in vTPM. That is my understanding during that discussion . melwitt correct me if that is wrong. | 17:52 |
| sean-k-mooney | the user configred in teh barbicna section shoudl be nova | 17:52 |
| sean-k-mooney | it shoudl nto be barbican | 17:52 |
| gmaan | why | 17:52 |
| sean-k-mooney | because nova shoudl never have the user/password fo another service | 17:52 |
| gmaan | it should be barbican given user to nova so that nova can talk to barbican. same as nova service user is configured in cinder conf nova section | 17:53 |
| sean-k-mooney | that is one of our security hardign recommedation and someitn we have been plannign to fix in devstack for a while | 17:53 |
| sean-k-mooney | gmaan it is the user thant nova shuodl use to talk to barbcina yes. conventionally nova but it can be any user and that is the user who shoudl own the secret | 17:53 |
| sean-k-mooney | whaterver there name maybe | 17:54 |
| gmaan | 1 sec, I think i mixed it | 17:55 |
| sean-k-mooney | i condire it incorect to use the service_user section to create the primary token for any request period | 17:56 |
| gmaan | yes, barbican section should have nova service user. i saw the devatack example which are all mixedup | 17:57 |
| gmaan | let me check comments again why we did not use barbican section | 17:58 |
| sean-k-mooney | its because fo castalan | 17:58 |
| sean-k-mooney | i think | 17:58 |
| sean-k-mooney | i need to doubel check | 17:58 |
| sean-k-mooney | we have both a barbican and barbican_service_user section today | 17:58 |
| sean-k-mooney | barbican is almost complete but its not the full set of keystone auth options | 17:59 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#barbican-service-user | 17:59 |
| sean-k-mooney | the option are splict between the two sectiosn today | 18:00 |
| sean-k-mooney | https://github.com/openstack/nova/blob/653f7a42d0c9db126c0d5eb94af8945732f68d72/releasenotes/notes/deprecate-barbican-config-options-68ae65643ac41e2f.yaml#L4 | 18:01 |
| gmaan | right, becauwe of castalan. so if itis from API interaction only them keystone_authtoken is right section which has the nova user but when it is way wider than just API, service_user is the only nova service user exist to use | 18:04 |
| sean-k-mooney | right which we cant use | 18:04 |
| sean-k-mooney | so we need a new section be it barbican_client or we use teh castalan options | 18:04 |
| gmaan | i know that is what i mentioned in your discussion also, we need to get an agreement on which one to use when, but in current design what other option we have? | 18:05 |
| sean-k-mooney | so i dont think we shoudl provceed with the current design | 18:05 |
| sean-k-mooney | the option are use both sectionvs form castalan or add a new barbican_client option or fix the option in castalane so that the brbican options are not splict | 18:06 |
| sean-k-mooney | fixing castalan would be my prefernce | 18:06 |
| sean-k-mooney | then we can just use the barbican section dirctly | 18:06 |
| gmaan | yeah, if we fix the castalan or add a new section then we can use but i feel we need to make a general agreement on 'why not to use service_user' | 18:09 |
| gmaan | one use case of that is for token expiry which can be send along with user token but also a user to interact other serviecs if nova compute (other than API) service want | 18:10 |
| sean-k-mooney | because it only for token lifecycle exteion and we need to be able to have diffent CA/region/users configured for every service we talk too | 18:10 |
| sean-k-mooney | i know there is an assumtion in general that the service_user user will have the service role and or admin role | 18:11 |
| sean-k-mooney | but we cant actully rely on that | 18:11 |
| gmaan | i agree for that. here specific case if comoute service want to talk where our existing normal service users per service section does not work | 18:11 |
| gmaan | bcz they are registered and tied at API service level for example keystone_authtoken | 18:12 |
| sean-k-mooney | per service section are not needed if we are suign a users token because we can use that tokens service catalong to find the endpoint | 18:12 |
| gmaan | anwyays, let'sa discuss it in PTG and see if we can get agreement | 18:12 |
| sean-k-mooney | although even the we do uses the cofnig sectoin to knwo which endpoithn we talk too | 18:12 |
| sean-k-mooney | ac | 18:13 |
| sean-k-mooney | ack | 18:13 |
| gmaan | accordingly I can work on some doc on that, which is what i mentioned to you about doc bcz it is not consistent and agreed | 18:13 |
| sean-k-mooney | anyway melwitt we got side tracked | 18:14 |
| sean-k-mooney | i approved the devstack patch | 18:14 |
| sean-k-mooney | i think once i look at the tempest resut im ok eot start ith the nova-vtpm job as seprate but i would really prefer to consoldiate it with nova-next or nova-alt-config i think in the future | 18:15 |
| melwitt | thanks sean-k-mooney | 18:23 |
| sean-k-mooney | so its currently runnign 3 live migrtiton tests https://ee4ee966b92d55ec0885-e7631c5842b30279943de651c580e67f.ssl.cf2.rackcdn.com/openstack/82adf7b225984621891eae9f930ba6ab/testr_results.html | 18:24 |
| sean-k-mooney | that usign the host policy right | 18:24 |
| sean-k-mooney | where we copy the secret over rpc | 18:25 |
| sean-k-mooney | and i assume we will have additoanl tempest test for deployment eventually with a new compute feature flag or a change to the tempest config to enable those later | 18:25 |
| melwitt | yes | 18:25 |
| melwitt | yes, those are proposed already bc what I did was split them out when we weren't going to get to merge deployment mode yet | 18:26 |
| sean-k-mooney | ack but they will need to be gated by a new flag in the compute_feature_flags in tempest or similar in whitebox | 18:27 |
| sean-k-mooney | becasue master tempet need to supprot the older branches i.e. 2026.1 | 18:27 |
| gmaan | yeah | 18:27 |
| sean-k-mooney | so we will eenither need to have a new config for the aviabel deployment modes | 18:27 |
| sean-k-mooney | and skip based on taht | 18:27 |
| sean-k-mooney | which woudl be my prefernce in this case since ist a list in nova | 18:28 |
| sean-k-mooney | or boolean values | 18:28 |
| sean-k-mooney | the reason im askign is becasue i dont see the poplicies defiend here https://review.opendev.org/c/openstack/nova/+/978841/6/.zuul.yaml#424 | 18:28 |
| sean-k-mooney | looks like tempest currently just has a bool for is it suprptoed at all https://review.opendev.org/c/openstack/tempest/+/957475/31/tempest/config.py | 18:30 |
| melwitt | ah it's bc during review we changed to make the parent job devstack-whitebox-multinode and they are set there already | 18:30 |
| sean-k-mooney | which is ok for now but we will need to evolve that | 18:30 |
| melwitt | *whitebox-devstack-multinode | 18:30 |
| sean-k-mooney | it also only hass a bool | 18:31 |
| sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/config.py#L371-L373 | 18:31 |
| sean-k-mooney | not which mode the host is in | 18:31 |
| sean-k-mooney | i guess | 18:32 |
| sean-k-mooney | from a pure tempest poitn of view it does not care | 18:32 |
| melwitt | yeah, since we split the policies we'll need a separate gate for the hibiscus ones. if it had not split we would just have the bool. but alas | 18:32 |
| sean-k-mooney | but we cant test both mdoes properly at the same time | 18:32 |
| sean-k-mooney | melwitt: so the point im tryign to make is we need to be able to test botht the case wehre nova owns the secrete | 18:33 |
| sean-k-mooney | and the case wehre the user does but we can copy it | 18:33 |
| melwitt | yeah I was thinking of the current config of the supported modes is in whitebox https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L109 so we didn't have to do it in the nova .zuul.yaml | 18:33 |
| sean-k-mooney | and i dont see how we can do that without either 4 nodes | 18:33 |
| sean-k-mooney | or reconfigurign the nova config | 18:33 |
| sean-k-mooney | we used ot reconfigure the nova config in whitebox and still can durign test but we tried to move aways form that for stablity reasons | 18:34 |
| melwitt | it currently works to test both modes so I'm not yet sure why we would need to change config but I'm sure i'm missing something | 18:35 |
| melwitt | (the proposed patches not yet merged works with both modes) | 18:36 |
| sean-k-mooney | ho do you knwo form one execution in a job where both deployment and host are allowed which the vm is using and how are you forcing that | 18:36 |
| melwitt | or is your point that that would change since H was cut? | 18:36 |
| sean-k-mooney | im saying we need to test with host mode (rpc copy) and with deployment mdoe secrest owned by nova) | 18:37 |
| sean-k-mooney | and we need to ensure that one or the other is used durign the migrtion | 18:38 |
| melwitt | there are currently separate tests for each mode and they both run in the same job, last I checked. I don't know if cutting the branch could have changed that | 18:38 |
| sean-k-mooney | without lookign at somting like debug messages | 18:38 |
| sean-k-mooney | oh they are forciign the mode via image properties | 18:38 |
| sean-k-mooney | sorry flavor extra specs | 18:39 |
| sean-k-mooney | not image proeprties | 18:39 |
| melwitt | yeah you have to select the mode | 18:39 |
| sean-k-mooney | right | 18:39 |
| gmaan | I think we are mixing the deployment mode testing in current changes. I have not reviewed/thoguht about deployment mode yet as those are not merged but host/user worked fine in existing tests/job | 18:39 |
| sean-k-mooney | gmaan: no i forgot that we can expicty set the mode in teh falvor | 18:39 |
| gmaan | ohk | 18:40 |
| sean-k-mooney | gmaan: we talked about haveing default per hsot and listing what each host can allow ectra in teh config | 18:40 |
| melwitt | 'user' currently is just verifying it's still blocked in the API but we were chatting about enabling live migration for 'user' if the API policy or secret ACLs would otherwise allow it | 18:40 |
| sean-k-mooney | and i was tryign to understand how a host that allows all 3 was tested spertaly with all 3 | 18:40 |
| melwitt | yeah, that got changed during spec review. no more choice on the default, 'user' is the only default | 18:40 |
| sean-k-mooney | right this is one of the thing that evovled | 18:41 |
| sean-k-mooney | and in the last ptg we entirlly remvoed the image options | 18:41 |
| melwitt | right | 18:41 |
| sean-k-mooney | becasue fo the resize isssues | 18:41 |
| sean-k-mooney | feels weeried that we chose the make it simpler option | 18:41 |
| sean-k-mooney | we shoudl do that more | 18:41 |
| melwitt | because rebuild is not implemented, so we didn't want to create a path where the user gets stuck with a mode and can't change it | 18:42 |
| sean-k-mooney | so i have been ocationally suggeting to james that we look at runign more of whitebox in nova-next this cycle | 18:43 |
| melwitt | if your image properties are locked-in (bc you can't rebuild), you will have a flavor/image conflict for resizes | 18:43 |
| sean-k-mooney | melwitt: yep i just had paged out that converstion | 18:43 |
| sean-k-mooney | ok after reviewign the whitebox code as well im ok with moving forward with this job for now | 18:44 |
| melwitt | yeah. it's been a long and complicated journey | 18:44 |
| sean-k-mooney | melwitt: before we add new test i woudl like to change the whitebox cofnig slightly so we list which polices are enabeld | 18:44 |
| sean-k-mooney | i think | 18:44 |
| melwitt | ok. yeah I was just thinking we merged all the tests and etc but no job running them so I figured maybe we want to go with that for now and then whatever happens this cycle I can adapt it | 18:44 |
| sean-k-mooney | and skip the relevent tests | 18:44 |
| sean-k-mooney | no its just user and host form what i saw | 18:45 |
| sean-k-mooney | when we add deployment without another way to know if it shoudl work it will block the 2026.1 branch | 18:45 |
| melwitt | right. and user is kind of a negative test, it just verifies that requests are rejected | 18:46 |
| sean-k-mooney | well i guess it wont but only because this job is not there | 18:46 |
| sean-k-mooney | but i assume we woudl liek to backport this job? | 18:46 |
| sean-k-mooney | to have coverage | 18:46 |
| melwitt | I have not heard anyone suggest that yet | 18:46 |
| melwitt | we have coverage by way of whitebox which IIRC runs as a periodic | 18:47 |
| sean-k-mooney | i mean its not hard to do and the test coverage would be valuabel but its not strictly requried | 18:47 |
| melwitt | this latest thing we are making it sort of an official nova thing I guess | 18:47 |
| sean-k-mooney | yes in the weekly perdic job | 18:48 |
| sean-k-mooney | but i dont think whitebox-devstack-multinode | 18:48 |
| sean-k-mooney | currently runs this test | 18:48 |
| melwitt | oh you mean since we missed the window in G. yeah that's true | 18:49 |
| sean-k-mooney | unless i missunderstood | 18:49 |
| melwitt | so yeah I guess we need to backport it. | 18:49 |
| sean-k-mooney | the host policy did merge before feature freeze adn is in 2026.1 right | 18:49 |
| melwitt | no you're right. I've just been brain fried | 18:49 |
| melwitt | yes | 18:49 |
| sean-k-mooney | ok cool. | 18:50 |
| sean-k-mooney | we could do this slightly diffently. | 18:50 |
| sean-k-mooney | we coudl move whitebox-devstack-multinode to check | 18:50 |
| sean-k-mooney | and update whitebox-devstack-multinode to run the vtpm test by default | 18:51 |
| sean-k-mooney | that woudl give us a weekly perodic on 2026.1 i think | 18:51 |
| sean-k-mooney | that getting to complciated | 18:51 |
| gmaan | tests are present in 2026.1 so yes job needs to be backported | 18:53 |
| gmaan | melwitt: sean-k-mooney: on service users/interaction standardization, I added separate topic than vTPM one added by melwitt so that we can discuss/audit rest all other cases also https://etherpad.opendev.org/p/nova-2026.2-ptg#L161 | 18:54 |
| melwitt | sounds good gmaan | 18:55 |
| gmaan | i will details later, feel free to add other case if i missed any | 18:55 |
| gmaan | outcome of that can be to write the agreed approachs in document | 18:55 |
| gmaan | I didn't want to mix it (as it has other cases also) in vTPM one so added as a separatetopic | 18:56 |
| melwitt | yeah I think that makes sense | 18:56 |
| gmaan | not sure which one we should discuss first but that we can figure out in PTG | 18:56 |
| melwitt | we could probably merge the topics, I could add mine as sort of concrete example | 18:57 |
| gmaan | ++ | 18:57 |
| sean-k-mooney | melwitt: i just +2w the nova-vtpm job wiht some notes | 18:57 |
| sean-k-mooney | so assuming the devstack patch merges it shoudl merge shortly there after | 18:58 |
| melwitt | cool, I'll move the vtpm topic under the general service user topic | 18:58 |
| melwitt | thanks sean-k-mooney | 18:58 |
| gmaan | on backport, along with backporting job, we need devstack backport also. | 18:59 |
| sean-k-mooney | one of the feature im implemnntign for cyborg this cycle si SRBAC | 18:59 |
| sean-k-mooney | so oen of the topic i was goign to have for the nova/cyborg session was how to evolve nova to talks to cyborg with service token in the future | 19:00 |
| sean-k-mooney | so we can like group that after the general service_user topic | 19:00 |
| gmaan | yeah, thast will be better | 19:01 |
| sean-k-mooney | it doesnt have to be back to back but we shoudl rsovle that first | 19:01 |
| gmaan | maybe somthing Uggla ^^ can do while scheduling or i can remind | 19:01 |
| sean-k-mooney | i dont think bookings have opened up yet | 19:02 |
| gmaan | slot booking? | 19:02 |
| sean-k-mooney | ut im goign to try and see of i can aovid to many conflicts between the nova watcher and cybrog tracks | 19:02 |
| sean-k-mooney | gmaan: ya the session request was a whiel ago | 19:03 |
| sean-k-mooney | but i have not recived the email fro bookign specific slot yet for cybrog | 19:03 |
| sean-k-mooney | but im expecting that to happen in the next week or so | 19:03 |
| gmaan | it is open, I am not sure there will be separate email for that? | 19:04 |
| gmaan | you can see booking happening in #openinfra-events | 19:04 |
| sean-k-mooney | i was told to expect one by sylvian but i guess i can check with allison | 19:04 |
| sean-k-mooney | ok i was waiting for a notifiction i gues i can figure that out next week then | 19:05 |
| gmaan | afaik, once team PTG booking is confirmed, you can book slot anytime | 19:05 |
| sean-k-mooney | ok i need to chnage the ether pad linkes that were auto created | 19:05 |
| gmaan | many projects already booked | 19:06 |
| gmaan | https://ptg.opendev.org/ptg.html | 19:06 |
| sean-k-mooney | ok i was specificly under the impression that the modeerators for each session would be notifed when we can start doing that | 19:06 |
| sean-k-mooney | looks like nova is not there yet ill sync with Uggla next week | 19:07 |
| gmaan | yeah | 19:08 |
| Uggla | sean-k-mooney, I'll book the slot tomorrow, because I'll be on PTO next wwek | 19:12 |
| sean-k-mooney | Uggla: what days were we thinking for the ptg | 19:13 |
| sean-k-mooney | i may have missed it but i was not sure that was dicsussed in the recent irc metting | 19:13 |
| Uggla | I thought about Tue --> Fri | 19:13 |
| sean-k-mooney | ack im condierign doing the actul cyborg ptg on monday or tudesday | 19:14 |
| sean-k-mooney | we coudl do the corss rpoejct session on one of the nova days | 19:14 |
| sean-k-mooney | wathcer is wednesday-friday | 19:15 |
| sean-k-mooney | althoguh firday is shorter due to the tc sessions | 19:15 |
| Uggla | yep expecting to close a bit earlier on friday. | 19:16 |
| sean-k-mooney | ok we can figure it out when your back form pto | 19:16 |
| sean-k-mooney | ill put in some temp cybrog slot on monday and tuesday for now and we can see fi there is a good slot free for the cross project when your back | 19:17 |
| Uggla | sure we will have 1 week to prepare. Right now we have few topics, but I'm pretty sure it will grow next week. | 19:17 |
| sean-k-mooney | i still ned to find time to prepare a small number fo high priroty topics | 19:18 |
| sean-k-mooney | just an fyi one of the things im goign to do is propse a very target spec to chate 2 things in the schduler one fo which si optional to maybe enabel cybrog to do numa in placment before nova does | 19:18 |
| Uggla | ok | 19:19 |
| sean-k-mooney | but i need ot find time to write that up but that was oging to be one of the topci i brought up | 19:19 |
| sean-k-mooney | the other would be the chagne needed to compelte vgpus with cybrog and how nova and cybrog talk to each other | 19:20 |
| sean-k-mooney | those are the 3 general teeme at least | 19:20 |
| sean-k-mooney | we might decied to push the numa topic to a future cycel btu we can see | 19:20 |
| Uggla | btw I don't know if we have requirments to set cross team session ? (beginning of the week ?) | 19:21 |
| sean-k-mooney | we dont but its often better to do | 19:22 |
| Uggla | maybe gouthamr knows about iy ^ | 19:22 |
| sean-k-mooney | historically trhey happend on monday | 19:22 |
| gouthamr | yes, monday and tuesday | 19:22 |
| sean-k-mooney | so we coudl do monday between 13-1500 | 19:22 |
| sean-k-mooney | before the tc session start | 19:23 |
| Uggla | yeah so maybe I'll book the full week and adapt later. | 19:23 |
| gmaan | Monday 15 - 18 UTC is I see the leader interaction sessions booked | 19:23 |
| gouthamr | we'll have to email blast this info: "Please try and schedule all cross project meetings at the beginning of the week, preferably by avoiding project-only sessions at the beginning of the week" | 19:24 |
| gouthamr | we can't get all of it, but, will be good to coordinate and attempt | 19:24 |
| sean-k-mooney | gmaan: ya the last 3 hours of that slot are the tc ones | 19:24 |
| gmaan | yeah | 19:24 |
| Uggla | gmaan got it, i'll avoid TC of course | 19:24 |
| sean-k-mooney | gouthamr: so taht can be a litte togh if you wnat to try and attend all or as much as possibel fo cybrog nova, watcher and tc seesions | 19:25 |
| gouthamr | always :( but we can try our best.. i think Monday for the TC will also be "forum" style - so we'll def address cross project stuff, even if all of it isn't "governance". I'm going to try to get some TC buy in for this | 19:26 |
| Uggla | sean-k-mooney, I see that as a trend to book x session first. | 19:26 |
| sean-k-mooney | gouthamr: im also tryign to decied if i want to bug a 00UTC slot or not | 19:27 |
| sean-k-mooney | for cybrog. | 19:27 |
| gouthamr | the "community leaders" session will likely be followed by an operators forum.. the specifics are tbd.. i'll also work with hberaud to get the "eventlet-removal" discussion scheduled, likely on tuesday for 1 hour instead of two | 19:27 |
| opendevreview | Clif Houck proposed openstack/nova master: perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup (B6) https://review.opendev.org/c/openstack/nova/+/980676 | 19:27 |
| gouthamr | sean-k-mooney: ah you might have some interest since past contributors have been from APAC | 19:28 |
| sean-k-mooney | gouthamr:right that why i was thinking of doing that on monday night and having the main seesion on tuesday | 19:28 |
| gmaan | gouthamr: i think monday 3 hrs is too much for cross projects in TC? unless you are accommodating eventlet kind of topics also | 19:29 |
| gmaan | bcz these 3 hrs will take most of the Monday slots so other cross projects things will be difficult to avoid conflict | 19:30 |
| gouthamr | gmaan: hmm, fair, i could cut that down to two hours if we don't have "cross project" impact. can i take until our next TC meeting (Tuesday) to decide? | 19:30 |
| gouthamr | if that happens, you folks get an extra hour.. if not, i'll promise it'll still be something you'll want to join and participate in | 19:31 |
| gmaan | ++, sure I mean, keeping it for TC is ok, but it will be helpful to know which hrs (out of these 3 hrs) hrs cross projects interaction/topic will be and which hrs TC specific | 19:32 |
| gouthamr | i'll push TC/governance-only discussions to Friday as much as possible | 19:35 |
| sean-k-mooney | well its ok for them ot be on moday | 19:36 |
| sean-k-mooney | its just we have a 2 hour widnow in the eu timeslot but htat a bit early for NA folks | 19:37 |
| sean-k-mooney | so most corss project stuff woudl have to happenon tueday or durign the week | 19:37 |
| sean-k-mooney | unless we do them in the na slots on monday | 19:37 |
| JayF | sean-k-mooney: clif: I'll get https://review.opendev.org/c/openstack/ironic/+/983251 mergable tomorrow or next week, but it should be good enough to get started. Ironic+Nova services start with it enabled. There's a zuul job in there with a devstack config. | 21:56 |
| clif | nice | 21:57 |
| sean-k-mooney[m] | Cool just got to the ironc part of the openinfra live | 21:57 |
| JayF | it's mainly just an ad for the full one next week | 21:57 |
| * sean-k-mooney[m] tries to ignore the conflicting use of the reserved capabilities: flavour extra spec | 22:01 | |
| sean-k-mooney[m] | [JayF_](https://matrix.to/#/@_oftc_JayF_:matrix.org) https://4a2cc9e4719053545829-344a6ad21c722e33f9112420ebbef28e.ssl.cf2.rackcdn.com/openstack/0127c1b07a614bf59b7652d259434573/controller/logs/local_conf.txt will be useful especially with the patch | 22:20 |
| JayF | sean-k-mooney[m]: feel free to give review feedback if it's on my change specifically; if it's an overall pattern then LOOK OVER THERE [/me runs] | 22:49 |
| sean-k-mooney[m] | Some telephone communication vibes. | 22:51 |
| sean-k-mooney[m] | Like instead of CUSTOM_GOLD trait I would expect you to use a CUSTOM_BEARMETAL_GOLD resource class so you can use unified limits of per sku quota and simpler billing | 22:55 |
| JayF | sean-k-mooney[m]: there's no doubt in my mind that some nontrivial % of that is carryover, if there are concrete improvements we can make in the devstack setup that'd be cool | 23:28 |
| JayF | sean-k-mooney[m]: I don't know as much as I should about the nova setup side of Ironic as I should, despite the work I've done on the virt driver, maybe could kill both those birds with one stone | 23:28 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!