Hi Michal, Thanks for your reply. I'm sorry to say that your reply shows a poor understanding of what distributions and packaging are in general, and what Debian does for OpenStack in particular. But I'm not surprised, this isn't the first time I see this. It also happened when I was employed by Mirantis, and with cloudwatt. People usually just dismiss packaging because they see it as a black-box they cannot act on, because they just happen to not do packaging themselves. On 12/2/21 8:37 AM, Michał Nasiadka wrote:
Hi Thomas,
Thanks for your opinion - but we can’t really wait until each Debian OpenStack release to test all the features (and what will be broken) - we already trail long time after the official OpenStack release due to other issues. That would significantly lengthen the delay and the process involved.
This isn't fair, and IMO isn't truth. Usually, Debian packages are ready *before* the final release, often just a week after the first RCs are out. The only reason why there's always one or 2 glitches, is because I couldn't install the new release until everything is finished (and from my side, including updating my puppet scripts for the new release of puppet-openstack). So, we're talking about just a few days delay after the release. This normally gives you enough time to fix things, and have Kolla ready the day of the release. I used to package all the beta releases, twice per OpenStack release. Though nobody ever consumed them. And these days, not all projects are release beta releases, so it is kind of useless.
It’s also a direction to make the external dependencies smaller - not bigger - and I see the custom things added from packager perspective as a dependency.
IMO, that's a very wrong perspective. Package maintainers (that's how we're called, not "packager" please...) are adding automations and system integrations. If you refuse them, this means you'll have to implement them yourself. Remember that I use puppet myself, so I very well know what I'm talking about, when discussing config management and package integration. When I can make a choice of where to do the automation, system dependency, etc., then it goes to the packaging: this is the normal and natural place to do it. A config management system should not be the one taking care of any of the things that packages normally take care of (like dependencies). Handling them in your config management system is not only an heresy, it's also using the wrong tool for it, and achieving a poorer result. Also, handing dependency management using something like pip is a non-sense, because it only knows about Python dependencies (not anything else), and it's been demonstrated so many times how bad pip is as a dependency solver: for example, it broke the CI so many times, showing its defects. Another thing you're seeing wrong, is about smaller dependencies. First, having one more Python package will not hurt, and if it is there, it is for a reason. Second, packages are designed to have the smaller amount of dependency possible. Always. As a rule. If there's something wrong there, it's easy to fix (and you could contribute to it...). And we also make sure that everything works together, adding patches when needed (how are you going to manage patches?). I'm not hoping to convince you, I feel it's already too late. Though I can't help myself to let you know I believe you're doing the wrong technical choice. Cheers, Thomas Goirand (zigo)