Open Stack

On Thu, 2 Dec 2021 at 08:19, Thomas Goirand <zigo at debian.org> wrote:
>
> 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.

Currently, we provide 'binary' images for CentOS, Ubuntu and Debian.
CentOS provides delorean builds from master, so we can test those on
R-26. Ubuntu UCA appears soon after. Only for Debian do we need to
wait until ~release. It's not a problem, since we're dropping binary
images, I'm just providing some context.

>
> > 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.

This is all true - we do incur some additional work to build OpenStack
from source. OTOH, this has been done and has been stable for many
years.

A major benefit we get from source images is being able to point at a
local source repo when building images. Thankfully we need to do this
less and less frequently as time goes on, but it is still sometimes
necessary.

>
> Cheers,
>
> Thomas Goirand (zigo)
>