| opendevreview | Merged openstack/nova stable/victoria: reenable greendns in nova. https://review.opendev.org/c/openstack/nova/+/833436 | 02:16 |
|---|---|---|
| zigo | stephenfin: Hi there! How are you? | 08:25 |
| zigo | Where is tracked the SQLAlchemy 2.x patches, so I can attempt backporting them to Bobcat in Debian? | 08:25 |
| bauzas | zigo: I can help, all changes for support SQLA2 'language' in SQL1.4 are in this gerrit topic https://review.opendev.org/q/topic:sqlalchemy-20 | 08:41 |
| zigo | Ah, thanks a lot, will try. | 08:42 |
| zigo | Gosh... too many... how do I know what's missing from Bobcat? | 08:42 |
| bauzas | what do you exactly want to backport ? | 08:46 |
| bauzas | sqla changes that were merged after Bobcat RC1 ? | 08:46 |
| zigo | Yeah. | 08:46 |
| bauzas | all projects or just nova ?. | 08:47 |
| zigo | All projects. | 08:47 |
| zigo | Maybe I can just use the date of last change ... | 08:47 |
| bauzas | well, the RC1 date is different for every project, that's the point | 08:47 |
| bauzas | but I can filter out the gerrit query | 08:48 |
| bauzas | sec | 08:48 |
| zigo | Oh, there's a way to know with a simple Gerrit query? :) | 08:48 |
| bauzas | for sure | 08:50 |
| bauzas | I was looking at some query field that would be 'includedin' but I can't find it so I'll just use mergedafter | 08:51 |
| bauzas | and you'll just compare with the list of merged patches to see whether we missed any patch during the RC period | 08:51 |
| zigo | I can just compare the code, yeah ... | 08:52 |
| zigo | https://review.opendev.org/q/topic:sqlalchemy-20+project:openstack/heat+mergedafter:2023-09-11 <--- This looks like doing the trick for heat... | 08:53 |
| bauzas | https://review.opendev.org/q/topic:sqlalchemy-20+is:merged+mergedafter:%25222023-09-15%2522,25 | 08:53 |
| bauzas | yeah, just be aware some projects may have branched RC1 late | 08:54 |
| bauzas | (like nova, whoops) | 08:54 |
| zigo | Thanks a lot, that's very helpful. So far, I backported 5 heat patches, continuing ... :) | 09:21 |
| opendevreview | sean mooney proposed openstack/nova master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/nova/+/899753 | 09:29 |
| zigo | sean-k-mooney: Oh my god... I'm having a headake reading your commit header!!! :/ | 09:48 |
| bauzas | pyproject.toml-- | 09:49 |
| sean-k-mooney | bauzas: thats not the problem and you know it | 09:50 |
| bauzas | #xkcd872 | 09:50 |
| sean-k-mooney | its we have not adapted to the pip change that was deprecated 2 years ago | 09:50 |
| bauzas | err, #xkcd972 - standards | 09:50 |
| zigo | Last time I checked, there was 4 ways to list the modules in a Python package, depending on what python packaging tooling is in use. | 09:50 |
| bauzas | sean-k-mooney: sure I'm not debating your own changes, I'm rather arguing about pyproject.toml instead | 09:50 |
| sean-k-mooney | zigo: this will eventually affect all distos not just centos so im trying to get ahead of it by enausering we have basic supprot for pep 517/518/660 | 09:51 |
| bauzas | sean-k-mooney: I'm basically hating what the python community did for packaging, ie. creating yet another standard | 09:51 |
| sean-k-mooney | zigo: we are goign to continue to use reqiurements.txt | 09:51 |
| zigo | sean-k-mooney: Guess which distro will be affected first ... :/ | 09:51 |
| sean-k-mooney | zigo: its actully centos not debian | 09:52 |
| sean-k-mooney | well depending on how you look at it. im usign debian sid right now and its works fine without this | 09:52 |
| sean-k-mooney | for now | 09:52 |
| zigo | Well, it's not like if I was maintaining 400+ python packages for OpenStack that will all need patching ... :/ | 09:52 |
| bauzas | zigo: yeah, thanks the python community for that brilliant idea | 09:53 |
| sean-k-mooney | bauzas: you know it annoys me every time you do that right | 09:53 |
| sean-k-mooney | bauzas: your being dilberatly dismissive of there efforts to solve an issue that many of there users had | 09:54 |
| zigo | On the bright side, I very much agree that the setup.py thingy was a disaster, ie: having to execute code to be able to find out things instead of reading a configuration file was kind of a very broken idea. | 09:54 |
| sean-k-mooney | zigo: ya i really dont like impertive systems for packaging | 09:55 |
| sean-k-mooney | not that debina or rpm format get it correct either | 09:55 |
| zigo | Though there a better ways than breaking everyone at once... | 09:55 |
| sean-k-mooney | i dont know 2 years of deprecation after several years of supprot is kind of reasonsble | 09:56 |
| sean-k-mooney | and to be clear the only thing that broke for us | 09:56 |
| bauzas | 2 years is a very short timeframe IMHO | 09:56 |
| sean-k-mooney | is an extention to setuptools we have in pbr | 09:56 |
| zigo | I agree with Sylvain. | 09:56 |
| sean-k-mooney | if we used plain setuptools with no extentiosn we would not ahve been broken at all | 09:56 |
| bauzas | sean-k-mooney: fwiw, I +2'd the change itself | 09:56 |
| bauzas | that's not because I hate that direction that I'll hold it | 09:56 |
| zigo | There are thousands of upstream of python modules that will *NOT* be reactive enough. | 09:57 |
| bauzas | the ship sailed and I need to move on | 09:57 |
| sean-k-mooney | bauzas: ack, we needed to wait for pbr 6.0.0 for the py 39 job to pass, that was released 7 hours ago so we will see what the ci says when it completes | 09:57 |
| bauzas | but I'm just throwing my hate by explaining why I think 2 years is not a respectful timeframe | 09:57 |
| sean-k-mooney | zigo: right but thats why they implemetned a fallback that will work for vaniall setuptools out of the box | 09:57 |
| bauzas | but that's not the first time the python community is trampling us | 09:58 |
| sean-k-mooney | i mean we dont supprot or release for 2 years | 09:58 |
| bauzas | anyway, I should stop arguing here as it's useless, I should rather invest time in the python community itself | 09:58 |
| sean-k-mooney | we only supprot them for 18 months | 09:58 |
| sean-k-mooney | offically anyway | 09:58 |
| sean-k-mooney | so your holding them ot a higher standard then we hold ourselves? | 09:59 |
| zigo | BTW, Python 3.12 thingy will start in Unstable next November. | 10:00 |
| zigo | Expect bug reports and patches from me ... | 10:00 |
| bauzas | I have the opinion that the lower you're a dependency, the longer you need to keep support | 10:00 |
| zigo | Yet another thing: how come every single new version breaks my world ... | 10:00 |
| sean-k-mooney | next november as in 2025 or as in that then next thing to start in novemerb on your backlog | 10:00 |
| bauzas | and a language sounds to me like probably one of the lowest dependencies we have and the most commonly shared | 10:01 |
| zigo | Oh sorry, as in this month ! | 10:01 |
| sean-k-mooney | ok :) | 10:01 |
| sean-k-mooney | i was like that seams far off | 10:01 |
| zigo | 3.14 is planned for Trixie (ie: debian 13). | 10:01 |
| bauzas | forcing people to upgrade by 2 years if you're a very common library is kinda harsh | 10:01 |
| sean-k-mooney | bauzas: your only forced to upgrade if you dont pin your deps | 10:02 |
| sean-k-mooney | you can always you an older pip to get the old behavior | 10:02 |
| sean-k-mooney | bauzas: the reason that is not viabel for us | 10:02 |
| sean-k-mooney | is openvswitch now requried pep 517 to build in debian and newer releases then we ship in centos/ubuntu | 10:03 |
| bauzas | that's my point | 10:03 |
| sean-k-mooney | so pining pip breaks once you have a new enought ovs | 10:03 |
| bauzas | if this wasn't ovs, this would be something else | 10:03 |
| bauzas | since lots of projects are moving on their own timeframe, the other ones also need to adjusty | 10:04 |
| sean-k-mooney | well the ovs issue is they did not keep supprot for both like i am | 10:04 |
| sean-k-mooney | im just adding pyproject.toml supprot without removing setup.py support | 10:04 |
| sean-k-mooney | zigo: ^ important point for you | 10:04 |
| bauzas | sean-k-mooney: yeah, hence my +2 | 10:04 |
| bauzas | we're continuing to do the old way but we allow doing it the new way | 10:05 |
| sean-k-mooney | we can drop setup.py support in the future but its not breaking anything so i didnt see a point | 10:05 |
| zigo | sean-k-mooney: Yeah, I'll look at what you did! | 10:05 |
| bauzas | again, my rant wasn't directed to your change | 10:05 |
| sean-k-mooney | bauzas: i know | 10:05 |
| sean-k-mooney | i just feel like i have to play devels avocate and defend the python core team | 10:06 |
| * sean-k-mooney wonders if the joys of workign with a gpu company starting with n has darkend bauzas world view in general :P | 10:06 | |
| jrosser | talking of gpu company starting with n, A100/A30 removal from the vGPU driver v16 is causing us a massive headache right now | 10:13 |
| sean-k-mooney | jrosser: yep... | 10:14 |
| jrosser | anyone with ideas what to do would be interesting | 10:14 |
| sean-k-mooney | other then keepign the old driver and pinnign your kernel till you retire the hardware | 10:14 |
| sean-k-mooney | there isnt much you can do | 10:14 |
| sean-k-mooney | jrosser: what os are you on | 10:14 |
| jrosser | ubuntu | 10:14 |
| sean-k-mooney | cool well i think you can continue to use the 15.x driver for the lifetime of 22.04 right | 10:15 |
| sean-k-mooney | although obviorulsy wihtout any future security/preformance improvements | 10:15 |
| jrosser | i don't believe we are going to be able to get any more vCS licences once ours expire | 10:15 |
| sean-k-mooney | oh right the lisciense have an experation date... | 10:16 |
| jrosser | yup | 10:16 |
| sean-k-mooney | they have a diffent driver that the created for some of there skus | 10:16 |
| sean-k-mooney | do you know fi the a100 moved to the new dirver | 10:16 |
| sean-k-mooney | they are spliting there product skus between enterpirse and ai/ml usecases i belive | 10:17 |
| sean-k-mooney | i havent really looked at the detail but i know the grid driver is being split in two for two diffent classes of hardware/workloads but i dont knwo where the a100 lands in that regard | 10:18 |
| jrosser | sean-k-mooney: we have been attempting to PCI passthrough the MIG sriov VF (this might be pointless and never work, but it is at the advice of someone from nv) and get this https://paste.opendev.org/show/bTDDSu1EaNMhflc12ROB/ - do you see anything like that before with PCI passthrough? | 10:30 |
| sean-k-mooney | jrosser: my understanding is while that could work the nvida driver in the guest does not curretnly work on the vf | 10:32 |
| jrosser | i could totally believe that | 10:33 |
| sean-k-mooney | header type 127 does seam famialr for some reason | 10:33 |
| sean-k-mooney | i belive its one fo the extended pci capablity headers | 10:34 |
| jrosser | and that certainly the case for vGPU/GRID driver on the host and free DataCenter driver in the guest which would be the most obvious licencing bypass you could do, so I expect that not to work | 10:34 |
| jrosser | the advice we got was to try DataCenter driver on the host and in the guest | 10:34 |
| sean-k-mooney | https://forum.level1techs.com/t/unknown-pci-header-type-127-for-device-000000-0/180125/4 | 10:35 |
| sean-k-mooney | appreently its somethign to do with the graphsics card sleep modes | 10:35 |
| opendevreview | Merged openstack/nova-specs master: Re-propose spec for ephemeral storage encryption https://review.opendev.org/c/openstack/nova-specs/+/897502 | 10:35 |
| opendevreview | Merged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt https://review.opendev.org/c/openstack/nova-specs/+/897503 | 10:35 |
| sean-k-mooney | jrosser: so its apprently because the card is not reseting properly when attached/detached form the vm | 10:37 |
| sean-k-mooney | jrosser: thats a pretty common thing on consumer graphics cards that are pci passhtough to a vm | 10:37 |
| jrosser | hmm | 10:37 |
| sean-k-mooney | im suprised thats a problem for a100 but since they never intended the vfs to be passed to the guest its not that surprising | 10:38 |
| sean-k-mooney | https://forum.level1techs.com/t/solved-gpu-passthrough-suddently-stopped-working-on-windows-10-vm/171273/5 | 10:41 |
| sean-k-mooney | i have not tired this but apprently you can disbable the d3 idel state for that device | 10:41 |
| sean-k-mooney | options vfio-pci ids=10de:2486,10de:228b disable_vga=1 disable_idle_d3=1 | 10:41 |
| opendevreview | Merged openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Caracal https://review.opendev.org/c/openstack/nova-specs/+/898319 | 10:42 |
| sean-k-mooney | jrosser: if it is just a sleep issue i woudl give that a try for the mig vfs | 10:42 |
| jrosser | ah thats interesting, thanks | 10:43 |
| bauzas | jrosser: fwiw, please know that you could be hit with https://bugs.launchpad.net/nova/+bug/2041519 if you use A100 | 10:43 |
| bauzas | jrosser: and yeah, I send hugs to you about vGPU GRID16 EOL support for AI | 10:44 |
| jrosser | bauzas: yeah i saw that discussion the other day - the whole thing is a total disaster /o\ | 10:44 |
| bauzas | you now need to buy a fancy expensive AIE license : https://docs.nvidia.com/ai-enterprise/4.0/release-notes/index.html | 10:44 |
| jrosser | indeed, for 50 to 100% of the cost of the hardware | 10:45 |
| sean-k-mooney | i recently bought an intel a750 apprently you can flash that to run there datacenter firmware | 10:45 |
| sean-k-mooney | and get sriov supprot on the consumer card | 10:45 |
| bauzas | jrosser: IMO, now working with some n guys, I can say that they're excellent hardware vendors but terrible software engineers | 10:45 |
| sean-k-mooney | i have been debating about doing that | 10:46 |
| bauzas | sean-k-mooney: btw. when you and dansmith have time, I'd like to discuss on what direction we should do with https://bugs.launchpad.net/nova/+bug/2041519 | 10:46 |
| bauzas | the alternative series I wrote is not helping as it doesn't delete existing RPs https://review.opendev.org/q/topic:bug%252F2041519-new | 10:47 |
| bauzas | (the above patch is just a nice try to pass a PF in device_addr instead of VFs, but that's not mandatory) | 10:47 |
| sean-k-mooney | ok ill need to load context on this again so let either set up a meeting ro choose a time to discuss it but it woudl be good to sumemrise what you have tried and what did/didnt work | 10:49 |
| bauzas | sean-k-mooney: and you know, I haven't darken my view of the world, I'm just mattman as matthew perry said | 10:49 |
| sean-k-mooney | bauzas: im currently reviewing dans spec | 10:49 |
| sean-k-mooney | but i can take a look at the patches after | 10:49 |
| bauzas | sean-k-mooney: sure, let's do a gmeet with dan when he's up | 10:49 |
| zigo | jrosser: Am I reading well that the A100 removal is from the Linux kernel ?!? | 10:49 |
| bauzas | sean-k-mooney: no urgency | 10:49 |
| sean-k-mooney | zigo: i dont think soo i think its just being droped form the nvidia binary driver they ship via there portal | 10:50 |
| bauzas | zigo: no, A100 are no longer supported in GRID, that's the point | 10:50 |
| bauzas | zigo: starting with GRID16 | 10:50 |
| sean-k-mooney | it would work as a normal graphics card with teh opensouce neuvous driver | 10:50 |
| bauzas | https://docs.nvidia.com/grid/16.0/whats-new-vgpu/index.html | 10:50 |
| dvo-plv | Hello, All. I would like to discuss results of yesterday debate regarding packed ring. Currently we have tow way traits and prefilter based on the release version. How we properly can solve this problem, Should be ask gibi for his ? | 10:50 |
| sean-k-mooney | but none of there vGPU stuff is supproted in the the opensouce dirver | 10:51 |
| bauzas | dvo-plv: I said yesterday that eventually, I'll let the spec sail | 10:51 |
| bauzas | so ask gibi for a review | 10:51 |
| bauzas | dvo-plv: sean-k-mooney had a point on the fact we shouldn't conditionnally provide the trait, so update your spec and add testing and I'll let sean-k-mooney +2 it | 10:52 |
| dvo-plv | okay, I see your point, thank you | 10:52 |
| bauzas | for me, I'll pass as I don't want to give an approval for some direction I have arguments against, but on the other way, I don't wanna hold the series, so I defer to other cores | 10:52 |
| bauzas | I'll just not vote on the spec | 10:53 |
| sean-k-mooney | dvo-plv: tl;dr we bumped libvirt min to 7.0.0 last cycle so no need to do a check on the version anymore | 10:53 |
| sean-k-mooney | either for the trait or in the driver | 10:53 |
| sean-k-mooney | you can just assume its new enough | 10:53 |
| dvo-plv | yes, i remember your comment under the nova patch, that i have to update it, because this https://review.opendev.org/c/openstack/nova/+/887255 was merge first | 10:54 |
| bauzas | correct | 10:54 |
| sean-k-mooney | yep | 10:54 |
| sean-k-mooney | it should simplfy your patch although you had already added the checks | 10:54 |
| dvo-plv | sure, i will update spec first and then nova. Thank you for your time | 10:55 |
| bauzas | dvo-plv: fwiw, even if I want to abstain on the spec, I can review the implementation | 10:55 |
| bauzas | now that I have the whole context, I surely can review it quickly once the design is approved by other cores but me | 10:56 |
| dvo-plv | sure | 10:56 |
| dvo-plv | it sounds critical:) | 10:56 |
| zigo | stephenfin: There are many more services that fail with SQLA 2.x, that haven't been addressed: https://qa.debian.org/excuses.php?experimental=1&package=sqlalchemy | 10:57 |
| zigo | Namely, cloudkitty, trove, ironic-inspector, masakari, sahara, senlin, vitrage, zaqar ... | 10:57 |
| bauzas | your spec will allow operators to not care about mixing hypervisors, which is good, it just doesn't solve our general problem on libvirt knobs we wanna handle | 10:57 |
| bauzas | sean-k-mooney: see, I'm not that dark | 10:57 |
| sean-k-mooney | bauzas: by the way i think we can do a better job on the adress size spec. i -1 with a request to supprot it in image properties adn enchanment to automatically use triats and enchnce the image propperties filter | 10:58 |
| sean-k-mooney | its a minimal expantionin the scope but will basically make it work out of the box for most peopel | 10:59 |
| bauzas | ack, I'll review that one | 10:59 |
| bauzas | tbh, it was a straight reproposal without much additions, I didn't put my brain on it like I did for some other spec :) | 11:00 |
| sean-k-mooney | ya im not sure why i didnt raise these point last cycle | 11:00 |
| bauzas | sean-k-mooney: I also reconsidered the debt we put on ourselves by adding traits | 11:00 |
| sean-k-mooney | which i said in the spec review | 11:00 |
| bauzas | since traits aren't allocations, we can remove compute traits whenever we want, provided we support N-1 or 2 computes | 11:01 |
| bauzas | without need of a reshape | 11:01 |
| sean-k-mooney | you mean requesting and or reporting them? | 11:01 |
| bauzas | both | 11:01 |
| sean-k-mooney | in general we shoudl never remove standard traits | 11:01 |
| sean-k-mooney | as it can break flavors or iamges | 11:01 |
| sean-k-mooney | with requried traits requests | 11:02 |
| bauzas | new computes can stop reporting a trait, but the prefilter needs to speak old language until next SLURP | 11:02 |
| sean-k-mooney | no that woudl still break explcit traits request in teh flavor/image | 11:02 |
| bauzas | sean-k-mooney: right, but dvo-plv's spec is not exposing the trait itself, which is less tech debt | 11:02 |
| sean-k-mooney | bauzas: it wont require it to be set manually | 11:03 |
| sean-k-mooney | if that is what you mean | 11:03 |
| bauzas | sean-k-mooney: that's why I think we said to avoid as much as possible to expose the traits in flavors | 11:03 |
| sean-k-mooney | partly | 11:03 |
| bauzas | sean-k-mooney: what I mean is that I would strongly disapprove the qemu spec if I hear people using the trait directly in a flavor | 11:03 |
| sean-k-mooney | i dont like askign for things twice (once with a traint and again with an extra spec) | 11:03 |
| bauzas | but I meh it, if we have a prefilter that hides that trait | 11:03 |
| bauzas | operators using that trait directly for scheduling would then do something unsupported | 11:04 |
| sean-k-mooney | right so in general a prefilter or and extention to ResouceRequest.from_request_sepc | 11:04 |
| sean-k-mooney | is the preferd way to use reqirued traits for standard traits | 11:04 |
| sean-k-mooney | ResouceRequest.from_request_spec is what you shoudl extend if its going to be in both the flavor and image | 11:05 |
| bauzas | correct, standard traits should never be used directly in flavors, and I think we said that while ago | 11:05 |
| sean-k-mooney | cool with me | 11:05 |
| bauzas | only custom traits can be used in flavors | 11:05 |
| sean-k-mooney | well | 11:05 |
| bauzas | but I think we never documented that | 11:05 |
| sean-k-mooney | no there are some standard taits that can be in the flavors | 11:05 |
| sean-k-mooney | specificaly the one for cpu fetature flags | 11:06 |
| bauzas | I know, and I'd want us to take a stand | 11:06 |
| sean-k-mooney | i.e. ones that are not related to any flavor extra spec | 11:06 |
| sean-k-mooney | so the nounce is standard traits shodl be avoided if they can be requested via an extra spec instead | 11:07 |
| bauzas | that's sad, PTG is just behind us but I realized we never went to a conclusion on whether we should expose our traits in flavors and the consequences it has | 11:07 |
| sean-k-mooney | well you knwo i generally dont like exposing resouces: or traits in the flavor/image when we can have an indriction via something else | 11:08 |
| bauzas | ditto here, but again, we haven't documented that tenet | 11:08 |
| sean-k-mooney | right but we cant say (you shoudl never request a standard triat in the flvor/image) | 11:09 |
| bauzas | and operators could be trying to test fancy things by exposing those traits in a flavor | 11:09 |
| stephenfin | zigo: nothing I can do about that, I'm afraid. I've pushed patches for Masakari and repeatedly trumpted the fact that this needs to be addressed in other projects | 11:09 |
| bauzas | I'd rather do an explicit list of traits we allow to specify | 11:09 |
| sean-k-mooney | specific these ones are genrally valid to request https://github.com/openstack/os-traits/tree/master/os_traits/hw/cpu | 11:09 |
| bauzas | sean-k-mooneylike a public API | 11:09 |
| bauzas | we have a stand on the contractual API we support | 11:09 |
| sean-k-mooney | bauzas: we could always enchnae the flavor validtor | 11:09 |
| stephenfin | zigo: Those will break when we uncap SQLAlchemy. They'll have to fix it then 🤷♂️ | 11:10 |
| opendevreview | Steven Relf proposed openstack/nova master: Adding basic auth to dynamic vendordata api calls https://review.opendev.org/c/openstack/nova/+/900252 | 11:10 |
| bauzas | sean-k-mooney: I don't know what to do, that's the point | 11:10 |
| bauzas | what's easier is when you have a prefilter or the requestspec translator | 11:11 |
| bauzas | then we can say 'sorry, no, not intended to be used this way' | 11:11 |
| sean-k-mooney | yep so when adding new extraspecs/image proeprts and a trait | 11:11 |
| zigo | stephenfin: Thanks for letting me know, I'll see if we can invest time in at least cloudkitty that we use in production. | 11:11 |
| sean-k-mooney | i think we shoudl alwasy prvied the prefilter/translator | 11:11 |
| bauzas | sean-k-mooney: sounds a direction | 11:11 |
| sean-k-mooney | and we could enhance the flavor validation api to also reject the use of the "resrved traits" in the future | 11:12 |
| sean-k-mooney | bauzas: https://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/traits.py | 11:12 |
| bauzas | I mean, for the short future, we need to agree between us as cores | 11:12 |
| sean-k-mooney | yep | 11:13 |
| sean-k-mooney | we shoudl likely update the contibutors guide or add a new refence doc | 11:13 |
| bauzas | I'll capture that in a doc patch | 11:13 |
| sean-k-mooney | i.e. how to design with triats and resouce classes | 11:13 |
| bauzas | that's a start | 11:13 |
| sean-k-mooney | i woudl add a new doc in https://github.com/openstack/nova/tree/master/doc/source/reference | 11:14 |
| sean-k-mooney | or here https://github.com/openstack/nova/tree/master/doc/source/contributor | 11:14 |
| sean-k-mooney | bauzas: on a related note i really dont like usign resouces: in genreal in the flavor either | 11:14 |
| bauzas | yeah the latter was the one I thought | 11:15 |
| sean-k-mooney | i kind of whish we had vgpu: instead | 11:15 |
| bauzas | sean-k-mooney: I don't disagree | 11:15 |
| sean-k-mooney | the main reason i say this is i dont like the way grouping works | 11:15 |
| bauzas | particularly if a VGPU resource could be a mdev or a VF in the next future | 11:15 |
| sean-k-mooney | i think that is leaking too much about how we modle things in placment | 11:15 |
| bauzas | yeah | 11:15 |
| bauzas | and it creates us some binding | 11:16 |
| sean-k-mooney | ya so i woudl prefer vgpu: to work kind fo liek the pci alias | 11:16 |
| bauzas | does it sound another action item for vgpus ? | 11:16 |
| sean-k-mooney | so we have a layer of indirection | 11:16 |
| bauzas | man, I really should invent the cloning machine first | 11:16 |
| sean-k-mooney | am im not sure based on the lifespan of vgpus | 11:16 |
| sean-k-mooney | but doign this as mdev: i could get behind | 11:16 |
| sean-k-mooney | im expecgint that we will just use the pci_alias goign forward for sriov vgpus implemenations | 11:17 |
| bauzas | actually, having mdevs: flavor resources sounds better for operators if we start support vfio-pci for GPUs | 11:17 |
| sean-k-mooney | having this indrection for mdevs in general i thikn would be nice but not required | 11:17 |
| bauzas | yeah | 11:18 |
| sean-k-mooney | so effectivly we woudl extend the devices section or one of the dynmic section with an alias option | 11:18 |
| bauzas | when I read my code last week, I thought I spoiled too many vgpu acronyms in the code while this can be mdev agnostic | 11:18 |
| stephenfin | zigo: nw. The topic bauzas mentioned will bring up most patches, and I suspect there are solutions to most potential upgrade issues there | 11:18 |
| stephenfin | topic:sqlalchemy-20 | 11:19 |
| dvo-plv | sean-k-mooney, bauzas I a little bit confused after this conversation. you talked regarding prefilter, as far as I understand about that https://review.opendev.org/c/openstack/nova/+/876075/25/nova/scheduler/request_filter.py#275 | 11:19 |
| dvo-plv | But i did not get if i need to change approach | 11:19 |
| zigo | stephenfin: Yeah, I managed to upload Heat 21.0.0 with all the 12 patches already ! :) | 11:19 |
| zigo | Currently working on Glance. | 11:19 |
| bauzas | dvo-plv: no, you don't need to change the approach if sean-k-mooney and some other core agree on your updated spec | 11:20 |
| sean-k-mooney | dvo-plv: that is fine in my view, no change required | 11:20 |
| sean-k-mooney | dvo-plv: we just have 2 places where you can do this | 11:20 |
| sean-k-mooney | dvo-plv: either as a trival prefilter there | 11:20 |
| bauzas | based on the discussion I just had with sean at the last min, I could even approve the spec now, provided we draw the line | 11:20 |
| sean-k-mooney | or in the schduler utils | 11:21 |
| sean-k-mooney | dvo-plv: like this https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L288-L304 | 11:21 |
| sean-k-mooney | dvo-plv: it has the same effect | 11:22 |
| sean-k-mooney | dvo-plv: the only reason to prefer a prefiler over a translate function like that is if you want ot make it configurable | 11:22 |
| bauzas | right | 11:23 |
| sean-k-mooney | dvo-plv: in your case we dont need or want it to be configurable (its not in your patch) | 11:23 |
| bauzas | you can opt-out | 11:23 |
| sean-k-mooney | but we have mandaotry pre-filters too | 11:23 |
| bauzas | (or opt-in, depending on the default value :) ) | 11:23 |
| sean-k-mooney | so either approch works | 11:23 |
| bauzas | actually | 11:23 |
| bauzas | this sounds terrible for interop if we make those image properties be config-driven, right? | 11:24 |
| sean-k-mooney | dvo-plv: i think we get slightly better logging in general with the prefilter but its basically the same | 11:24 |
| sean-k-mooney | bauzas: it woudl be but its not | 11:24 |
| sean-k-mooney | triat help with interup | 11:24 |
| sean-k-mooney | but only if you have access to placement | 11:24 |
| bauzas | well, if you disable the prefilter, then your property is useless, right? | 11:25 |
| sean-k-mooney | bauzas: the prefilter cant be disabeld | 11:25 |
| bauzas | in the current code, yeah | 11:25 |
| bauzas | but in general, we have prefilters that are config-driven | 11:25 |
| sean-k-mooney | yes but those are genrelaly not related to extra specs | 11:26 |
| bauzas | sure, but that's again errorprone | 11:26 |
| dvo-plv | okay, great that you are on the same page now and all left the friends :) So, I will resolve comments asap, than kyou again | 11:26 |
| sean-k-mooney | bauzas: over time i would expect use to make some prefilters that you can currently opt out of mandatory | 11:26 |
| bauzas | some day we may want to have some configurable prefilter that would do property translation | 11:26 |
| sean-k-mooney | i recently did that for the az prefilter when i remvoed teh az filter | 11:27 |
| sean-k-mooney | i could see use makign the require_image_type_support or transform_image_metadata required at some point | 11:27 |
| sean-k-mooney | bauzas: actully looking at the code more are required then optional today | 11:28 |
| bauzas | yeah fortunately | 11:28 |
| sean-k-mooney | bauzas: we have for image properties already | 11:29 |
| sean-k-mooney | i wrote a genric one to work with all image properties that have corresponding triats | 11:29 |
| sean-k-mooney | we just need to extend that as it make sense | 11:29 |
| sean-k-mooney | i didnt do that for flavors mainly because there are less extra spec that map to triat | 11:29 |
| sean-k-mooney | but reflectign on that it might make sense too revisit that | 11:30 |
| sean-k-mooney | there is likely some consoliation i coudl to with low amoutn of work | 11:30 |
| sean-k-mooney | do you think that woudl be valuable. i just havent felt the effort was worth it previously | 11:31 |
| bauzas | that's a very good question | 11:31 |
| sean-k-mooney | prefilters/translaotr tend to be a single short funciton that is easy to test in isolation | 11:31 |
| sean-k-mooney | combining them loose some of that simplicty depending on how you approch it | 11:32 |
| bauzas | I'm still afraid by the imagination of our lovely operators and I want us to draw a solid yellow line in terms of support, since I don't wanna buy some trait forever | 11:32 |
| bauzas | so, any forgery hiding traits sounds preferable | 11:33 |
| sean-k-mooney | i think its fair to say that if you have very complex resouce and traits request in flavor that opens you up to some upgrade impacts that you woudl otehrwise not be exposed too | 11:33 |
| bauzas | whether we should factorize the forgeries into one piece is debatable | 11:33 |
| sean-k-mooney | perhasp something to consier in the future | 11:33 |
| sean-k-mooney | but i dint think its required right now | 11:34 |
| bauzas | yeah | 11:34 |
| bauzas | also, have we ever tried to sanitize os-traits before ? | 11:34 |
| bauzas | sounds now nearly impossible to me | 11:35 |
| sean-k-mooney | we are not allowed to remove traits form os-traits | 11:36 |
| sean-k-mooney | ever | 11:36 |
| sean-k-mooney | placement does not support that today | 11:36 |
| bauzas | I reached to that conclusion | 11:36 |
| sean-k-mooney | it could be done with some mettadata but basically we need to resver the triat ids in the db | 11:36 |
| * bauzas shivers | 11:39 | |
| bauzas | anyway, I need to deserve time for lunch and writing my own spec | 11:40 |
| opendevreview | Merged openstack/nova-specs master: Add libvirt-dev-alias spec https://review.opendev.org/c/openstack/nova-specs/+/892806 | 11:56 |
| *** Continuity__ is now known as Continuity | 12:19 | |
| opendevreview | sean mooney proposed openstack/nova master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/nova/+/899753 | 12:19 |
| Continuity | hey all, I have submitted a PR (https://review.opendev.org/c/openstack/nova/+/900252) and I'm struggling to understand and fix the build errors. Mostly around openstack-tox-cover, openstack-tox-py38 and nova-tox-py310-with-sqlalchemy-2x. It seems to be a case of, works fine on my local machine :D | 12:22 |
| Continuity | anyone have any pointers | 12:22 |
| sean-k-mooney | Continuity: the pep8 failures look valid https://zuul.opendev.org/t/openstack/build/914ce175822a4ada8271b3d5ae9d6877/log/job-output.txt#4269-4282 | 12:28 |
| sean-k-mooney | Continuity: we will also need a bug or specless blueprint to proceed with this feature | 12:30 |
| sean-k-mooney | the unit test failrue also look valid https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_3b1/900252/2/check/openstack-tox-py38/3b1dc22/testr_results.html | 12:31 |
| sean-k-mooney | requests.exceptions.MissingSchema: Invalid URL 'POST': No scheme supplied. Perhaps you meant https://POST? | 12:31 |
| Continuity | sean-k-mooney: yeah I agree they look correct, thats the issue, when I run the tox commands locally they pass :S | 12:33 |
| sean-k-mooney | Continuity: the fact you are gettign fewer error in 3.10 vs 3.8 is concerning | 12:33 |
| Continuity | and yes i need to drop a BP in as well | 12:33 |
| sean-k-mooney | as it imply your relaying on a behaivor in requests that is diffent between the two versions | 12:33 |
| Continuity | not intentionally, but its possible. I will dig a litter deeper | 12:34 |
| sean-k-mooney | in general in not sure how i feel about adding http basic auth to this feature | 12:35 |
| sean-k-mooney | escially since we have not tempest testing of this at all | 12:35 |
| sean-k-mooney | Continuity: we will have to see how others feel about that and if a spec is required and ci coverave beyond unit test. i woudl like to see at least some functionl coverate for this i think | 12:36 |
| sean-k-mooney | but maybe even devstack/tempest testing | 12:36 |
| Continuity | fair enough, basic auth felt like a good step between having to shoehorn keystoneauth into and endpoint that may already exist and nothing. | 12:37 |
| sean-k-mooney | basically devstack woudl jsut have to stand up a fake webservice with http_auth configured that returns some static data to show the auth actully works | 12:37 |
| Continuity | yeah i can deffo take a look at that | 12:37 |
| Continuity | let me get a BP created at least then we can invite conversation.. | 12:38 |
| sean-k-mooney | sure. im not agaisnt basic auth in general but i dont want to see us supproting more auth protocl in the future | 12:38 |
| sean-k-mooney | i.e. oath or saml tokens | 12:38 |
| sean-k-mooney | if we needed anything more advanced then you shoudl use keystone | 12:38 |
| Continuity | yeah | 12:39 |
| Continuity | i agree | 12:39 |
| Continuity | it would get massively messy otherwise. | 12:39 |
| sean-k-mooney | are you missign POST here https://review.opendev.org/c/openstack/nova/+/900252/3/nova/api/metadata/vendordata_dynamic.py#116 | 12:40 |
| sean-k-mooney | oh no | 12:41 |
| sean-k-mooney | your using session.post | 12:41 |
| sean-k-mooney | is there a reason your not using res = self.session.request(url, 'POST', | 12:42 |
| sean-k-mooney | ah sessionis a difent object | 12:42 |
| sean-k-mooney | dependin on if you use _load_ks_session or _load_request_session | 12:42 |
| sean-k-mooney | one is using a keystone auth client vs a requests client directly | 12:43 |
| Continuity | yeah | 12:48 |
| Continuity | might be the wrong approach ... | 12:48 |
| Continuity | i know that that ks_sessions is built ontop of requests, but had issues picking it apart | 12:48 |
| sean-k-mooney | it is yes | 12:48 |
| Continuity | and was trying to not muddy the two | 12:48 |
| sean-k-mooney | using request directly is fine | 12:49 |
| sean-k-mooney | but can you try and use the same method assumign it exits | 12:49 |
| sean-k-mooney | i commented on the patch | 12:49 |
| sean-k-mooney | you are not mockign the funciton that you are calling in the unit test correctly | 12:49 |
| sean-k-mooney | you are using session.post but mocking session.request | 12:49 |
| sean-k-mooney | if we can just use session.request in both cases that woudl be preferable | 12:50 |
| sean-k-mooney | or session.post in both cases | 12:50 |
| Continuity | right, thanks | 12:55 |
| Continuity | sean-k-mooney: appreciate the pointers. I will take another look | 12:55 |
| dansmith | bauzas: I'm around now | 14:36 |
| bauzas | sean-k-mooney: cool, let's see if sean-k-mooney can also be around | 14:39 |
| * bauzas writing the mdev live-migration spec atm | 14:39 | |
| bauzas | heh, sorry, I meant dansmith | 14:39 |
| dansmith | bauzas: if you just want sean-k-mooney twice and not me, that's fine | 14:40 |
| bauzas | dansmith: nah, was saying let's see if sean-k-mooney and you have time for discussing about the bug :) | 14:41 |
| dansmith | I know :) | 14:41 |
| bauzas | 'sup, sean ? | 14:41 |
| bauzas | dansmith: also fwiw, I eventually accepted to use a trait for the virtio-packedring thing if *to be clear* we use a prefilter that we can delete | 14:42 |
| bauzas | because I want to be clear that standard traits shouldn't be directly used in flavors | 14:42 |
| bauzas | this way, we could do something else for hypervisory-only verifications if we want without holding the spec itself that we already accepted before | 14:43 |
| dansmith | standard traits shouldn't be used in flavors? what does that mean? | 14:44 |
| bauzas | they *could* be used if we don't have prefilters or request spec transformation but, | 14:47 |
| bauzas | for the other ones that have a prefilter, nova shouldn't support the fact to call directly Placement with a resource request using those traits | 14:47 |
| bauzas | by saying "shouldn't support", I think people could do it, but in case computes no longer provide the traits, it wouldn't be a bug | 14:48 |
| bauzas | like we do with, say, virt driver API which is an internal API | 14:48 |
| dansmith | okay I guess I'm confused - one of the primary reasons for this stuff in the first place was so you could have a flavor that guaranteed you some CPU flag like sse3, which is a standard trait | 14:48 |
| bauzas | that's the exception I agree | 14:48 |
| dansmith | that's the _rule_ IMHO :) | 14:49 |
| bauzas | hypervisor specific traits like sse3 are okay to me to be directly used in flavors | 14:49 |
| bauzas | we wouldn't change the computes to no longer pass those traits | 14:49 |
| dansmith | okay I don't see that we can, should, or need to draw the line around things like this new one.. if it's a trait it's a trait | 14:49 |
| bauzas | but for other traits that we create, like the one we discussed yesterday, I'm torn to say 'sure, the compute will always provide it" | 14:50 |
| sean-k-mooney | bauzas: i generally agree with dan the reason traits exist is to request hardware capabliteis like sse3 | 14:50 |
| sean-k-mooney | but we realised that not all capabliteis are hardware capabliets | 14:50 |
| dansmith | right, this new capability is "virtual hardware capability" not unlike a cpu flag, IMHO | 14:51 |
| sean-k-mooney | which is why the compute namespace exists to model the capablity of a hyperviors to emulate/provide a functionaltiy | 14:51 |
| sean-k-mooney | right so https://github.com/openstack/os-traits/tree/master/os_traits/compute | 14:51 |
| sean-k-mooney | is for software cpablies | 14:51 |
| sean-k-mooney | and https://github.com/openstack/os-traits/tree/master/os_traits/hw is for host capablities | 14:52 |
| dansmith | exactly | 14:52 |
| bauzas | yeah, so my point is that some of the traits can directly be used, for sure, like the hardware ones | 14:53 |
| sean-k-mooney | where i kind of sit in this debate is if we have an extra spec to enable a functionlatiy that should automatically result in requeest the capablity | 14:53 |
| bauzas | but for some traits we only use internally for scheduling, those shouldn't be directly used | 14:53 |
| sean-k-mooney | i.e. you should not need to request hw:viommu=true and traits:viommu=required | 14:53 |
| sean-k-mooney | the former shoudl result in the latter being added automatically | 14:54 |
| bauzas | if one day, we think that COMPUTE_NET_VIRTIO_PACKED is not the right trait to provide for supporting the virtio_packed thing, we could be able to no longer provide it | 14:54 |
| opendevreview | Danylo Vodopianov proposed openstack/nova-specs master: Re-propose using VirtIO PackedRing Configuration support for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/895924 | 14:54 |
| sean-k-mooney | yep and since we dont expect anywone to directly request it (just use the flavor extra spec) that shoudl be fine | 14:55 |
| bauzas | anyway, I don't want us to discuss that much now | 14:55 |
| sean-k-mooney | we can just document "hay dont set this nova will do it for you" | 14:55 |
| bauzas | agreed | 14:55 |
| dansmith | well, it's that reason why I think it's not *worth* a trait really, and a service version is enough to get through this current hoop we have | 14:56 |
| bauzas | dansmith: that's exactly why I meh'd to the spec | 14:56 |
| dansmith | but I'm not wed to either alternative as they both have pros and cons | 14:57 |
| bauzas | if we only do this in a prefilter, we can modify it later | 14:57 |
| bauzas | like, say, by one time, we create some other trait that says "heh, look, I'm a libvirt host" (I know, I know, this is something some people disagree but that's just an example), then we could remove that trait, provided we support both traits during a SLURP time | 14:58 |
| bauzas | again, don't nitpick that example, we could be smarter | 14:58 |
| dvo-plv | sean-k-mooney, bauzas Under words "user should not use trait, only nova". Should I add this here https://review.opendev.org/c/openstack/nova/+/876075/25/releasenotes/notes/packed-virtqueue-filter-43a376674cb5b345.yaml ? | 14:59 |
| bauzas | dvo-plv: I don't think we need | 14:59 |
| sean-k-mooney | dvo-plv: not in the release notes | 15:00 |
| sean-k-mooney | but it could be a note in the feature doc | 15:00 |
| dansmith | I don't think you should say it at all | 15:00 |
| sean-k-mooney | that also ok | 15:00 |
| dansmith | if it's a trait there's no point in us trying to get people to not use it | 15:00 |
| dansmith | that's just confusing | 15:00 |
| sean-k-mooney | provided we dont refence it in our doc | 15:00 |
| dansmith | (and won't work) | 15:00 |
| sean-k-mooney | i.e. just mention the extra spec not the trait in the doc | 15:00 |
| *** blarnath is now known as d34dh0r53 | 15:00 | |
| dansmith | I'm confused | 15:00 |
| dansmith | why are we not mentioning it? | 15:00 |
| sean-k-mooney | to use this feature you do not need to set the trait manually in the flavor ro the image | 15:01 |
| sean-k-mooney | you just need to set the flavor extra spec | 15:01 |
| dansmith | but why? | 15:01 |
| sean-k-mooney | the trait is an internal detail and does not need to be in the doc | 15:01 |
| dansmith | then we should _not_ be using a trait, IMHO | 15:01 |
| sean-k-mooney | becuase the prefilte adds it based on teh extra spec | 15:02 |
| dansmith | the only way I think a trait makes sense is if you want to be able to say "I asked for packed queue in hw_ and I want you to FAIL if you can't find me a host that supports that" | 15:02 |
| sean-k-mooney | that what it will do | 15:03 |
| sean-k-mooney | the prefilter will check if the flavor has the packed virt queue extra spec and add a required trait | 15:03 |
| sean-k-mooney | so it will fail if we dont find a host | 15:03 |
| dansmith | but you're talking about a prefilter to always do that | 15:03 |
| sean-k-mooney | yes | 15:03 |
| dansmith | what other hw_ things do we enforce at prefilter time that way? | 15:04 |
| sean-k-mooney | unless we just dont do the trait at all | 15:04 |
| sean-k-mooney | sev | 15:04 |
| sean-k-mooney | vtpm | 15:04 |
| sean-k-mooney | we technialy do thoese in teh ResouceRequest.from_request_spec function | 15:04 |
| dansmith | "sev" and "tpm" are not in request_filter | 15:04 |
| sean-k-mooney | rahter then a prefilter | 15:04 |
| sean-k-mooney | if you want a prefilter example cyborg | 15:05 |
| sean-k-mooney | they both run at more or less the same time | 15:05 |
| dvo-plv | dansmith, it will set trait if user required packed here https://review.opendev.org/c/openstack/nova/+/876075/25/nova/scheduler/request_filter.py#275 | 15:05 |
| dansmith | this seems like mixing scopes to me | 15:06 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L187-L195 | 15:06 |
| sean-k-mooney | dansmith: that the other place we do this ^ | 15:06 |
| dansmith | ack, well, I don't really see why this needs to be this way, but whatever | 15:08 |
| bauzas | anyway, I don't have time this cycle to do anything with traits | 15:09 |
| bauzas | I just wanted to make sure we don't agree to use that trait I dislike in flavors | 15:09 |
| opendevreview | Danylo Vodopianov proposed openstack/nova-specs master: Re-propose using VirtIO PackedRing Configuration support for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/895924 | 15:10 |
| bauzas | and I can write some contrib doc saying "please avoid passing hw traits directly in flavors" or some paragraph we could bikeshed | 15:10 |
| dansmith | bauzas: I'm really opposed to that | 15:10 |
| bauzas | what exactly ? hw traits ? | 15:11 |
| sean-k-mooney | bauzas: i would also be opposed to saying dont pas hw traits | 15:11 |
| dansmith | I think acting like there are some 3rd rail traits that you shouldn't use is ridiculous and makes no sense.. if you're going to have an un-disable-able request filter then there's no _point_ in putting one in a flavor, | 15:11 |
| dansmith | but sayin that you shouldn't for some unexplainable reason makes no sense to me | 15:11 |
| bauzas | okay, then the yellow line I would draw would be "don't use standard traits that are automatically queried by either a scheduler prefilter or a requestspec utils method" | 15:12 |
| dansmith | no. | 15:12 |
| sean-k-mooney | i mean you proably shouldnt but i dont think we need to docuemnt that | 15:12 |
| sean-k-mooney | there may be valid reasons to do it | 15:12 |
| dansmith | "there is no need to specify traits like hw_packed_virt_queue because nova does it for you" | 15:12 |
| dansmith | is the strongest I'd say, but I wouldn't even say that | 15:12 |
| sean-k-mooney | i think all we have to do is document the minimal extra spec requried to enabel the feature | 15:13 |
| dansmith | yes | 15:13 |
| sean-k-mooney | and jsut not mention the triats outside the spec | 15:13 |
| bauzas | okay, I won't argue | 15:13 |
| sean-k-mooney | wether there are triats, compute service bump ectra are detail we need to agree on but in general should not impact end users or operators | 15:14 |
| bauzas | I personnally think there are 'consumable traits' and 'non-consumable ones' but OK to not explain to operators the names of the 'non-consumable' ones :) | 15:14 |
| bauzas | that said, they'll get them with placement | 15:15 |
| dansmith | bauzas: I reject your reality and substitute my own | 15:15 |
| sean-k-mooney | :) | 15:15 |
| bauzas | okay, nevermind, I'm done with this | 15:16 |
| sean-k-mooney | bauzas: all traits shoudl be "consumabel traits" they may not exist in yoru cloud but thats a seperate probelm | 15:16 |
| bauzas | like I said, there are other cores but me for the spec | 15:16 |
| dansmith | all traits *are* consumable, so that's just the end of it :) | 15:16 |
| bauzas | this just implies that we won't never remove a trait from a compute once we provide it | 15:17 |
| bauzas | but OK | 15:17 |
| sean-k-mooney | bauzas: we have never done it before | 15:17 |
| sean-k-mooney | and i assuemd that was going to be the case yes | 15:17 |
| sean-k-mooney | i mean unless | 15:17 |
| sean-k-mooney | we remove a feature | 15:17 |
| sean-k-mooney | if we remove the ablit to do somethign removing the trait is reflecting reality | 15:18 |
| bauzas | sure, I wasn't talking about removing a feature | 15:18 |
| dansmith | I too don't think there's any way to remove a trait other than not supporting a thing it represents | 15:19 |
| bauzas | but rather rebuilding the feature by doing other scheduler way | 15:19 |
| dansmith | which is also why traits are massively more expensive than bumping an internal integer | 15:19 |
| bauzas | ^ that is my concern | 15:19 |
| dansmith | well, that was my argument in the beginning | 15:19 |
| sean-k-mooney | if we decied because we have done the min libvirt version we dont need the triat thats fine | 15:20 |
| bauzas | so, again, if we are not able to draw a line (which I can understand), then I won't accept the spec | 15:20 |
| sean-k-mooney | but i dont really like bumping a min compute version for a driver only change | 15:20 |
| bauzas | and I'll just wait for another core to accept it | 15:20 |
| sean-k-mooney | but if that is preferabel fine | 15:20 |
| sean-k-mooney | we are just scoping out supproting this until the cloud is fully upgraded | 15:20 |
| bauzas | we already have a min compute version that works | 15:20 |
| dansmith | sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/objects/service.py#L136 | 15:21 |
| sean-k-mooney | right but normally i would not expect a compute service bump for a change that only affect a virt driver | 15:21 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/objects/service.py#L264 | 15:21 |
| sean-k-mooney | dansmith file backed memroy required toher chagnes | 15:21 |
| dansmith | this feels kinda similar: https://github.com/openstack/nova/blob/master/nova/objects/service.py#L220 | 15:22 |
| sean-k-mooney | dansmith: im more ok with documenting "do a compute service bump for dirver only changes" then docuementing anything about not suing traits | 15:24 |
| dansmith | I definitely understand the "this is purely a driver thing so not service version eligible" but I think that this is (a) the primary virt driver, (b) in tree, (c) has hard version requirements built into the driver | 15:25 |
| bauzas | guys, I originally wanted to discuss about https://bugs.launchpad.net/nova/+bug/2041519 status and we sidetracked on the trait thing where I'm done and not much interested. Fancy moving to that ? | 15:25 |
| dansmith | and also maybe (d) most of the other live migration and neutron things we bump the service version for are really just for libvirt features/changes | 15:25 |
| dansmith | so I dunno | 15:25 |
| dansmith | I think the relative cost makes it worth it | 15:25 |
| dansmith | bauzas: yes please ;P | 15:26 |
| dansmith | bauzas: gmeet or here/ | 15:26 |
| bauzas | gmeet, will be faster if you don't mind getting yet another meeting | 15:26 |
| dansmith | I'd rather do less typing | 15:26 |
| dansmith | here it's 7:26 and I'm already sick of typing | 15:26 |
| bauzas | already had 2 hours of meeting already | 15:26 |
| bauzas | okay, so | 15:26 |
| bauzas | https://meet.google.com/mdo-owzo-zka | 15:27 |
| bauzas | people wanting to discuss on https://bugs.launchpad.net/nova/+bug/2041519 are free to come here ^ | 15:27 |
| dvo-plv | FYI, I've updated packed ring spec file https://review.opendev.org/c/openstack/nova-specs/+/895924 | 15:28 |
| dansmith | sean-k-mooney: ? | 15:31 |
| dansmith | ah nevermind, you're busy sorry | 15:32 |
| sean-k-mooney | ya sorry on two calls currently | 15:37 |
| bauzas | sean-k-mooney: nevermind, dansmith found me a solution that should work :) | 15:41 |
| bauzas | I just need to make sure we can verify the resource providers by init_host :) | 15:41 |
| *** artom_ is now known as artom | 16:01 | |
| *** artom_ is now known as artom | 16:14 | |
| bauzas | dang, since we call check_on_dest before check_on_source in the live migration worflow, I don't have any way to hard guess the mdev type the instance was set against | 17:43 |
| *** JayF is now known as JasonF | 18:53 | |
| *** JasonF is now known as JayF | 18:53 | |
| opendevreview | Erik Olof Gunnar Andersson proposed openstack/nova master: Fix coverage issues with eventlet https://review.opendev.org/c/openstack/nova/+/900116 | 20:17 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!