| opendevreview | Merged openstack/openstack-manuals master: Imported Translations from Zanata https://review.opendev.org/c/openstack/openstack-manuals/+/1000225 | 05:47 |
|---|---|---|
| opendevreview | OpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/1000684 | 05:56 |
| opendevreview | Gregory Thiemonge proposed openstack/election master: Adding Gregory Thiemonge candidacy for Octavia https://review.opendev.org/c/openstack/election/+/1000689 | 07:16 |
| opendevreview | Merged openstack/election master: Add Andriy Kurilin candidacy for Rally 2027.1 PTL https://review.opendev.org/c/openstack/election/+/1000456 | 10:11 |
| opendevreview | Merged openstack/election master: Adding Gregory Thiemonge candidacy for Octavia https://review.opendev.org/c/openstack/election/+/1000689 | 12:18 |
| JayF | https://github.com/openstack-experimental is the existence of this a trademark concern? cc TheJulia | 15:38 |
| TheJulia | absolutely | 15:38 |
| TheJulia | And the creator has even acknowledged that | 15:39 |
| TheJulia | on the mailing list of all places. | 15:39 |
| JayF | I knew the keystone-ng stuff, tbh this is the first I realized it was in an openstack-branded org | 15:41 |
| JayF | that's the only reason I dredged it up | 15:41 |
| fungi | keep in mind that "keystone" is also trademarked by openinfra (well now by lf effectively) | 15:42 |
| fungi | foundation legal and trademark enforcement is also engaged already as of a few months back | 15:44 |
| *** dviroel is now known as dviroel_lunch | 15:53 | |
| TheJulia | yup | 16:05 |
| gtema | jayf - don't push all frustration at openstack-experimental. There is https://github.com/openstack-exporter/openstack-exporter and many others out in the wild - those are by no means different | 16:19 |
| JayF | This statement is what really bothered me, to be honest. There's a lot of people who invest time and effort into governance and keeping our community unified in some technical aspects. https://usercontent.irccloud-cdn.com/file/LOtqF8Nt/part-of-openstack-soon.png | 16:20 |
| JayF | openstack-exporter, or any other openstack-* I've seen misusing our trademarks make that kind of statement | 16:20 |
| JayF | **have not made that kind of statement | 16:21 |
| gtema | so if we rename it to e.g., os-experimental you would be immediately happy? | 16:22 |
| gouthamr | if you changed "will" to "may", i wonder if it will actually mean what you intend? | 16:22 |
| gouthamr | because everything is an "experiment" around here at some point, and we have all these processes/infra to make that happen.. this seems like a closed experiment in one sense that's not happening in the community | 16:23 |
| gtema | I just want to understand why one occurence of many where we explained the necessary temporary step multiple times causes such an issue | 16:24 |
| gouthamr | i'm reading further on the github page, and this feels fine to me: | 16:25 |
| gouthamr | "This organization is not an official OpenStack namespace, but is made by the OpenStack community members to perform architectural experiments before bringing them to the mainline becomes possible." | 16:25 |
| fungi | perhaps part of the disconnect is that the intent of the language requirements policy is to prevent things from being an official released openstack component until there's community agreement and necessary integration needs are met, but that shouldn't stop teams from experimenting in repositories inside the openstack/ git namespace on opendev | 16:25 |
| JayF | The temporary step is essentially building something outside of the community to try and route around the work to get the community using an additional language. This bothers me at a basic level as someone who cares about governance. | 16:25 |
| * JayF == fungi | 16:25 | |
| gtema | btw - just changed the "will" to "may" as suggested | 16:25 |
| JayF | And I know how upset I'd be if I found that someone had used LLMs to recreate Ironic -- including using our name -- in another language. | 16:26 |
| JayF | Even though I'm not invested in keystone; I'm invested in the community indicating that ^ is not an OK pattern | 16:26 |
| fungi | (or even in the same language presumably?) | 16:26 |
| JayF | fungi: yeah, really. I'm thinking chardet tbh | 16:26 |
| gtema | I do keystone in python, I do keystone in Rust, what is your concern with that? | 16:27 |
| JayF | (context: https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense ) | 16:27 |
| JayF | My concern is that keystone is a term that refers to official openstack deliverables written in python. There is no keystone in rust. | 16:27 |
| gtema | not officially, because rust is not allowed. But that does not forbid us experimenting with how it would look like if we would rewrite it to improve it | 16:28 |
| gtema | we as team made decision to try it out, and present results to community for the evaluation | 16:29 |
| gtema | otherwise it would be another "water" of talking without facts | 16:29 |
| fungi | i don't see a problem with creation of a https://opendev.org/openstack/keystone-rs repository for the keystone team to experiment with a proof-of-concept reimplementation in rust, getting started putting the necessary ansible roles in place to effectively test it with zuul jobs and so on | 16:30 |
| fungi | it just wouldn't be part of the openstack release officially until the various requirements of the language policy were met | 16:30 |
| JayF | fungi: to me, I personally agree, but part of my care is ensuring that such an approval go through the elected technical project leadership | 16:30 |
| JayF | fungi: if not, the TC might as well disband today or be replaced with a mechanical turk | 16:30 |
| fungi | well, it would still be up to the tc to agree when keystone-rs is ready to be an official alternative | 16:31 |
| gtema | fungi: we were evaluating doing initial dev on opendev, but decided against since the initial work is what would put a lot of additional unrelated effort. Now we are ready to invest in it sicne we see the results | 16:31 |
| gouthamr | yes, and i don't see that proposal yet.. there is however a proposal to make rust an official language.. the tc's reviewing | 16:31 |
| gouthamr | https://review.opendev.org/c/openstack/governance/+/998652 | 16:32 |
| gtema | gouthamr - proposal of what? Proposal of moving of keystone-rs to opendev? | 16:32 |
| gouthamr | don't be alarmed there are no comments posted.. i for one have draft comments and haven't gotten time to click buttons and post | 16:32 |
| gouthamr | and people are observing holidays/vacations | 16:33 |
| gtema | sure, also a vacation period so I am not alarmed | 16:33 |
| JayF | This is all I really care about; tbh. I want things in the right places and following the right processes because quite frankly, I think one of our biggest competitors can potentially be LLM coded remakes of many openstack services. At that point, the real value of OpenStack will be the brand and trust we've built through decade+ of stable and security support. | 16:34 |
| JayF | and as a US-ian, I have personally observed that "trust people to generally do an OK thing" is not as safe of an approach to governance as "ensure the enforcement mechanisms kick in if people go outside the lines" | 16:35 |
| gtema | but that is exactly the reason why the community should have more flexibility with the used technologies, competitors do not care, and if I would be competitor I would not name it openstack-experimental or keystone-rs and a proposal to start adopting rust - I would just name it keystone and start selling it | 16:37 |
| gtema | I have still a feeling you somehow misunderstands the whole idea about keystone-rs - it is attempt by the community to imrpove our stand against competition. It is done FOR the community | 16:38 |
| fungi | well, if you named it "keystone" and started selling it in any regions where the foundation has that name trademarked, you'd be looking at an expensive infringement lawsuit, but i assume you meant sell it under some non-infringing name (your company's legal department wouldn't responsibly let you sell something with a name that could cost you a lot in legal damages) | 16:42 |
| gtema | it was just an example grown from previous statement regarding competitors rewriting with LLM the whoe OpenStack | 16:43 |
| fungi | yes, as the hypothetical competitor in your example i mean | 16:43 |
| gtema | could be | 16:44 |
| fungi | anyway, i think a lot of the animosity would be side-stepped if teams conducted poc experiments in the same code review system where they work on their official release deliverables. it'll be a prerequisite for any official approval in the end anyway, and when it's involving a new programming language there's really no better way to get buy-in from the rest of the project where | 16:48 |
| fungi | other teams may want to do similar experiments and could share some of the same base infrastructure and collaborate on establishing norms, patterns, workflows | 16:48 |
| fungi | we had repositories with golang code in them as part of figuring out what the tc's requirements for golang-based projects should be | 16:49 |
| fungi | otherwise there's a catch-22 problem | 16:49 |
| gtema | fungi - agreed. It would be great if a guideline for that would have existed describing what you say. Maybe the result of our experiment could be exactly such a guidance | 16:51 |
| fungi | without any rust-based projects sharing the same developer infrastructure as the rest of the project, it's hard for the tc to be reasonably informed as to what that would require | 16:51 |
| fungi | and developing a rust-based project in github doesn't directly translate to what requirements should be for having one in openstack | 16:52 |
| gtema | don't forget we are now many steps further compared to the current "new language guidance" or what I read between lines position of some others: we have a code and a proov and not only an unproven idea | 16:53 |
| gtema | s/proov/proof/ | 16:53 |
| fungi | yes, but it's not being built and exercised in ci by zuul jobs, for example, so the requirements for being able to do that are presently unknown (though some guesses could be made). decisions for how documentation trees in such a project should be organized and what toolchains should build them, how translations will be managed with weblate, how dependencies will be vetted and | 16:55 |
| fungi | coordinated with other rust-based deliverables... | 16:55 |
| gtema | I am using rust jobs in the codegenerator repository since more than a year for pushing results to github cli repo | 16:56 |
| gtema | so some things are definitely tested | 16:56 |
| gtema | you need to at least accept - developing such experiment on opendev leads to high "overhead" that would be "wasted" should the experiment fail or at the end new programming language not accepted. I am not able to invest so much more | 16:58 |
| gtema | I mean speculatively | 16:58 |
| fungi | i see a lot of references to rust in https://opendev.org/openstack/codegenerator but the only thing i'm finding that's rust-like source code is in a jinja template | 17:01 |
| gtema | it uses jinja templates to produce rust code. It is then applied on top of github repo checkout and compiled | 17:01 |
| gtema | https://opendev.org/openstack/codegenerator/src/branch/master/playbooks/rust/all.yaml | 17:02 |
| fungi | got it. so that's how you'd recommend structuring rust-based openstack projects in opendev | 17:02 |
| gtema | this is more a cornercase scenario though | 17:02 |
| fungi | to be fair, i'm unfamiliar with rust development workflows, i've used cargo to compile some stuff occasionally but haven't seen the jinja template approach | 17:03 |
| gtema | not necessarily the same way, as said codegenerator overlays generated code on top of existing and compile it. It is not doing a regular "let's build, test and publish" | 17:03 |
| gtema | the keystone-rs usecase would be more similar to our current python based jobs with "build", "test", etc | 17:04 |
| gtema | cargo can be compared to uv | 17:04 |
| gtema | to certain extend | 17:05 |
| fungi | how do you manage system dependencies (librust, cargo, other toolchain components)? | 17:05 |
| gtema | it is a top level build tool, and you would "cargo build", "cargo test", "cargo publish", etc | 17:05 |
| fungi | with bindep or some other mechanism? | 17:05 |
| fungi | yeah, i get that cargo is like make or other workflow tools | 17:05 |
| fungi | i'm more interested in the steps that come before running cargo | 17:06 |
| gtema | current rustup zuul job takes toolchain version. We would map mutltiple independent jobs like py312, py312 just for rust for using different compiler versions | 17:06 |
| gtema | but that is rarely necessary | 17:07 |
| JayF | cargo is very much a tool built in the "if you don't have it, bring it yourself" sense | 17:07 |
| JayF | it can be annoying to work with from a package manager POV, but it's pretty great from a "I just want it to work" POV | 17:07 |
| fungi | okay, so rustup is another tool that takes care of things like finding which librust you need for the target platform and stuff, like autotools in traditional c-based projects? | 17:07 |
| gtema | we have "ensure-rust" role now in zuul that is used by codegenerator | 17:07 |
| gtema | and it is capable of taking param of toolchain version | 17:08 |
| JayF | fungi: rustup is the (I think official?) tool used to install + keep up to date an upstream rust binary | 17:08 |
| gtema | yes, correct | 17:08 |
| gtema | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-rust | 17:09 |
| gtema | so we would basically build jobs that use "ensure-rust" followed by executing "cargo build" or "cargo test" | 17:09 |
| gtema | not different to what we do now in py | 17:10 |
| JayF | I suspect one of the interesting-shaped problems rust will have (go has this too) compared to python is that, depending on security policy, you may need to ensure for some downstream bugs we rebuild binaries even if code is the same (or do scheduled rebuilds, or stop offering binaries on a "forever" timescale) | 17:10 |
| fungi | well, yes, we already have a governance policy that states binary artifacts are strictly out of scope | 17:11 |
| JayF | not to mention generally getting folks who know rust on the VMT, but that's more of a self-solving problem. I'm more curious about how to approach long-term-support of rust deliverables when that ecosystem doesn't really like that model | 17:11 |
| fungi | openstack releases source code, not compiled binaries | 17:11 |
| gtema | rust has lock files just like python's uv, this way you can force rebuild | 17:11 |
| fungi | the expectation currently is that distributions take our released source code and create binary packages with their own downstream build toolchains anyway | 17:12 |
| gtema | I am not 100% sure we need to release binaries at all - we publish code to the rust ecosystem (similar to pypy) and the distro tools can build binaries themselves | 17:12 |
| JayF | fungi: I think that scope itself is something that should be re-evaluated in light of a language like rust (vs a language like python) | 17:12 |
| JayF | gtema++ not releasing binaries at all would be one interesting solution | 17:13 |
| fungi | it's the solution i would push for if that decision gets re-litigated | 17:13 |
| gtema | with the package released to crates.io you install (building locally) with "cargo install <package>" | 17:13 |
| JayF | part of this is why adding new languages is tough, you almost gotta re-evaluate policies for "spirit of the law" in context of the new lang | 17:13 |
| fungi | we don't have the bandwidth to track vulnerabilities in dependencies, never have, and i don't see that changing | 17:13 |
| gtema | distros are building rpm/pkg exactly this way | 17:13 |
| JayF | gtema: I'm having to supress my #gentoo-* support coded "WAIT NO DON'T" to use of `cargo install $thing` :D | 17:14 |
| gtema | :) | 17:14 |
| fungi | well, it's no different from distro package builds invoking `make install` you just install to a tree that you then package up | 17:14 |
| gtema | I just know all major distros are always building packages directly from crates.io or actually by embedding source code into their srpm | 17:15 |
| JayF | fungi: yeah, but no quick start guide I've seen is like "BTW, make sure prefix is opt or usrlocal :D) | 17:16 |
| gtema | the only "interesting" usecase is releasing container images with the built rust code - I have a very good experience with microcontainers only having the binary and no sh inside | 17:16 |
| fungi | i mainly know debian packaging since i do some of it, and the requirement there is that all dependencies are also packaged and built from source | 17:16 |
| JayF | fungi: do they try to integrate deps, or do an independent stack build for each binary? | 17:16 |
| gtema | fungi - correct, this is also something zigo was confirming in the mailinglist | 17:16 |
| fungi | and needs to be able to build hermetically without network access entirely from local copies of source | 17:16 |
| JayF | fungi: meaning like, does rust-myapp use the same version of myapp-rust-lib as rust-myotherapp, or can they dep on separate ones | 17:17 |
| gtema | it depends like with all binaries - rust support dynamic loading | 17:17 |
| fungi | the expectation is that all packaged software agrees on one consistent set of dependencies | 17:17 |
| *** dviroel_lunch is now known as dviroel | 17:17 | |
| gtema | but from the building - static linking only for things built from source | 17:18 |
| JayF | gtema: well, I was asking from a package mangaer POV. For instance, contrary to what fungi reported for debian, Gentoo generally will "obey" the cargo lock files and make a separate source bundle for download | 17:18 |
| fungi | not because the language can't have different components with different versions of dependencies, but because tracking and fixing security vulnerabilities in dozens of versions of the same library is untenable | 17:18 |
| JayF | e.g. it might get myapp.crate for source (IDK the actual extension?) + myapp.crate-version.tar.gz with all the rust source deps inside | 17:18 |
| fungi | if the distro isn't on the hook for actually securing the versions of software they package then it may be a different story | 17:19 |
| JayF | Gentoo def. follows the "it's SECURABLE" model | 17:19 |
| fungi | but at least in debian's case there's a strong push for exactly one version of a library in the distro release | 17:19 |
| JayF | but it's hard for a lego blocks style distro to be secure outta the box | 17:20 |
| fungi | and so projects get patched to work with the same version of that library where possible | 17:20 |
| JayF | yeah that'd be infinite work for a rolling relaese distro. both decisions make sense in context | 17:20 |
| fungi | well, debian is effectively under continuous development too, it's no less work there. mainly it's one of the reasons to just not package a project if it can't be flexible about what library versions it will work with | 17:21 |
| fungi | if trying to make an application work with the same versions of libraries as other packaged applications is too hard, then it's not packaged/distributed | 17:22 |
| fungi | or gets dropped from the distribution when that problem arises | 17:22 |
| fungi | from openstack's perspective we'd want to avoid putting distributions in that situation, so i think would adopt a policy that at least all of *our* rust-based deliverables should agree on common versions of dependencies and hopefully mostly the same dependencies in order to limit sprawl | 17:23 |
| zigo | There may be 2 versions of a lib at a given time, to allow ... transitions ! :) | 17:23 |
| fungi | of course | 17:23 |
| fungi | but that's a temporary situation until all applications have rebuilt on the new lib | 17:25 |
| zigo | The same is true for Python stuff, except there's only one version. It has been painful at times, like when switching to SQLAlchemy 2.x. | 17:25 |
| JayF | yeah. Gentoo has entire projects to handle that kinda work for C and Python. I just don't think anyone had the taste for it for golang/rust. | 17:26 |
| zigo | Yeah, and that's only for dynamic libs, this does not apply to static builds like rust. | 17:26 |
| gtema | zigo - is lock file respected of the main dep versions from Cargo.toml? | 17:26 |
| gtema | I think with the policy like you describe Cargo.lock should not be used at all | 17:27 |
| zigo | Not sure, though we patch Cargo.toml sometimes to make it more permissive. | 17:27 |
| zigo | I'm not very good at rust packaging (yet). | 17:28 |
| gtema | than most likely only Cargo.toml is really read | 17:28 |
| gtema | Cargo.lock strictly binds the version while Cargo.toml describes range | 17:28 |
| zigo | Got rabbitmqadmin-ng to RC bugfix (fungi, if you have time, I need help for it), which is annoying me for deps versions... | 17:29 |
| fungi | also it's fair to say that the "rust team" in debian does things a little differently from other language teams, which has created some friction in the poast | 17:29 |
| fungi | past | 17:29 |
| clarkb | what is the high overhead for starting such an experiment in opendev? it should take about 10 seconds to create a breanch in the keystone repo called experimental-rust or whatever and then you're set | 17:29 |
| gtema | fungi - I feel even python is packaged in debian very differently to RH | 17:30 |
| clarkb | I feel like that assertion just isn't based in reality and is instead an opinmion that keeps getting thrown around but the overhead is really small and imo comparable to clicking the fork button in github or whatever system you use instead | 17:30 |
| gtema | clarkb - artifacts publishing (including containers) is something that just require additional (unnecessary for the moment) work. And please don't (respectfully) start with "you can always put credentials to quay.io into your secrets" and push them there | 17:32 |
| fungi | gtema: oh most things in debian are packaged differently than how rh approaches it, but my point was that the debian rust team packages things differently than is typical for most other debian packages | 17:33 |
| clarkb | why is that not a valid response? I/we use it for many systems and it works fine. | 17:33 |
| gtema | we are also heavily using gh issues for planning and even for security work. Also dependabot is in heavy use | 17:33 |
| clarkb | but ok the problem isn't the code hosting and review its publication of artifacts and yes that takes a few extra steps | 17:33 |
| fungi | gtema: it sounds like you've built up a project in a separate ecosystem which is going to make it harder to move when the time comes? | 17:34 |
| clarkb | but it is completely doable and we do it every day. And it comes with useful extra features like speculative execution | 17:34 |
| gtema | hardcoding secrets, even encrypted, is not what you should do when you have possibility of not having any secrets at all | 17:34 |
| fungi | gtema: zuul supports acting as an oauth federated provider too | 17:34 |
| gtema | clarkb - I didn't say you can't do it, I say - it is not worth of invest at this stage and from security pov is not what you should do at all | 17:34 |
| fungi | you authorize it and then don't need secrets | 17:34 |
| gtema | don't forget oauth support is not existing very long | 17:35 |
| clarkb | gtema: no you said 'please don't (respectfully) start with "you can always put credentials to quay.io into your secrets" and push them there' which is a non starter conversation and comes across as being unwilling to have a dialogue around what the actual concerns/issues are | 17:35 |
| gtema | I mean you can argue this for new projects, but not for something what is there since a year already | 17:35 |
| clarkb | I appreciate that you've actually expanded on what your concerns are. But starting with "don't talk to me about this" is not helpful | 17:36 |
| gtema | we we having this conversation already and I knew quite good what you will say. But sorry if that didn't sound polite enough | 17:36 |
| gtema | were | 17:37 |
| gtema | I would again summarize: overhead of publishing containers, missing dependabot (or any other bot for automatic bumping of dependencies) and literally lack of reasonably usable issue tracker | 17:38 |
| clarkb | its not even that it is is rude. Its that OpenDev is built on the idea that we can and should work together to make the tools we rely on to build software more capable. And shutting down before we can even have that discussion is detrimental | 17:38 |
| gtema | lauchpad is a torture | 17:38 |
| fungi | i'm sure they love hearing that too | 17:39 |
| gtema | one of the things that is done in keystone-rs is a major rework of the federation/oidc/oauth support so that it would allow zuul provision and auth into VMs without any creds (once clouds deploy it) | 17:39 |
| clarkb | fwiw opendev does not require you to use launchpad. Some projects do use github issues. I think starlingx uses their own jira? | 17:40 |
| gtema | I know, but it is much much more comfortable when you have code and issue tracker in one tab | 17:40 |
| fungi | but not every community can invest the sort of money into these services that microsoft can, i don't think that's a reason to give up and just use microsoft | 17:40 |
| gtema | I asked few times few years ago whether we can use gitea issues. I understood explanation and thus not repeating the query anymore. But that would definitely make it so much easier | 17:41 |
| gtema | at least for me | 17:41 |
| fungi | yes, the main blocker there is finding someone with the time to push efforts like our central sso spec forward | 17:43 |
| clarkb | unfortunately the cluster is still split up as independent gitea instances. And with the state of the internet in the last few months converting gitea to a read write setup is looking more involved | 17:43 |
| fungi | right, but a prerequisite to even considering that would be having a way to bridge identities to our services | 17:44 |
| clarkb | I get the sense that codeberg is in a never ending battle (as are github et al). Our read only mirror system buffers us a bit | 17:44 |
| gtema | pros and cons are everywhere, and they are having different weight for everybody. That's why every person is making a different choice | 17:45 |
| zigo | fungi: I will *NOT* use the rust team mono-repo non-sence ! | 17:47 |
| gtema | yeah, my chin fell off when I saw that | 17:48 |
| fungi | zigo: understandable, i don't really get why they make that choice either | 17:51 |
| zigo | Lots of DDS feel the same. | 17:52 |
| JayF | https://codeberg.org/gentoo/gentoo/src/commit/7a7ae7bf98a559969fe6b812e6d969c953c01ff1/sys-apps/ripgrep/ripgrep-15.2.0.ebuild#L7 gentoo rust ebuilds are written in the language of sadness lol | 17:52 |
| JayF | "here, step 1: download 47 tarballs" | 17:53 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0107: IPA Container HWM Security Misimplmented https://review.opendev.org/c/openstack/security-doc/+/1000784 | 22:01 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0107: IPA Container HWM Security Misimplmented https://review.opendev.org/c/openstack/security-doc/+/1000784 | 22:12 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
