Open Stack

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)