Centos Stream is fine for those who were using Centos for testing or development. It's not at all suitable for production, because rolling release doesn't provide the stability that production clusters need. Switching to Centos Stream would require significant resources to be expended to setup local mirrors and then perform exhaustive testing before each upgrade. 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. 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; 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, but there's no denying that it puts production Centos users in a difficult position. 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 -----Original Message----- From: Luigi Toscano <ltoscano@redhat.com> Sent: Thursday, December 10, 2020 3:51 PM To: Thomas Wakefield <dwakefi2@gmu.edu>; openstack-discuss@lists.openstack.org Cc: Satish Patel <satish.txt@gmail.com> Subject: [EXTERNAL] Re: New Openstack Deployment questions CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. On Thursday, 10 December 2020 15:27:40 CET Satish Patel wrote:

I just built a new openstack using openstack-ansible on CentOS 8.2 last month before news broke out. I have no choice so i am going to stick with CentOS.

What is the future of RDO and EPEL repo if centOS going away. ?

Continue as before on CentOS Stream. -- Luigi E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

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)

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@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)

On 12/11/20 10:37 AM, Arnaud Morin wrote:

Hey,

Yes, debian packages are very nice, thank you zigo for all you did!

Moreover, you can also take a look at what canonical did with ubuntu cloud archives. Packages are working very well and openstack documentation is explaining quite easily how to deploy them. I dont know, but maybe it's based on what you did for debian zigo?

Cheers,

Hi, No, Canonical packages aren't the same as the ones in Debian (at least, not the core service packages). They are developed in a separate way, even though we share some of them (mainly, Ubuntu imports the dependency packages from Debian, where for many of them, I'm the package maintainer). Cheers, Thomas Goirand (zigo)