Open Stack

Sorry for top posting but I just wanted to mention that Kolla supports
also Debian and Ubuntu, in both binary (meaning using distro packages)
and source (meaning using upstream sources) flavours.

The only Kolla project the above is not true about is Kayobe, and that
is where the misconception that we support only CentOS comes from.

-yoctozepto

On Fri, Dec 11, 2020 at 5:33 PM Thomas Goirand <zigo at debian.org> wrote:
>
> On 12/11/20 3:09 PM, Braden, Albert wrote:
> > The old Centos did this work for us; Centos was built on RHEL source that had already been tested by paying customers, and bugs fixed with the urgency that paying customers require.
>
> This sounds like free beer instead of free speach...
>
> > Adding an upstream build (Stream) to the existing downstream (Centos 8.x) was fine, but I'm disappointed by the decision to kill Centos 8. I don't want to wax eloquent about how we were betrayed;
>
> I'm surprised that you're surprised...
>
> > suffice it to say that even for a free operating system, suddenly changing the EOL from 2029 to 2021 is unprecedented, and places significant burdens on companies that are using Centos in production. I can understand why IBM/RH made this decision
>
> Simple answer: it's a commercial company that has, as first interest,
> making money. It's goal is not having happy non-paying users.
>
> > but there's no denying that it puts production Centos users in a difficult position.
>
> It just forces you to buy a service from a company that was previously
> giving it for free (as in free beer).
>
> > I hope that Rocky Linux [1], under Gregory Kurtzer (founder of the Centos project) will turn out to be a useful alternative.
> >
> > {1} https://github.com/rocky-linux/rocky
>
> So you haven't learned from this event, it seems...
>
> On 12/11/20 3:58 PM, Tobias Urdin wrote:
> > But this just reaffirms my ideas that OpenStack should be packaged and
> > distributed as an application by upstream
>
> I attempted this (ie: doing the packaging in upstream OpenStack) in
> 2014. The release of OpenStack in Jessie was built this way. However,
> nobody had interest in contributing, not even Canonical who turned away
> from the initiative (after they gave the initial idea and initially
> agreed to do so). I wont do it again unless there's strong interest and
> contribution.
>
> Also, you might know that this was how OpenStack started in the very
> beginning, where the CI was even using packages.
>
> However, the recent event about CentOS redefinition is orthogonal to
> this. This is the underlying distribution that we're talking about, not
> OpenStack that runs on top of it. I don't see how the fall of CentOS has
> a relation to OpenStack being packaged upstream.
>
> > One of the best ideas so far is on Mohammed Naser's line, which is a
> > shame that there isn't more colaboration on already, is ready-to-use
> > container images for running OpenStack services which would make the
> > layer beneath more "not important".
>
> I strongly disagree with this. If you aren't using packages, you end up
> reinventing them in a different context (ie: the one of a container),
> and rewrite all of what they do in a different way. I know I'm swimming
> against the tide, but eventually, the tide will change direction... :)
>
> Besides this, there's all sorts of important components that are
> maintained within distros that OpenStack can't work without:
> - qemu
> - openvswitch
> - rabbitmq
> - ceph
> - haproxy
> - mariadb/galera
> - you-name-it... (the list goes on, and on, and on... and I suppose you
> know this list as much as I do)
>
> Yes, you can use containers for the Python bits. But what about the
> rest? You will certainly end up using a distribution as a base for
> building (and running) the other bits, even if that's within a container.
>
> Denying that the underneath distribution is important wont drive you
> very far in such a context.
>
> Choosing carefully what distribution you're using (and contributing) is
> probably more important than everyone thought, finally... :)
>
> Cheers,
>
> Thomas Goirand (zigo)
>