| opendevreview | Pierre Riteau proposed openstack/governance master: Fix SVG badge generation https://review.opendev.org/c/openstack/governance/+/965445 | 07:25 |
|---|---|---|
| * frickler also notes that the banner on https://docs.openstack.org/os-net-config/latest/ is misleading. there is no 2025.2 release of that project. but that may be tricky to fix | 08:15 | |
| mnasiadka | frickler: I think it ties in with the fact we should have a banner for inactive and retired projects | 09:41 |
| opendevreview | Pierre Riteau proposed openstack/governance master: Fix SVG badge generation https://review.opendev.org/c/openstack/governance/+/965445 | 12:24 |
| sean-k-mooney | fungi: clarkb | 12:38 |
| sean-k-mooney | fungi: so on the os-net-config thing i replied on the mailing list and linked the folk i think cna help sort it out | 12:38 |
| sean-k-mooney | fungi: i was expectign os-net-config not to be retired and thsoe contibutiosn to go via the opendev repo | 12:39 |
| sean-k-mooney | obviously that is nto what happend but os-net-cofnig is still used today in redhat installer and redhat are still mainitning it but im glad this issue was found and raised | 12:39 |
| sean-k-mooney | i am not really in a postion to do anythign beyond flag ti to folk but obviously the proces of transferign the ownership and ensuring the maintaienr ship is properly atributed if that transfer was granted was not completed fully | 12:40 |
| sean-k-mooney | again i dont know if the peopel contibuting to it ask the tc to transfer the project on pypi ectra before now | 12:41 |
| sean-k-mooney | presumbing good faith here i think updatign the mainter in the setupconfig was just missed | 12:41 |
| sean-k-mooney | fungi: we had a similar converation a while ago about https://opendev.org/openinfra/python-tempestconf | 12:44 |
| sean-k-mooney | and the retirement of refstack | 12:44 |
| sean-k-mooney | where i mention this si also still used by redhatin our github ci. and ideally that woudl move under the tempest/qa teams governace going forard | 12:45 |
| sean-k-mooney | i was expecting the same for os-net-config for it to be adopted by oen of the other openstack team defiend in the governace repo and continut to be maintaiend on opendev.org but i guess that not what happend | 12:46 |
| mnasiadka | Kolla is also using python-tempestconf - so having that maintained would be in our interest as well | 13:30 |
| fungi | sean-k-mooney: yeah, what was confusing on the os-net-config project was that they didn't update any of the package metadata to indicate it's a fork that moved off opendev, but added other people as maintainers on pypi and then removed our account so we don't really have any recourse over it now | 13:31 |
| sean-k-mooney | mnasiadka: gmaan had no object to it becoming part of the qa team deliverbels in the past so if that has not happend that woudl be where i woudl start | 13:39 |
| fungi | yeah, i avoided retiring python-tempestconf but it desperately needs a new owner. we could arrange to move it into the openstack/ namespace if there's a team willing to adopt it | 13:44 |
| sean-k-mooney | *no objection too | 13:45 |
| * sean-k-mooney stop typeing objection at object way to often | 13:46 | |
| * sean-k-mooney i think my brain stops checkign at "thats a word" rather than "thats the word i intened to type" | 13:46 | |
| fungi | the main reason i looked into the os-net-config situation on pypi when i saw the collaborator add/remove notifications i wanted to make sure we didn't have some sort of jia tan incident | 14:02 |
| bauzas | gouthamr: I may be late for the TC session in 5 mins, I have an important discussion at the nova PTG at the same time but I still would like to hear about the discussion about crypto libs | 15:56 |
| * bauzas will try to work around as much concurrent connections :) | 15:57 | |
| gouthamr | ack, ty bauzas | 15:58 |
| gouthamr | xz triggers indeed.. ty for the follow up on the ML sean-k-mooney | 16:05 |
| sean-k-mooney | so i was not ablt to attend the keystone rust topic bug rust is not an allowed lanague today for openstack projects | 18:06 |
| sean-k-mooney | so presumable to even have that dicusssion we would need to change that correct | 18:06 |
| sean-k-mooney | im specificly refering to https://github.com/openstack/governance/blob/master/resolutions/20150901-programming-languages.rst | 18:07 |
| clarkb | yes, as I noted on the etherpad I think that the goals we once had were not necessarily bad goals, but as time goes on its possible we need to modify the goals to change policy whether that is for programming language or requiring devstack use specific tools for cloud configuration. | 18:08 |
| cardoe | sorry I missed. I ended up staying on another PTG session. | 18:08 |
| sean-k-mooney | well i dont nessicarly object ot using rust if we actully add it to the list of allowed lanagues | 18:08 |
| clarkb | IIRC the goals for programming languages within openstack exist to ensure we have a common set of languages that we can "speak" while still managing to meet the needs of the project. So javascript is tehre because you can't python in a web browser (at least not without extra hoops) | 18:08 |
| sean-k-mooney | if we just start using it without doing tha tfor anythign non optional that is a problem IMO | 18:09 |
| clarkb | My interpretation of the current policy is basically javascript for web things, python by default, then go for the things that are more performance sensitive | 18:09 |
| sean-k-mooney | yep same more or less | 18:09 |
| sean-k-mooney | although i doing think we have anytrhing in go really | 18:09 |
| clarkb | and maybe go was premature (I don't think we ever really added any go projects), and maybe something else (like rust or java or whatever) is a better fity | 18:09 |
| sean-k-mooney | so i could see rust or zig as reasonable thing to add | 18:10 |
| sean-k-mooney | but before doing it in keystoen or nova we should do that, add it to the allowed list, dicuss the PTI aspects | 18:10 |
| cardoe | gouthamr: I'm going to add to an upcoming agenda the "Generated-by" and "Assisted-by" AI labels as a follow on. I've gotten feedback from more than one team at the PTG that they would like things to be a bit more clear. | 18:11 |
| gouthamr | ack ty cardoe | 18:12 |
| cardoe | I was actually just speaking to the cinder folks at their PTG about it which is why I missed the TC session. Just lost track of time. | 18:12 |
| clarkb | sean-k-mooney: yup I think if we consider the origianl goal(s) and lack of golang usage I'm comfortable saying that A) having code that is performance oriented is probably still something we may run into here and there and B) golang doesn't seem to have met that purpose so considering alternatives is reasonable | 18:12 |
| clarkb | (at the same time I think we also conflate poor design of the python code we've written with python is untenable and I like to avoid that if we can. For example the reliance on entrypoints) | 18:13 |
| fungi | the goal for having a list of allowed programming languages was so that we could make sure that when multiple projects use them they employ consistent tooling, coordinate their dependencies, and so on | 18:13 |
| fungi | like we do for python now | 18:14 |
| sean-k-mooney | effectivly we woudl need to write https://github.com/openstack/governance/blob/master/resolutions/20170329-golang-use-case.rst but for rust or any other language and adopt it | 18:14 |
| cardoe | As far as programming languages go, I think we need to be mindful of the domain as well. So taking golang for example. That's become the language of Kubernetes. So to get the best libraries, support, etc you really need to use it. | 18:14 |
| clarkb | compiled languages avoid the entrypoint problem by forcing you to compile all the things upfront. We can do that too with python and stop dynamically loading things | 18:15 |
| fungi | we did actually have two go projects, one was that thing dean was working on as a proof of concept and the other was the swift team's hummingbird object server rewrite. neither made it into an official release deliverable but the assertion was that before starting work on them everyone needed to agree to some ground rules | 18:15 |
| cardoe | I think we could probably write something up for Rust. Out of all the possible languages to add I feel like Rust isn't as big of a stretch for Python based projects. You've already got a number of Python projects that are using Rust under the hood. | 18:15 |
| bauzas | most of my concerns with another language is about the duplication of efforts we would have for common oslo libs and deps | 18:16 |
| sean-k-mooney | bauzas: not nessisarly | 18:16 |
| sean-k-mooney | you can use pyozide | 18:16 |
| sean-k-mooney | to have 2 way binding | 18:16 |
| bauzas | we already are limited in terms of maintainers for oslo and other libs, I don't want us to fragment ourselves more if we go down another route | 18:16 |
| cardoe | Yeah "import blah; help(blah)" works in a Python repl for Rust code. | 18:17 |
| bauzas | sean-k-mooney: there are technical possibilities indeed but I wanted to point out the human factor | 18:17 |
| sean-k-mooney | that is the large concern not the duplication i think | 18:17 |
| bauzas | if that human factor is not at risk with rust, then rust can be a good candidate then, provided we agree on the PTIs | 18:17 |
| fungi | but yes, for all of the "i rewrote this python project in go/rust/new-shiny look how much faster it is" cases i've seen, rewriting that same python project in python would also make it faster because you have the ability to redesign and avoid earlier complexities you ended up being forced to carry for historical reasons | 18:17 |
| bauzas | agreed | 18:18 |
| cardoe | fungi: so for me using Rust hasn't been about speed. | 18:18 |
| cardoe | It's about ensuring correctness. | 18:18 |
| cardoe | Python suffers from not really knowing what you're gonna see at runtime until you see it. | 18:18 |
| sean-k-mooney | you can do much fo that in python too | 18:18 |
| sean-k-mooney | espcilly if you lean into mypy | 18:18 |
| fungi | rewriting a project does make it easier to ensure correctness, regardless of whether you switch languages | 18:18 |
| cardoe | sean-k-mooney: yeah if we lean into mypy strict I'd love it. | 18:19 |
| fungi | which, again, is quite easy to do if you're (re)writing a project from the ground up | 18:19 |
| bauzas | yeah, we can't on one side lean towards rust for telling it can import python libs while on the other side we like his correctness... while forgetting Python can be good at that too | 18:19 |
| fungi | it's much harder to shoehorn into an existing mess of spaghetti | 18:19 |
| bauzas | and duck typing FTW :) | 18:19 |
| cardoe | bauzas: you get that same power in Rust, you just need to handle it at compile time. | 18:20 |
| cardoe | Or I should say all your cases are checked by the compiler. | 18:20 |
| fungi | but yes, just remember that it's the process of rewriting that yields the bulk of the benefits, not the choice of language | 18:20 |
| bauzas | cardoe: I've been well teached by Uggla about Rust, trust me ;) | 18:20 |
| sean-k-mooney | so just to be clear. im not advocating for or agaist rust. but if we ant to consider usign it i think it would be good to formally propos addign it to the languge list and start having these converstions in a form that is more actionabl | 18:20 |
| fungi | rewriting a project does give you an opportunity to switch languages, doesn't mean it's necessary | 18:21 |
| bauzas | sean-k-mooney: 100% agreed | 18:21 |
| bauzas | most of the existing projects seem nearly impossible to me to be rewritten | 18:21 |
| sean-k-mooney | i mean we coudl rewrite parts of nova if we had a need | 18:21 |
| cardoe | Heck if we stopped using arbitrary dicts and switched to dataclasses internally that'd be a HUGE step. | 18:22 |
| bauzas | cardoe: we have o.vo :) | 18:22 |
| sean-k-mooney | you woudl do it by writing rust modules with python interfaces | 18:22 |
| sean-k-mooney | and adopting them where it made sense | 18:22 |
| sean-k-mooney | cardoe: mnay projects did | 18:22 |
| bauzas | stopping to use arbitrary dicts is something we fixed years ago | 18:22 |
| sean-k-mooney | cardoe: nova does nto pass around random dicts and stop doing that before we supprot python 3 | 18:23 |
| cardoe | Where? | 18:23 |
| cardoe | Cause I still got a nova exception right now over a rando dict. | 18:23 |
| bauzas | olso.versionedobjects | 18:23 |
| bauzas | cardoe: then file a bug ;) | 18:23 |
| cardoe | I did last version release ;) | 18:23 |
| sean-k-mooney | cardoe: we didnt remove all dict usage where you jsut need a map | 18:23 |
| sean-k-mooney | but we use class and oslo versioned objects for anything over rpc | 18:23 |
| sean-k-mooney | and we do use data classes in someplaces too | 18:24 |
| bauzas | ++ | 18:24 |
| cardoe | Yep I'm saying internally. | 18:24 |
| cardoe | https://opendev.org/openstack/cinder/src/commit/658ff1ab4aec62a35fba6d63efac95db3b423f22/cinder/volume/driver.py#L441 | 18:24 |
| cardoe | Just to pick on something I discussed with them. | 18:25 |
| cardoe | What's the surface to create a Volume Driver? (which is a backend to a storage device vendor) | 18:25 |
| cardoe | **kwarg | 18:25 |
| clarkb | right but to go back to my earlier point thats bad python not python is bad | 18:26 |
| sean-k-mooney | that not a public api for one | 18:26 |
| clarkb | sean-k-mooney: even then if you as the maintainer have to come back to this years later its going to be extra work for you to trace it down | 18:26 |
| sean-k-mooney | and second this si in the legacy code that we have not rewrtiien | 18:26 |
| cardoe | clarkb: agreed. My statement was if we stopped using random **kwargs and random dicts that would eliminate most of the calls for using a new language. | 18:27 |
| clarkb | but importantly that can be rewritten more clearly with better contracts in python | 18:27 |
| bauzas | we welcome contributions for improving that interface | 18:27 |
| sean-k-mooney | cardoe: this is a very bad example because it does not follwo any of our normal patterens | 18:27 |
| bauzas | the image metadata properties are well better defined | 18:27 |
| bauzas | (for instance) | 18:27 |
| sean-k-mooney | well that is also in cinder not nova | 18:27 |
| fungi | everyone has written bad python at some point (i'll refrain from putting together a list of languages i've written poorly in, but suffice to say it's every language i've ever used). that doesn't make the language bad | 18:27 |
| sean-k-mooney | so maybe it follwos there patterns | 18:28 |
| cardoe | https://opendev.org/openstack/nova/src/commit/32f58e8ad6a7ff896cc6ae8a361e3a18f5b35c9a/nova/virt/driver.py#L756 | 18:28 |
| cardoe | What's "connection_info"? | 18:28 |
| bauzas | it comes from brick | 18:28 |
| clarkb | ubuntu 25.10 had a bug in rust coreutils that broke date and prevented the operating system from upgrading | 18:29 |
| cardoe | bauzas: nova defines the interface | 18:29 |
| bauzas | cardoe: that's indeed a docstring issue, we should have documented it like other virt interfaces we have | 18:31 |
| sean-k-mooney | os-brick is a delivber of the cidner project and they define the content of the connect info | 18:31 |
| cardoe | https://opendev.org/openstack/nova/src/commit/32f58e8ad6a7ff896cc6ae8a361e3a18f5b35c9a/nova/virt/driver.py#L488 | 18:31 |
| cardoe | What's network_info? | 18:31 |
| bauzas | cardoe: but as I said, connection_info is an object directly inherited from what os-brick gives us | 18:31 |
| bauzas | cardoe: do you think that rust would solve that discoverability issue ? | 18:31 |
| cardoe | I've literally not argued for Rust. | 18:32 |
| bauzas | then, what's the point about we discuss ? :) | 18:32 |
| sean-k-mooney | cardoe: network_info is https://opendev.org/openstack/nova/src/commit/32f58e8ad6a7ff896cc6ae8a361e3a18f5b35c9a/nova/network/model.py#L521 | 18:32 |
| bauzas | I thought the conversation started about rust becoming an official language, hence my confusion | 18:32 |
| cardoe | I said we could probably eliminate most of these demands if we were better about removing arbitrary dicts and defining things with dataclasses or going to mypy strict. | 18:32 |
| bauzas | if that's about spotting nova bugs, I apologize :) | 18:32 |
| sean-k-mooney | it is a list of vif model objuects https://opendev.org/openstack/nova/src/commit/32f58e8ad6a7ff896cc6ae8a361e3a18f5b35c9a/nova/network/model.py#L408 | 18:33 |
| sean-k-mooney | cardoe: for what its worth we have rewriten most interface to not use dict | 18:33 |
| cardoe | sean-k-mooney: I'm not saying that there's not been unofficial efforts. | 18:33 |
| cardoe | bauzas told me that its been entirely eliminated in nova. | 18:34 |
| sean-k-mooney | cardoe: no there were offical effort for the rpc api too | 18:34 |
| bauzas | anyway, 7:30pm here and I should probably stop | 18:34 |
| sean-k-mooney | cardoe: we have codifed all of our external interface where we can and most if not all our internal ones | 18:34 |
| bauzas | cardoe: I made false assumptions, apparently you did the same :) | 18:34 |
| sean-k-mooney | so far you have not point to one that we can change | 18:34 |
| bauzas | I never spoke about the fact we removed all our dicts as interface parameters | 18:35 |
| bauzas | I just said that there are structures that give us that possibility | 18:35 |
| cardoe | The world isn't black and white. Overall if the code base did a better job of checking and enforcing contracts of APIs it would eliminate a lot of the calls for another language. | 18:36 |
| cardoe | That's all my statement was. | 18:36 |
| bauzas | we surely can improve, I don't disagree | 18:36 |
| sean-k-mooney | cardoe: sure and in the limitd time we have made effort to improve. although not everyone agree that adding more typing to interface is an impremnet | 18:38 |
| cardoe | sean-k-mooney: Not trying to stir a pot or anything. Just stating that writing good Python requires effort. It's a blessing and a curse of Python. | 18:38 |
| cardoe | Cause I can bang out a Python script that does what I need in the happy case quickly. | 18:38 |
| bauzas | sean-k-mooney: yup, mostly because we always said that changing interfaces isn't a trivial effort while we have limited capacity for revierws | 18:39 |
| sean-k-mooney | cardoe: sure but form a comunication point of view it kind of sound like your suggestion we dont put effort into this | 18:39 |
| cardoe | There has not been a focused effort to do this across all of our code bases (oslo included) and to audit that and bring the coverage level of it up. | 18:40 |
| sean-k-mooney | sure but there also are not peole able to or willing to do that | 18:40 |
| cardoe | And you're only as strong as your dependencies are weak as has been pointed out by os-brick. | 18:41 |
| sean-k-mooney | i.e because they are not paid to or dont have the time | 18:41 |
| cardoe | Yep. It's not easy. | 18:41 |
| clarkb | thinking out loud here: that may be one reason why rewriting in something new is attractive. Its hard to miss the effort. Similarly the issues with CI coming up as a major problem for contributors are interesting to me because I spent years of significant dedicated time addressing the issue and eventually stopped beacuse the work was not really recognized as valuable | 18:41 |
| cardoe | clarkb: yeah you're probably right | 18:41 |
| cardoe | Plus people like to tinker. | 18:41 |
| clarkb | its hard to see the effort behind things that quietly work and prevent alarms | 18:42 |
| sean-k-mooney | clarkb: thanks for the work on pbr by the way | 18:44 |
| clarkb | sean-k-mooney: that was 90% stephenfin | 18:44 |
| sean-k-mooney | clarkb: it goes without saying but its worth saying form time to time | 18:44 |
| clarkb | but alsoi thanks! | 18:44 |
| clarkb | I was definitely in a support role of ensuring things got code reviewed and pushed along. stephenfin did the hard part of untangling the setuptools changes and writing updates to accomodate them | 18:45 |
| cardoe | I wonder if that might be a good place for AI to help with. | 18:47 |
| cardoe | Adding type hinting and such | 18:47 |
| JayF | cardoe: absolutely, I think cid might have used them for his IPA typing changes | 18:50 |
| cardoe | I'll just say the folks that I had seen been ra-ra Rust when coming from Python have been folks that feel like they need to read all of a function and what it calls to really understand what the API contract is of a Python function. So they feel warm fuzzies when that contract is declared up front. | 18:51 |
| clarkb | sean-k-mooney: fungi helped too! | 18:53 |
| sean-k-mooney | clarkb: well i was more taking that as an example of an often invisable effort | 18:54 |
| sean-k-mooney | clarkb: stephen does a lot fo those | 18:54 |
| sean-k-mooney | i alwasy try to priotize there work as a result when im able to | 18:54 |
| sean-k-mooney | cardoe: it can help but again some peole really hate them so i use them for new code personally wehre it does nto conflict with the style of the exsitng functions in the module | 19:00 |
| sean-k-mooney | cardoe: for example when pocing a new weigher i used types intrenally in the new file review.opendev.org/c/openstack/nova/+/953131/5/nova/scheduler/weights/resource_provider.py | 19:02 |
| sean-k-mooney | but in files where mypy is not used i kept with the exsing style | 19:02 |
| sean-k-mooney | i raised the topic of adding mypy to watcher and the team was a bit retsent to do it partly because fo familariy and the learning curve | 19:03 |
| sean-k-mooney | but we mortly agreed it would be good to start with our interfaces and abstract base classes and then see how it is next cycle | 19:04 |
| sean-k-mooney | i have found an softer approch end up working best as people can see what it looks like | 19:04 |
| sean-k-mooney | and get used to the idea | 19:05 |
| sean-k-mooney | fungi: before i dissapar for the weekend just an fyi i got my zuul ci mostly working and made some progress on my ai code review job | 19:08 |
| sean-k-mooney | fungi: https://zuul.teim.app/t/main/job/openstack-ai-code-review | 19:08 |
| sean-k-mooney | i broke the log upload in my base job which is why that is curerntly failing but i got it to the point of actully executing sst/opencode with a prompt and it outputing somehting | 19:08 |
| cardoe | Yeah that's a fair approach | 19:09 |
| sean-k-mooney | im going to hack on it a bit more at the weekend but i think im close to having it be able to do a review as a third party ci in hte next week or two | 19:10 |
| sean-k-mooney | https://github.com/SeanMooney/openstack-ai-style-guide/pull/1/files is where im developing it for those that are interestied but once its working and i have done some personal testing ill probly send a mail to the list and invite peopel to test it fi they are interested. | 19:18 |
| gouthamr | w00t - one thing this sorta thing can help with is to ease the very little bandwidth core reviewers have to flag obvious issues on a patch - hopeful that a contributor engages with this feedback and fixes things prior to a human review to speed things up… | 19:22 |
| sean-k-mooney | that is kind fo my hope yes. again following my own advice i wasnt to start softly so inially it will onlyrun if you leae a comment | 19:29 |
| sean-k-mooney | and intally only on a subset of repos but if it proves useful and teams are ok with it i could trigger it automaticly or on a wider set | 19:30 |
| sean-k-mooney | one thing i was conider ing it coudl do is if a patch has closes-bug: but does not have a release note it could perhaps generate one. that kind of a step 3 or 4 thing however | 19:31 |
| sean-k-mooney | i dont plan for it to ever directly modify the review to be clear | 19:32 |
| JayF | sean-k-mooney: we did discuss in Ironic the idea of just committing an AGENTS.md | 19:32 |
| sean-k-mooney | just comment with a link to the logs and maybe at somepoint i would coinder inline comment like the pep8 job but again softly at first | 19:32 |
| sean-k-mooney | JayF: ya i have debated between that and adding AGENTS.md to gitignore | 19:33 |
| sean-k-mooney | i think having an AGENTS.md may be a good thing eventually | 19:33 |
| JayF | my main argument against was that today we would have to symlink it to fifteen names | 19:33 |
| JayF | because agents.md isn't really a standard yet | 19:34 |
| sean-k-mooney | JayF: im currently using sst/opencode with the "GLM Coding Max" plan to power it | 19:34 |
| sean-k-mooney | so it will read agnets.md if its there | 19:34 |
| JayF | I use claude-code almost exclusively, but have played with some others with less success | 19:35 |
| JayF | but tbh these days it's getting more and more rare that I sit down with a cozy bug and an IDE lol | 19:35 |
| sean-k-mooney | right i tend to use claude most i have acess to cursor adn started playing with droid | 19:35 |
| sean-k-mooney | JayF: i was tempted to use claude for this but right now i didnt want to break my normal setup | 19:36 |
| sean-k-mooney | but im wrting the actions as "agents" that can run as claude code sub agents too | 19:36 |
| sean-k-mooney | this is still partly a learnign exersie for me to see if i can make these tools do useful work | 19:37 |
| JayF | docs are really the killer case in openstack | 19:38 |
| JayF | doc/code being side by side makes it easy for the AI to grok it | 19:38 |
| sean-k-mooney | and imporantly useful work that is repeatble and composeable without my direct intervention/oversight | 19:38 |
| JayF | and AI "dumbing it down" is a feature not a bug for us imo | 19:38 |
| sean-k-mooney | i created https://github.com/SeanMooney/openstack-ai-style-guide/blob/master/agents/doc-to-markdown.md?plain=1 to help on the "docs to something ai can consume side" | 19:39 |
| sean-k-mooney | so here is an example of the ai policy converted to markdown so that ai can consume it https://github.com/SeanMooney/openstack-ai-style-guide/blob/master/references/ai-policy.md | 19:40 |
| fungi | sean-k-mooney: oh awesome! | 20:03 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!