| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 17:47:03 | dansmith | I thought we were going to have a discussion about it? | |
| 17:47:13 | bauzas | dansmith: you had other prios | |
| 17:47:31 | bauzas | if you have time, sean-k-mooney and I are debating on the need for a trait | |
| 17:47:38 | bauzas | I captured my thoughts in gerrit | |
| 17:47:52 | bauzas | I just can't wait for the next feature coming by and asking for the same | |
| 17:48:09 | bauzas | "hey, I wanna be sure we land on libvirt node" | |
| 17:49:06 | bauzas | so my question is, shall we create a trait for every single image property or flavor extra spec that matches a specific libvirt feature ? | |
| 17:49:12 | bauzas | (and a prefilter of course) | |
| 17:50:12 | dansmith | yeah, honestly for a thing that is just based on libvirt version, and especially a thing in a version from the past, I'd hate to get into the habit of doing a new trait for each of those things because it's such a heavyweight process | |
| 17:50:34 | dansmith | so I think I'm leaning more heavily towards a service version and a hypervisor filter for this kind of stuff | |
| 17:50:44 | bauzas | in the past, we left people to configure their clouds the way they wanted if they had mixed virt drivers | |
| 17:50:46 | dansmith | however, gibi also approved the spec with the trait, so might be good to get him to weigh in there | |
| 17:51:05 | bauzas | the spec never got approved, right? | |
| 17:51:50 | dansmith | bauzas: yeah, it's approved | |
| 17:51:50 | dansmith | so I guess I'm less concerned about that specifically | |
| 17:51:50 | dansmith | bauzas: right the mixed hypervisor thing is definitely a concern, but this is also the sort of thing where a flavor isn't likely to work between ironic and libvirt anyway, | |
| 17:51:50 | bauzas | oh my bad, no | |
| 17:52:10 | bauzas | in the past, we leaned towards saying it's the operator responsibility to make the matching that works | |
| 17:52:24 | bauzas | we had aggregates | |
| 17:52:44 | bauzas | so I'm surprised that we now all go full steam on adding traits for such things | |
| 17:53:04 | dvo-plv | yeah, unfortinatelly i did not get finnal decision how I should move with my solution according to your thoughts | |
| 17:53:37 | dansmith | bauzas: yeah I mean sean-k-mooney's point of *not* making it "some assembly required" definitely resonates with me- I want us to do the right thing when we can | |
| 17:54:28 | dansmith | and I do not think we assert that all the extra specs are schedulable | |
| 17:54:28 | bauzas | dvo-plv: I'm sorry I went into trampling your previous approval, but I guess my disapproval is more about the pattern we follow than your own spec itself | |
| 17:54:28 | dansmith | but a trait is pretty heavy for each "just need a new libvirt version" sort of thing, | |
| 17:54:53 | bauzas | dansmith: yeah, so let's do some kind of automatic filter that would say 'I'm libvirt specific, please give me a libvirt thingies' | |
| 17:55:16 | bauzas | if we reconsider the operator experience and the burden of setting aggregates | |
| 17:56:36 | dansmith | I gotta jump to my next thing, but yeah I think I agree | |
| 17:57:54 | bauzas | fwiw, we have filters that do mappings between flavors/images and aggregates | |
| 17:59:03 | bauzas | operators could just amend their 'libvirt' aggregates by adding an agg property equal to hw:virtio_packed_ring and problem is solved | |
| 17:59:27 | bauzas | but that's adding some operator burden I don't disagree | |
| 17:59:31 | dvo-plv | its okay, never mind | |
| 19:17:15 | sean-k-mooney | bauzas: i think a post schduler filter is far to heavy weight for this | |
| 19:17:58 | sean-k-mooney | we can do a min compute server version check if we really want | |
| 19:18:23 | sean-k-mooney | i feel like that is the midel gorund we can all live with but that means makign this feature unaviabel during the upgrade to caracal | |
| 19:18:43 | sean-k-mooney | i think that is an ok requirement but its somethign we could have supproted via the trait if we wanted too | |
| 19:28:36 | bauzas | you know what ? I'm tired of this, so let's just use the trait | |
| 19:30:01 | bauzas | I'll just don't +2 the spec | |
| 21:11:55 | gmann | sean-k-mooney: just in case you missed these virt driver deprecation backport https://review.opendev.org/q/topic:deprecate-virt-drivers+status:open | |
| #openstack-nova - 2023-11-08 | |||
| 02:16:13 | opendevreview | Merged openstack/nova stable/victoria: reenable greendns in nova. https://review.opendev.org/c/openstack/nova/+/833436 | |
| 08:25:36 | zigo | stephenfin: Hi there! How are you? | |
| 08:25:37 | zigo | Where is tracked the SQLAlchemy 2.x patches, so I can attempt backporting them to Bobcat in Debian? | |
| 08:41:12 | 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:42:09 | zigo | Ah, thanks a lot, will try. | |
| 08:42:37 | zigo | Gosh... too many... how do I know what's missing from Bobcat? | |
| 08:46:32 | bauzas | what do you exactly want to backport ? | |
| 08:46:46 | bauzas | sqla changes that were merged after Bobcat RC1 ? | |
| 08:46:59 | zigo | Yeah. | |
| 08:47:18 | bauzas | all projects or just nova ?. | |
| 08:47:23 | zigo | All projects. | |
| 08:47:32 | zigo | Maybe I can just use the date of last change ... | |
| 08:47:51 | bauzas | well, the RC1 date is different for every project, that's the point | |
| 08:48:02 | bauzas | sec | |
| 08:48:02 | bauzas | but I can filter out the gerrit query | |
| 08:48:33 | zigo | Oh, there's a way to know with a simple Gerrit query? :) | |
| 08:50:51 | bauzas | for sure | |
| 08:51:28 | 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:58 | bauzas | and you'll just compare with the list of merged patches to see whether we missed any patch during the RC period | |
| 08:52:35 | zigo | I can just compare the code, yeah ... | |
| 08:53:20 | 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:51 | bauzas | https://review.opendev.org/q/topic:sqlalchemy-20+is:merged+mergedafter:%25222023-09-15%2522,25 | |
| 08:54:23 | bauzas | yeah, just be aware some projects may have branched RC1 late | |
| 08:54:47 | bauzas | (like nova, whoops) | |
| 09:21:31 | zigo | Thanks a lot, that's very helpful. So far, I backported 5 heat patches, continuing ... :) | |
| 09:29:14 | opendevreview | sean mooney proposed openstack/nova master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/nova/+/899753 | |
| 09:48:29 | zigo | sean-k-mooney: Oh my god... I'm having a headake reading your commit header!!! :/ | |
| 09:49:49 | bauzas | pyproject.toml-- | |
| 09:50:00 | sean-k-mooney | bauzas: thats not the problem and you know it | |
| 09:50:06 | bauzas | #xkcd872 | |
| 09:50:22 | sean-k-mooney | its we have not adapted to the pip change that was deprecated 2 years ago | |
| 09:50:23 | bauzas | err, #xkcd972 - standards | |
| 09:50:39 | 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:58 | bauzas | sean-k-mooney: sure I'm not debating your own changes, I'm rather arguing about pyproject.toml instead | |
| 09:51:06 | 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:31 | bauzas | sean-k-mooney: I'm basically hating what the python community did for packaging, ie. creating yet another standard | |
| 09:51:37 | sean-k-mooney | zigo: we are goign to continue to use reqiurements.txt | |
| 09:51:54 | zigo | sean-k-mooney: Guess which distro will be affected first ... :/ | |
| 09:52:07 | sean-k-mooney | zigo: its actully centos not debian | |
| 09:52:36 | 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:40 | sean-k-mooney | for now | |
| 09:52:41 | zigo | Well, it's not like if I was maintaining 400+ python packages for OpenStack that will all need patching ... :/ | |
| 09:53:06 | bauzas | zigo: yeah, thanks the python community for that brilliant idea | |
| 09:53:56 | sean-k-mooney | bauzas: you know it annoys me every time you do that right | |
| 09:54:16 | sean-k-mooney | bauzas: your being dilberatly dismissive of there efforts to solve an issue that many of there users had | |
| 09:54:42 | 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:55:01 | sean-k-mooney | zigo: ya i really dont like impertive systems for packaging | |
| 09:55:26 | sean-k-mooney | not that debina or rpm format get it correct either | |
| 09:55:27 | zigo | Though there a better ways than breaking everyone at once... | |
| 09:56:00 | sean-k-mooney | i dont know 2 years of deprecation after several years of supprot is kind of reasonsble | |
| 09:56:15 | sean-k-mooney | and to be clear the only thing that broke for us | |
| 09:56:27 | bauzas | 2 years is a very short timeframe IMHO | |
| 09:56:28 | sean-k-mooney | is an extention to setuptools we have in pbr | |
| 09:56:35 | zigo | I agree with Sylvain. | |
| 09:56:41 | sean-k-mooney | if we used plain setuptools with no extentiosn we would not ahve been broken at all | |
| 09:56:44 | bauzas | sean-k-mooney: fwiw, I +2'd the change itself | |
| 09:56:57 | bauzas | that's not because I hate that direction that I'll hold it | |
| 09:57:03 | zigo | There are thousands of upstream of python modules that will *NOT* be reactive enough. | |
| 09:57:05 | bauzas | the ship sailed and I need to move on | |
| 09:57:25 | 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:41 | bauzas | but I'm just throwing my hate by explaining why I think 2 years is not a respectful timeframe | |