| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 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 | but a trait is pretty heavy for each "just need a new libvirt version" sort of thing, | |
| 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 | and I do not think we assert that all the extra specs are schedulable | |
| 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 | but I can filter out the gerrit query | |
| 08:48:02 | bauzas | sec | |
| 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 | |
| 09:57:59 | sean-k-mooney | zigo: right but thats why they implemetned a fallback that will work for vaniall setuptools out of the box | |
| 09:58:02 | bauzas | but that's not the first time the python community is trampling us | |
| 09:58:47 | sean-k-mooney | i mean we dont supprot or release for 2 years | |
| 09:58:47 | bauzas | anyway, I should stop arguing here as it's useless, I should rather invest time in the python community itself | |
| 09:58:54 | sean-k-mooney | we only supprot them for 18 months | |
| 09:58:57 | sean-k-mooney | offically anyway | |
| 09:59:11 | sean-k-mooney | so your holding them ot a higher standard then we hold ourselves? | |
| 10:00:15 | zigo | BTW, Python 3.12 thingy will start in Unstable next November. | |
| 10:00:24 | zigo | Expect bug reports and patches from me ... | |
| 10:00:33 | bauzas | I have the opinion that the lower you're a dependency, the longer you need to keep support | |
| 10:00:44 | zigo | Yet another thing: how come every single new version breaks my world ... | |
| 10:00:51 | sean-k-mooney | next november as in 2025 or as in that then next thing to start in novemerb on your backlog | |
| 10:01:00 | bauzas | and a language sounds to me like probably one of the lowest dependencies we have and the most commonly shared | |
| 10:01:04 | zigo | Oh sorry, as in this month ! | |
| 10:01:10 | sean-k-mooney | ok :) | |
| 10:01:27 | sean-k-mooney | i was like that seams far off | |
| 10:01:44 | zigo | 3.14 is planned for Trixie (ie: debian 13). | |
| 10:01:45 | bauzas | forcing people to upgrade by 2 years if you're a very common library is kinda harsh | |
| 10:02:16 | sean-k-mooney | bauzas: your only forced to upgrade if you dont pin your deps | |