On 12/10/21 5:29 PM, Jean-Philippe Evrard wrote:
Totally agree. I have so many points I want to raise. I realise asking what I have in mind will cause more trouble on this mailing list than the value it will bring. I just want the TC to think broader than the "we used to do it this way, and this is the only way".
Willing to change things within OpenStack is a completely different topic than "doing things my own way". I very welcome change if you have a cross-project attitude but I don't welcome "we don't do like the others, because we can" type of thinking. Packaging Telemetry, I've hated many times the design decision that was just a little bit different. It wasn't better or worse, just different. And it caused a lot of troubles just because I had to learn "their way" of doing things. I suppose the experience was the same for contributors. For example, aodh has it's build-dependency (well, "test requirements" if you prefer the Python wording than the distro ones) in setup.cfg instead of test-requirements.txt. Both works, but when I upgrade any component, I diff the test-requirements.txt between version, to see if there's new Build-Depends: to add to my package. But with Aodh, I have to remember to do it with setup.cfg. Its *VERY* annoying. Yes, I'm aware that this way, Aodh can have different test-requirements for mysql and postgresql for example. But this is still very annoying. I would have very much prefer if the Telemetry guys pushed so that *ALL* projects would move to push test-requirements.txt within setup.cfg, and *THEN* I would have accepted the change. Do you see where I'm going? :) I have other examples in mind, but I believe what's above is enough.
I am sure the topic raised some questions, and will give enough food for thoughts. Hence, I hope it will result in the improvement of OpenStack :)
If you don't do things on your own different than the others, and push every projects to move one direction at the same time then it's going to be an improvement. If you are the only one doing your own way, it's going to be a regression, and a pain for everyone.
Just my opinion, but I think buying into container hype to the point where we make OpenStack only deployable through containerization would be a massive step backwards.
I didn't say it was a goal or if I consider this important. I just wanted to mention that they are other ways to consume software than distribution packages.
Probably, but it's not up to you to decide for the others how they want to consume your deliverables.
Side note: I have spent to much time on this, so I will just step out now. I hope the TC got enough details about what to make out of this in the future. If you need an extra $0.02, you know where to find me :)
Regards, Jean-Philippe Evrard (evrardjp)
I very much hope that Skyline will be in a super nice shape in 6 months from now, so I can include in in Debian Bookworm! :) By the way, we discussed Python packaging a lot, but never JS. There's a huge discussing that sooner or later will have to get started too. NPM is a very dangerous thing that often leads to "npm install world" (ie: a JS orgy that is barely maintainable). I have to admit that I didn't look closely into how that's done in Skyline. But let's just take something else as the worst example: Grafana. I've heard someone from Red Hat attempted to package it, and discovered it included (directly or indirectly) 1600 JS packages, and then gave-up. How is Skyline in this regard? Cheers, Thomas Goirand (zigo)