I have been reading a lot about the new CentOS stream "revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
Could we list pros/cons about using CentOS stream in a computational Center?
Are we going to see CentOS stream in the top500 list?
Best regards,
Pablo Sanz
On 12/25/20 12:54 PM, Pablo Sanz Mercado wrote:
I have been reading a lot about the new CentOS stream "revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
If I were in your shoes ( actually I AM in the same situation except that on a much lower scale ) I'd wait 4-6 months until we see the plans for the new subscriptions that RH will announce in Q1 2021.
Could we list pros/cons about using CentOS stream in a computational Center?
Pro: will always be ahead of RHEL, with all new bugs and features
Con:will always be ahead of RHEL, with all new bugs and features
Are we going to see CentOS stream in the top500 list?
I am willing to bet a case of Estrella Damm on "Never". Those machines usually require a more stable env. As I see it (I might of course be wrong, it would not be the first time), Centos Stream seems to be more intended to developers and people looking to be on the front end of using new features and bugs.
wolfy
El vie, 25-12-2020 a las 13:25 +0200, Manuel Wolfshant escribió:
On 12/25/20 12:54 PM, Pablo Sanz Mercado wrote:
I have been reading a lot about the new CentOS stream "revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
If I were in your shoes ( actually I AM in the same situation except that on a much lower scale ) I'd wait 4-6 months until we see the plans for the new subscriptions that RH will announce in Q1 2021.
It is a good point, we can wait. The problem is when you have a lot of computers and no budget to be used in OS.
As has been reported, you can use RHEL in the front servers, and Fedora in the cluster itself. The problem is to have a real software compability. When having a lot of users, working with their own programs, you have to be sure everything is going to work. However they are going to compile the programs "with poor knowledge" in the front servers, and they will have problems when using the binaries in the Fedora systems...
Could we list pros/cons about using CentOS stream in a computational Center?
Pro: will always be ahead of RHEL, with all new bugs and features
Con:will always be ahead of RHEL, with all new bugs and features
;-)
Are we going to see CentOS stream in the top500 list?
I am willing to bet a case of Estrella Damm on "Never". Those machines usually require a more stable env. As I see it (I might of course be wrong, it would not be the first time), Centos Stream seems to be more intended to developers and people looking to be on the front end of using new features and bugs.
That is the point: developing system vs stable system.
wolfy
On 12/25/20 11:54 AM, Pablo Sanz Mercado wrote:
I have been reading a lot about the new CentOS stream "revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
Could we list pros/cons about using CentOS stream in a computational Center?
Response of the Red Hat employees will most like be "do not worry, just use it". Also, if you are educational institution, you might get no-cost licenses, once offer is prepared.
Response of the many of current "CentOS Linux" users is that:
- "CentOS Stream" (still) does not have solved issue of 3rd party kernel modules braking RHEL kernel devs decide to change kABI,
- and you have to be aware that "CentOS Stream" will have (has at this moment) only latest/one version of all packages, so downgrade will not be possible (without internal repo that saves old package versions).
- Also, be ready to potentially have daily updates of many packages while they are prepared by RHEL devs. Scope and intensity of this is not clear to anyone from outside RHEL, but every change that is done to packages prepared for next RHEL minor version will land to "CentOS Stream" at some point between RHEL minor releases (8.3 to 8.4, 8.4 to 8.5, etc), basically they can happen any day of the year and it could be never for some packages but every few days for others, no way to predict.
- Other then these technical issues, only other difference is that "CentOS Stream" will not correspond to any specific RHEL minor release, so software and hardware vendors might or might not decide to officially or unofficially support "CentOS Stream" as they did "CentOS Linux".
Notice that "CentOS Linux 7" will be supported to natural EOL in 2024, you do not have to worry about those (hopefully).
If neither of no-cost RHEL and "CentOS Stream 8" is good option for you, you should be able to rather easily switch "CentOS Linux 8" to "Springdale" RHEL clone or "Oracle Linux 8", both are readily available and no-cost options. CloudLinux project "Lenix" is expected to produce usable distro before April 2021 ("in Q1 2021"), and Rocky Linux before September 2021 ("in Q2 2021").
Are we going to see CentOS stream in the top500 list?
I doubt "CentOS/"CentOS Stream" will even keep it's today market share "CentOS Linux" has after 2024 when "CentOS Linux 7" hits EOL
Best regards,
Pablo Sanz
El vie, 25-12-2020 a las 12:32 +0100, Ljubomir Ljubojevic escribió:
On 12/25/20 11:54 AM, Pablo Sanz Mercado wrote:
I have been reading a lot about the new CentOS stream "revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
Could we list pros/cons about using CentOS stream in a computational Center?
Response of the Red Hat employees will most like be "do not worry, just use it". Also, if you are educational institution, you might get no- cost licenses, once offer is prepared.
Response of the many of current "CentOS Linux" users is that:
- "CentOS Stream" (still) does not have solved issue of 3rd party
kernel modules braking RHEL kernel devs decide to change kABI,
- and you have to be aware that "CentOS Stream" will have (has at
this moment) only latest/one version of all packages, so downgrade will not be possible (without internal repo that saves old package versions).
- Also, be ready to potentially have daily updates of many packages
while they are prepared by RHEL devs. Scope and intensity of this is not clear to anyone from outside RHEL, but every change that is done to packages prepared for next RHEL minor version will land to "CentOS Stream" at some point between RHEL minor releases (8.3 to 8.4, 8.4 to 8.5, etc), basically they can happen any day of the year and it could be never for some packages but every few days for others, no way to predict.
- Other then these technical issues, only other difference is that
"CentOS Stream" will not correspond to any specific RHEL minor release, so software and hardware vendors might or might not decide to officially or unofficially support "CentOS Stream" as they did "CentOS Linux".
Notice that "CentOS Linux 7" will be supported to natural EOL in 2024, you do not have to worry about those (hopefully).
It is true, but I think in a computational center 3 years is not enough to prepare everything. Take into account you have to compile every research program you have (hundreds) and what is going to happen with software like Lustre? It is going to be hard to assimilate.
If neither of no-cost RHEL and "CentOS Stream 8" is good option for you, you should be able to rather easily switch "CentOS Linux 8" to "Springdale" RHEL clone or "Oracle Linux 8", both are readily available and no-cost options. CloudLinux project "Lenix" is expected to produce usable distro before April 2021 ("in Q1 2021"), and Rocky Linux before September 2021 ("in Q2 2021").
Are we going to see CentOS stream in the top500 list?
I doubt "CentOS/"CentOS Stream" will even keep it's today market share "CentOS Linux" has after 2024 when "CentOS Linux 7" hits EOL
I hope you are wrong at this point, but...
Best regards,
Pablo
Best regards,
Pablo Sanz
On 12/26/20 7:07 PM, Pablo Sanz Mercado wrote:
Notice that "CentOS Linux 7" will be supported to natural EOL in 2024, you do not have to worry about those (hopefully).
It is true, but I think in a computational center 3 years is not enough to prepare everything. Take into account you have to compile every research program you have (hundreds) and what is going to happen with software like Lustre? It is going to be hard to assimilate.
I meant that if you are now using C7 then nothing changes for you, or, if you have to install something C7 is not so bad choice since you probably already used them.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 25, 2020 4:54 AM, Pablo Sanz Mercado pablo.sanz@uam.es wrote:
I have been reading a lot about the new CentOS stream"revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
Could we list pros/cons about using CentOS stream in a computational Center?
Are we going to see CentOS stream in the top500 list?
Best regards,
Pablo Sanz
To start off for a computational cluster running in-house written applications, I would have three primary/storage nodes running RHEL 8.
All of the other nodes would be diskless. I would boot Fedora (one version previous to latest) via PXE/NFS and then non-OS application/data would be on a gluster mount.
I want my focus for high availability and administration to be on just three servers. The rest of the servers should be easy to spin up/down as well as upgrade/replace as needed.
Pro of using CentOS Stream would be you get features before they are released for RHEL.
Con of using CentOS Stream is it won't get offcial support and packages will be released before getting the same level of QA of RHEL 8 or CentOS 8. The other con is CentOS Stream will not be getting major software updates/features as frequently/soon as Fedora.
It is /possible/ you may see CentOS Stream appear on the top 500. I think it is unlikely. To make it on the bottom of the list you need over 20,000 cores. With a budget that can get you that much equipment and the resulting on-going costs, paying for RHEL and getting the support probably will seem worth it.
The majority of my nodes wouldn't be running RHEL to save money. It is just Fedora would provides me the kernel and library versions I would prefer to work with on the computation nodes. I would also rather self-support the OS for those nodes.
If there is a specific application you are building the cluster for then you may want to ask the software vendor what OS/distribution they recommend using.
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
On Friday, December 25, 2020 2:02 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
How invested are they on that?
How often will a package be released on RHEL at the same exact time it is published on Stream?
We played this game in the pre-FESCo days of Fedora as well.
If the gamble works out then it is because they have been doing everything great.
For the packages the gamble does not work out on then it is proof people should have bought RHEL.
It is a win-win for RH/Stream engineers to make claims because they are gambling with other people's chips instead of their own.
CentOS engineers also said there was a firewall between CentOS and RHEL but we still got Brian "Bex" Exelbierd on the governing board. It turns out they say a lot of things and not all of them are true.
My opinion still stands, not all releases to Stream will be moved as-is into RHEL. At some point there will be a release to Stream in which the package will be updated again before RHEL is willing to release it.
I would say the chances of Stream ending up on a Top 500 cluster is about the same as Windows Insider Slow Ring builds. The methodology seems to be similar.
However, RHEL 8 is a great product. Gluster is also a great product but has a slight learning curve and benefits from Red Hat support.
If your application resource usage is mostly CPU bound with some amount of disk reads and low amount of disk writes, then a gluster may provide the required performance. Combine that with a pair of 10Gbps switches providing bonded/LACP to each of the nodes, the latency/bandwidth should be minimal.
My main point is the question of finalizing what needs to be "installed" on the cluster shouldn't matter for the majority of node.
Nether Fedora or Stream are what I would recommend for the head nodes. I would recommend making sure to get support for those.
The other nodes should be easy to swap what is booted over the network or installed via anconda kickstart automation.
If there is an application that would benefit from Stream on the nodes then put that on the nodes for that application run. If there is an application that would benefit from Fedora on the ndoes then put that on the nodes for the run of that application. If there is an application that would benefit from Debian on the nodes, then put that on during that run.
If you are making it on the bottom of the Top 500 list using something like System76 1U AMD servers with 40 cores per server (full disclosure: I personally have not used System76 servers), then you are looking at 14 cabinets full servers (if not more). What is installed on the majority of those nodes should be automated and reinstalls should be "cheap." The question of choosing what to install for the long term sounds a little odd.
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
I think the problem is that the document you are quoting is simply just out of date.
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening. Significant portions of the CentOS team are now under my org which is called the "Linux Engineering" team. We're responsible for RHEL, CentOS, Fedora, CoreOS, UBI, and several other Linux related activities at Red Hat. They're excellent engineers and I'm lucky to have them and hope they can find a fruitful career in the engineering org.
I agree you have several justifiable concerns, for example, transparency. Though even that has recently changed as the board has been posting meeting minutes. It could be better but a step in the right direction. The closer joining of the Fedora and CentOS teams (under Linux Engineering) was not in any way hidden or kept secret and there were multiple announcements about it. Your concerns are the first negative feedback I've received on that team merger. It would be helpful to take your concerns looking forward to what you want to see as opposed to looking back at a period in time in CentOS where you clearly weren't aware of what was actually going on.
-Mike
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Dec 25, 2020 at 7:16 PM Mike McGrath mmcgrath@redhat.com wrote:
On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
I think the problem is that the document you are quoting is simply just out of date.
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening. Significant portions of the CentOS team are now under my org which is called the "Linux Engineering" team. We're responsible for RHEL, CentOS, Fedora, CoreOS, UBI, and several other Linux related activities at Red Hat. They're excellent engineers and I'm lucky to have them and hope they can find a fruitful career in the engineering org.
I agree you have several justifiable concerns, for example, transparency. Though even that has recently changed as the board has been posting meeting minutes. It could be better but a step in the right direction. The closer joining of the Fedora and CentOS teams (under Linux Engineering) was not in any way hidden or kept secret and there were multiple announcements about it. Your concerns are the first negative feedback I've received on that team merger. It would be helpful to take your concerns looking forward to what you want to see as opposed to looking back at a period in time in CentOS where you clearly weren't aware of what was actually going on.
Personally speaking, I've been generally happy with how the integration of teams has worked out. However, I am unhappy with the nature of the CentOS governance. I will admit to being spoiled: I've been part of the Fedora community for almost 15 years and I've been a member of FESCo for the past six months. I'm a member of so many SIGs, Teams, and Working Groups that I've lost count. I've participated in almost every facet of the project (except for the relatively minor things that require being a Red Hat employee, like budget and engineering interfaces with RHEL engineering). With CentOS Stream underway, I would like the CentOS Project to open up *somewhat* (alluding to Karsten's openness thing).
The real annoyance to me is that CentOS Board meetings are not only secret, but the meetings are essentially unknown to the community. There is no real understanding of the functional nature and structure of the CentOS Project. There is no avenue for me to feel like I can make a difference in the Project itself. This is not a specific failing by Karsten or by you, Mike. This is a failing of the CentOS community. In the same timespan I've been actively involved in Fedora, I've also peered into the looking glass at CentOS, and CentOS has been an unmitigated disaster as a project in that timeframe. Red Hat brought much needed stability in the past six years, and I thank them profusely for that. But I think that the folks who came onboard at the time and tried to "fix" the governance underestimated how broken the project was.
Sometimes, I think this project should have failed six years ago. That it didn't is a testament to Johnny, Jim, Brian, and the others who held the project together by the loose threads it had. But it's clear that we need to do better.
So how are we going to do that? I don't know. I am willing to help with that, though.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Friday, December 25, 2020 6:15 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
I think the problem is that the document you are quoting is simply just out of date.
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening. Significant portions of the CentOS team are now under my org which is called the "Linux Engineering" team. We're responsible for RHEL, CentOS, Fedora, CoreOS, UBI, and several other Linux related activities at Red Hat. They're excellent engineers and I'm lucky to have them and hope they can find a fruitful career in the engineering org.
I agree you have several justifiable concerns, for example, transparency. Though even that has recently changed as the board has been posting meeting minutes. It could be better but a step in the right direction. The closer joining of the Fedora and CentOS teams (under Linux Engineering) was not in any way hidden or kept secret and there were multiple announcements about it. Your concerns are the first negative feedback I've received on that team merger. It would be helpful to take your concerns looking forward to what you want to see as opposed to looking back at a period in time in CentOS where you clearly weren't aware of what was actually going on.
Fool me once shame on Red Hat. Fool me twice shame on me.
I spoke up before. I tried to treat Red Hat like they were operating in good faith and tried to get things resolved behind the scenes. I was advised to wait and see. That if an issue came up effecting the CentOS community that the RHEL members would recuse themselves from the discussion. The spirit of the firewall would remain.
I was also told that my concerns would be escalated. You have now provided in writting that it was never escalated to you.
We are now being told once again to wait and see. AGAIN with the "just wait." That we shouldn't be quick to get mad. That if was wait then 95% of us should be fine. That if wait then we will see the needs of CentOS was kept in the balance. That if we wait that we won't see a difference between CentOS 8 and Stream. That if we wait we might see changes to RHEL to fit our needs but can not be discussed.
But as you just so perfectly put wrote, if we wait then it is on *US* for honoring the request to wait. It is like all objections never happened. Your own words is justification to be as *LOUD* and *PUBLIC* with objections as possible this time instead of the mistakes of the past of honoring the call to "just wait."
As to that the "things that are NOT CHANGING" is now a document that simply goes out of date? Really?? You want to go there?! Maybe tomorrow the documents claiming Red Hat is a Linux distribution provider will also just go "out of date" and Red Hat will go full blown Caldera/SCO. We get to start 2021 with Red Hat trying to sue Linux vendors and users. Come on. Leave Red Hat some degree of credability. Red Hat being a Linux distributor isn't something that goes out of date and nether are the fundmentals of CentOS.
But I am willing to accept the spirit of the document might have some wiggle room. However, having Brian "Bex" Exelbierd involved in non-public discussions to set the roadmap by gutting the CentOS 8 EoL date is not just pushing for wiggle room. He should have recused himself from the entire discussion as having a clear conflict of interest.
But you are right. It is on me for assuming things were being done in good faith. None of what I said directly to members of CentOS and Red Hat actually matters now. I was a fool for following the advise to just wait. I will NEVER make those mistakes again. I will shout from the roof tops about CentOS 8 getting Bex'd. This time my concerns will count as being real. The threat of the Bex'ing needs to end now. No more calls for waiting.
On Fri, Dec 25, 2020 at 8:05 PM redbaronbrowser < redbaronbrowser@protonmail.com> wrote:
On Friday, December 25, 2020 6:15 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel < centos-devel@centos.org> wrote:
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic < centos@plnet.rs> wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
I think the problem is that the document you are quoting is simply just out of date.
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening. Significant portions of the CentOS team are now under my org which is called the "Linux Engineering" team. We're responsible for RHEL, CentOS, Fedora, CoreOS, UBI, and several other Linux related activities at Red Hat. They're excellent engineers and I'm lucky to have them and hope they can find a fruitful career in the engineering org.
I agree you have several justifiable concerns, for example, transparency. Though even that has recently changed as the board has been posting meeting minutes. It could be better but a step in the right direction. The closer joining of the Fedora and CentOS teams (under Linux Engineering) was not in any way hidden or kept secret and there were multiple announcements about it. Your concerns are the first negative feedback I've received on that team merger. It would be helpful to take your concerns looking forward to what you want to see as opposed to looking back at a period in time in CentOS where you clearly weren't aware of what was actually going on.
Fool me once shame on Red Hat. Fool me twice shame on me.
I spoke up before. I tried to treat Red Hat like they were operating in good faith and tried to get things resolved behind the scenes. I was advised to wait and see. That if an issue came up effecting the CentOS community that the RHEL members would recuse themselves from the discussion. The spirit of the firewall would remain.
I was also told that my concerns would be escalated. You have now provided in writting that it was never escalated to you.
Just to be clear on this point. I don't have any actual authority that I'm aware of in the CentOS community. It would be highly unusual for something to get escalated to me unless it was related to my associates, budgeting, or perhaps some obscure legal matter (which to be clear hasn't happened)
We are now being told once again to wait and see. AGAIN with the "just wait." That we shouldn't be quick to get mad. That if was wait then 95% of us should be fine. That if wait then we will see the needs of CentOS was kept in the balance. That if we wait that we won't see a difference between CentOS 8 and Stream. That if we wait we might see changes to RHEL to fit our needs but can not be discussed.
But as you just so perfectly put wrote, if we wait then it is on *US* for honoring the request to wait. It is like all objections never happened. Your own words is justification to be as *LOUD* and *PUBLIC* with objections as possible this time instead of the mistakes of the past of honoring the call to "just wait."
oh, to be clear I was issuing a call to action. I'm not asking you to just wait. I'm not sure who you spoke to nor if they purposefully or accidentally ignored your concerns. It sounds like the original CentOS model wasn't working for you either.
As to that the "things that are NOT CHANGING" is now a document that simply goes out of date? Really?? You want to go there?! Maybe tomorrow the documents claiming Red Hat is a Linux distribution provider will also just go "out of date" and Red Hat will go full blown Caldera/SCO. We get to start 2021 with Red Hat trying to sue Linux vendors and users. Come on. Leave Red Hat some degree of credability. Red Hat being a Linux distributor isn't something that goes out of date and nether are the fundmentals of CentOS.
I've got years of experience in the community prior to turning "corporate". If there's one thing I know, it's that docs get out of date. You're attributing maliciousness to some firewall thing that was written who knows how many years ago and everyone I've talked to believed that firewall was to prevent RHEL employees from helping CentOS Community people from building CentOS. Asking one team at Red Hat not to interact with another team at Red Hat is really weird, the same would go for any two open source communities...
But I am willing to accept the spirit of the document might have some wiggle room. However, having Brian "Bex" Exelbierd involved in non-public discussions to set the roadmap by gutting the CentOS 8 EoL date is not just pushing for wiggle room. He should have recused himself from the entire discussion as having a clear conflict of interest.
Bex is on the board though. He's an actual member of the board who has the special role of representing Red Hat. We (Red Hat) ask him to take matters that are important to us to the board. In the case of the meeting in question, he brought Chris Wright with him. That seems to be functioning exactly as intended.
But you are right. It is on me for assuming things were being done in good faith. None of what I said directly to members of CentOS and Red Hat actually matters now. I was a fool for following the advise to just wait. I will NEVER make those mistakes again. I will shout from the roof tops about CentOS 8 getting Bex'd. This time my concerns will count as being real. The threat of the Bex'ing needs to end now. No more calls for waiting.
This last paragraph is toxic and unprofessional. Bex did his job as we asked him to and he performed the exact role on the CentOS Board as the liaison role was designed to do. AFAIK this doc is still up to date though I'd have to defer to the board to know for sure:
https://www.centos.org/about/governance/board-responsibilities/#red-hat-liai...
Have a good evening.
-Mike
On Friday, December 25, 2020 9:18 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, Dec 25, 2020 at 8:05 PM redbaronbrowser redbaronbrowser@protonmail.com wrote:
On Friday, December 25, 2020 6:15 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/25/20 9:02 PM, Gordon Messmer wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
> Con of using CentOS Stream is it .. packages will be released before > getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
And Red Hat executives said nothing will change for CentOS Linux and here we are (YMMV) ...
Actually, if you read carefully statements made by Karsten Wade and Johnny Hughes, it appears they still believe technically nothing has changed for the majority of users.
I would be willing to accept that Stream has the potential to fit the needs of CentOS 8 users. That isn't the change that bothers me.
What bothers me is the level of disrespect for foundational promises made to the community.
They have been pushing that "a lot of people" were involved in this decision. That is not the same as being *public*. That is not the same as being *transparent*.
What exactly was said to decide Dec 31, 2021 is the date instead of June 30, 2024 to be in line with CentOS 7?
What was Brian "Bex" Exelbierd from the RHEL team doing there? What did he say?
It seems we will never know for sure. I can *imagine* what was said and I am getting really close to posting my *imaginary* transcript but that also is not a good replacement for the real transcript.
It has been reiterated that this was a hard decision for everyone involved. That might be true. But how hard is it to keep the promises made about how CentOS Governance would work once joined with Red Hat? How hard is it to honor the claim there would be a firewall between CentOS and RHEL?
I think the problem is that the document you are quoting is simply just out of date.
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening. Significant portions of the CentOS team are now under my org which is called the "Linux Engineering" team. We're responsible for RHEL, CentOS, Fedora, CoreOS, UBI, and several other Linux related activities at Red Hat. They're excellent engineers and I'm lucky to have them and hope they can find a fruitful career in the engineering org.
I agree you have several justifiable concerns, for example, transparency. Though even that has recently changed as the board has been posting meeting minutes. It could be better but a step in the right direction. The closer joining of the Fedora and CentOS teams (under Linux Engineering) was not in any way hidden or kept secret and there were multiple announcements about it. Your concerns are the first negative feedback I've received on that team merger. It would be helpful to take your concerns looking forward to what you want to see as opposed to looking back at a period in time in CentOS where you clearly weren't aware of what was actually going on.
Fool me once shame on Red Hat. Fool me twice shame on me.
I spoke up before. I tried to treat Red Hat like they were operating in good faith and tried to get things resolved behind the scenes. I was advised to wait and see. That if an issue came up effecting the CentOS community that the RHEL members would recuse themselves from the discussion. The spirit of the firewall would remain.
I was also told that my concerns would be escalated. You have now provided in writting that it was never escalated to you.
Just to be clear on this point. I don't have any actual authority that I'm aware of in the CentOS community. It would be highly unusual for something to get escalated to me unless it was related to my associates, budgeting, or perhaps some obscure legal matter (which to be clear hasn't happened)
We are now being told once again to wait and see. AGAIN with the "just wait." That we shouldn't be quick to get mad. That if was wait then 95% of us should be fine. That if wait then we will see the needs of CentOS was kept in the balance. That if we wait that we won't see a difference between CentOS 8 and Stream. That if we wait we might see changes to RHEL to fit our needs but can not be discussed.
But as you just so perfectly put wrote, if we wait then it is on *US* for honoring the request to wait. It is like all objections never happened. Your own words is justification to be as *LOUD* and *PUBLIC* with objections as possible this time instead of the mistakes of the past of honoring the call to "just wait."
oh, to be clear I was issuing a call to action. I'm not asking you to just wait. I'm not sure who you spoke to nor if they purposefully or accidentally ignored your concerns. It sounds like the original CentOS model wasn't working for you either.
Other members of Red Hat have been telling us to wait and see. I'll gather together a list of names and quotes if you require them.
As to that the "things that are NOT CHANGING" is now a document that simply goes out of date? Really?? You want to go there?! Maybe tomorrow the documents claiming Red Hat is a Linux distribution provider will also just go "out of date" and Red Hat will go full blown Caldera/SCO. We get to start 2021 with Red Hat trying to sue Linux vendors and users. Come on. Leave Red Hat some degree of credability. Red Hat being a Linux distributor isn't something that goes out of date and nether are the fundmentals of CentOS.
I've got years of experience in the community prior to turning "corporate". If there's one thing I know, it's that docs get out of date.
That is good to know. I will put together a list of Red Hat and CentOS documents that can no longer be trusted by the community because Red Hat has refused to reaffirm/update them.
Red Hat employees seem to like to frequently reference out of date documents in a misleading way to imply Red Hat is doing things they aren't.
This new information will be very helpful moving forward to set expectations.
You're attributing maliciousness to some firewall thing that was written who knows how many years ago and everyone I've talked to believed that firewall was to prevent RHEL employees from helping CentOS Community people from building CentOS. Asking one team at Red Hat not to interact with another team at Red Hat is really weird, the same would go for any two open source communities...
But I am willing to accept the spirit of the document might have some wiggle room. However, having Brian "Bex" Exelbierd involved in non-public discussions to set the roadmap by gutting the CentOS 8 EoL date is not just pushing for wiggle room. He should have recused himself from the entire discussion as having a clear conflict of interest.
Bex is on the board though. He's an actual member of the board who has the special role of representing Red Hat. We (Red Hat) ask him to take matters that are important to us to the board. In the case of the meeting in question, he brought Chris Wright with him. That seems to be functioning exactly as intended.
Exactly. It went as Red Hat and the RHEL team intended. How exactly it went as intended is provided in an open/public way by refusing to provide a transcript?
Was there a "balancing the needs of CentOS" in the discussions of the meeting or statements that indicate a conflict of interest?
But you are right. It is on me for assuming things were being done in good faith. None of what I said directly to members of CentOS and Red Hat actually matters now. I was a fool for following the advise to just wait. I will NEVER make those mistakes again. I will shout from the roof tops about CentOS 8 getting Bex'd. This time my concerns will count as being real. The threat of the Bex'ing needs to end now. No more calls for waiting.
This last paragraph is toxic and unprofessional. Bex did his job as we asked him to and he performed the exact role on the CentOS Board as the liaison role was designed to do. AFAIK this doc is still up to date though I'd have to defer to the board to know for sure:
https://www.centos.org/about/governance/board-responsibilities/#red-hat-liai...
I'm sorry, I was overly vague and I think you misread what I wrote.
Being Bex'd does not mean he did not do his job. Rather it is an assertion that he *did* do the job Red Hat intended him to do which included a conflict of interest. It is also an assertion that what exactly his job at that meeting was is not open or transparent because we have no transcript of the meeting. As far as I know, both of those concerns are still valid.
Back to the question of what would work best for an computation cluster, that would be something were uptime might be important. It would be nice to leave long computation applications running without rebooting for kernel security updates.
You had previous brought up that Red Hat wants robust SIGs for Stream (RHEL Insider Slow Ring). Were you serious about that?
I have wanted for a while now to purpose a SIG to improve the infrastructure of pushing out live kpatch'ing of the kernel. The reason I have never bothered is (as I brough up before), CentOS doesn't have documented kernel patches. It has a monolithic tar-balls which effectively sabotages any community effort to kpatch on a patch by patch basis.
If Red Hat wants robust SIGs such as a kpatch SIG, are they willing to close the "openness gaps" they created such as how patches are not presented in the kernel SRPM? Or Karsten Wade just using the term because he thinks it is what the community wants to hear? I have to be honest, it was really hard to stomach Wade's blog post with the CentOS kernel SRPM in the state that it currently is in.
On 12/26/20 1:15 AM, Mike McGrath wrote:
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening.
Even before CentOS was bought by Red Hat, I have seen people who wanted to join building efforts (mostly?) turned away. CentOS devs were and stayed exclusive club doing magic behind armored doors. Various reasons were given, keeping security high, preventing other cloning projects from getting better, etc. I did not care enough to speak up, especially since it would not have maid difference.
That is the reason CloudLinux promised foundation that will keep complete procedure and ALL tools to clone RHEL accessible, anyone will be able to recreate their effort (good luck with that unintended result you created, your shot foot must start to hurt *big time*)
Then CentOS Board decided to sell CentOS to Red Hat, same as now there was no discussion, no debate, community was not asked at all. Since it was said CentOS Linux will not be killed, and people working hard got their financial reward, I accepted they did not ask anyone and moved on. And accepted that any wish, complaint or demand of the community that was not in the interest of CentOS Board would be simply dismissed, so why bother raising any when I still got what interested me, free RHEL clone?
I believe that same sentiment was on minds of majority of CentOS users, as long as it serves our interests we would allow them to do what ever they want. I never heard of Springdale and I did not like Oracle as a company, so CentOS was the only free RHEL clone in my mind.
So if you are truly asking why no one objected to what CentOS Board decided without asking anyone in the community, it was pointlessness of the effort.
This time around my interest WAS violated, but considering the futility of the opposition, I will just find me another RHEL clone to use. I am staying in CentOS community for another 4 years because I have several CentOS 7 servers, and I might even install 1 more in next few days, to replace mail CentOS 6 server. 4 years will be enough for it.
The only reason I am replying on CentOS mailing lists is to keep you Red Hat employees from claiming victory and making unfounded conclussions since all opposition decided ti is pointless in arguing with you, you will not prolong "CentOS Linux 8" life to 2029. I can be stubborn in that regard when someone tries to play me for a fool (like with "outdated document/promise" crap).
Le 26/12/2020 à 13:08, Ljubomir Ljubojevic a écrit :
On 12/26/20 1:15 AM, Mike McGrath wrote:
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening.
Even before CentOS was bought by Red Hat, I have seen people who wanted to join building efforts (mostly?) turned away. CentOS devs were and stayed exclusive club doing magic behind armored doors. Various reasons were given, keeping security high, preventing other cloning projects from getting better, etc. I did not care enough to speak up, especially since it would not have maid difference.
That is the reason CloudLinux promised foundation that will keep complete procedure and ALL tools to clone RHEL accessible, anyone will be able to recreate their effort (good luck with that unintended result you created, your shot foot must start to hurt *big time*)
Then CentOS Board decided to sell CentOS to Red Hat, same as now there was no discussion, no debate, community was not asked at all. Since it was said CentOS Linux will not be killed, and people working hard got their financial reward, I accepted they did not ask anyone and moved on. And accepted that any wish, complaint or demand of the community that was not in the interest of CentOS Board would be simply dismissed, so why bother raising any when I still got what interested me, free RHEL clone?
I believe that same sentiment was on minds of majority of CentOS users, as long as it serves our interests we would allow them to do what ever they want. I never heard of Springdale and I did not like Oracle as a company, so CentOS was the only free RHEL clone in my mind.
So if you are truly asking why no one objected to what CentOS Board decided without asking anyone in the community, it was pointlessness of the effort.
This time around my interest WAS violated, but considering the futility of the opposition, I will just find me another RHEL clone to use. I am staying in CentOS community for another 4 years because I have several CentOS 7 servers, and I might even install 1 more in next few days, to replace mail CentOS 6 server. 4 years will be enough for it.
The only reason I am replying on CentOS mailing lists is to keep you Red Hat employees from claiming victory and making unfounded conclussions since all opposition decided ti is pointless in arguing with you, you will not prolong "CentOS Linux 8" life to 2029. I can be stubborn in that regard when someone tries to play me for a fool (like with "outdated document/promise" crap).
I totally agree with all is written above and thought as I read Mike's affirmations, I couldn't say it better.
Jean-Marc
On Sat, Dec 26, 2020 at 9:50 AM Jean-Marc Liger < jean-marc.liger@parisdescartes.fr> wrote:
Le 26/12/2020 à 13:08, Ljubomir Ljubojevic a écrit :
On 12/26/20 1:15 AM, Mike McGrath wrote:
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening.
Even before CentOS was bought by Red Hat, I have seen people who wanted to join building efforts (mostly?) turned away. CentOS devs were and stayed exclusive club doing magic behind armored doors. Various reasons were given, keeping security high, preventing other cloning projects from getting better, etc. I did not care enough to speak up, especially since it would not have maid difference.
That is the reason CloudLinux promised foundation that will keep complete procedure and ALL tools to clone RHEL accessible, anyone will be able to recreate their effort (good luck with that unintended result you created, your shot foot must start to hurt *big time*)
Then CentOS Board decided to sell CentOS to Red Hat, same as now there was no discussion, no debate, community was not asked at all. Since it was said CentOS Linux will not be killed, and people working hard got their financial reward, I accepted they did not ask anyone and moved on. And accepted that any wish, complaint or demand of the community that was not in the interest of CentOS Board would be simply dismissed, so why bother raising any when I still got what interested me, free RHEL clone?
I believe that same sentiment was on minds of majority of CentOS users, as long as it serves our interests we would allow them to do what ever they want. I never heard of Springdale and I did not like Oracle as a company, so CentOS was the only free RHEL clone in my mind.
So if you are truly asking why no one objected to what CentOS Board decided without asking anyone in the community, it was pointlessness of the effort.
This time around my interest WAS violated, but considering the futility of the opposition, I will just find me another RHEL clone to use. I am staying in CentOS community for another 4 years because I have several CentOS 7 servers, and I might even install 1 more in next few days, to replace mail CentOS 6 server. 4 years will be enough for it.
The only reason I am replying on CentOS mailing lists is to keep you Red Hat employees from claiming victory and making unfounded conclussions since all opposition decided ti is pointless in arguing with you, you will not prolong "CentOS Linux 8" life to 2029. I can be stubborn in that regard when someone tries to play me for a fool (like with "outdated document/promise" crap).
I totally agree with all is written above and thought as I read Mike's affirmations, I couldn't say it better.
Jean-Marc
It sounds like the existing CentOS community wasn't working for anyone. Let's make sure to do better going forward and setup something that will function properly for those involved.
-Mike
On Saturday, December 26, 2020 10:51 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Sat, Dec 26, 2020 at 9:50 AM Jean-Marc Liger jean-marc.liger@parisdescartes.fr wrote:
Le 26/12/2020 à 13:08, Ljubomir Ljubojevic a écrit :
On 12/26/20 1:15 AM, Mike McGrath wrote:
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening.
Even before CentOS was bought by Red Hat, I have seen people who wanted to join building efforts (mostly?) turned away. CentOS devs were and stayed exclusive club doing magic behind armored doors. Various reasons were given, keeping security high, preventing other cloning projects from getting better, etc. I did not care enough to speak up, especially since it would not have maid difference.
That is the reason CloudLinux promised foundation that will keep complete procedure and ALL tools to clone RHEL accessible, anyone will be able to recreate their effort (good luck with that unintended result you created, your shot foot must start to hurt *big time*)
Then CentOS Board decided to sell CentOS to Red Hat, same as now there was no discussion, no debate, community was not asked at all. Since it was said CentOS Linux will not be killed, and people working hard got their financial reward, I accepted they did not ask anyone and moved on. And accepted that any wish, complaint or demand of the community that was not in the interest of CentOS Board would be simply dismissed, so why bother raising any when I still got what interested me, free RHEL clone?
I believe that same sentiment was on minds of majority of CentOS users, as long as it serves our interests we would allow them to do what ever they want. I never heard of Springdale and I did not like Oracle as a company, so CentOS was the only free RHEL clone in my mind.
So if you are truly asking why no one objected to what CentOS Board decided without asking anyone in the community, it was pointlessness of the effort.
This time around my interest WAS violated, but considering the futility of the opposition, I will just find me another RHEL clone to use. I am staying in CentOS community for another 4 years because I have several CentOS 7 servers, and I might even install 1 more in next few days, to replace mail CentOS 6 server. 4 years will be enough for it.
The only reason I am replying on CentOS mailing lists is to keep you Red Hat employees from claiming victory and making unfounded conclussions since all opposition decided ti is pointless in arguing with you, you will not prolong "CentOS Linux 8" life to 2029. I can be stubborn in that regard when someone tries to play me for a fool (like with "outdated document/promise" crap).
I totally agree with all is written above and thought as I read Mike's affirmations, I couldn't say it better.
Jean-Marc
It sounds like the existing CentOS community wasn't working for anyone. Let's make sure to do better going forward and setup something that will function properly for those involved.
-Mike
You keep reiterating this. The CentOS community was never perfect but it scratch the itch just enough to make it not worth rocking the boat. Implying the old method wasn't perfectly liked so everyone should be happy it is being thrown out with 1 year of notice is a little frustrating to hear. There is something really off about how you are rationalizing this.
As to the "let's make sure," *who* exaclty is the members of this "let's?" How do *I* make sure the openness gap is closed for the kernel SRPM going forward? How do *I* make board meeting transcripts appear?
It seems Red Hat has made sure the ball is in their court going forward and thumbed their nose at the community with "expired" documents.
On Saturday, December 26, 2020 6:08 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
On 12/26/20 1:15 AM, Mike McGrath wrote:
If you truly wanted to keep that firewall in place. You, or someone, should have complained two years ago when the CentOS infrastructure team formally joined the RHEL team as "CPE". There were no objections to that and it was largely seen as a positive move by everyone I've talked to. If that was something so important to you, I think it's on you to pay attention and raise those concerns when they were happening.
Even before CentOS was bought by Red Hat, I have seen people who wanted to join building efforts (mostly?) turned away. CentOS devs were and stayed exclusive club doing magic behind armored doors. Various reasons were given, keeping security high, preventing other cloning projects from getting better, etc. I did not care enough to speak up, especially since it would not have maid difference.
That is the reason CloudLinux promised foundation that will keep complete procedure and ALL tools to clone RHEL accessible, anyone will be able to recreate their effort (good luck with that unintended result you created, your shot foot must start to hurt big time)
Then CentOS Board decided to sell CentOS to Red Hat, same as now there was no discussion, no debate, community was not asked at all. Since it was said CentOS Linux will not be killed, and people working hard got their financial reward, I accepted they did not ask anyone and moved on. And accepted that any wish, complaint or demand of the community that was not in the interest of CentOS Board would be simply dismissed, so why bother raising any when I still got what interested me, free RHEL clone?
I believe that same sentiment was on minds of majority of CentOS users, as long as it serves our interests we would allow them to do what ever they want. I never heard of Springdale and I did not like Oracle as a company, so CentOS was the only free RHEL clone in my mind.
So if you are truly asking why no one objected to what CentOS Board decided without asking anyone in the community, it was pointlessness of the effort.
This time around my interest WAS violated, but considering the futility of the opposition, I will just find me another RHEL clone to use. I am staying in CentOS community for another 4 years because I have several CentOS 7 servers, and I might even install 1 more in next few days, to replace mail CentOS 6 server. 4 years will be enough for it.
The only reason I am replying on CentOS mailing lists is to keep you Red Hat employees from claiming victory and making unfounded conclussions since all opposition decided ti is pointless in arguing with you, you will not prolong "CentOS Linux 8" life to 2029. I can be stubborn in that regard when someone tries to play me for a fool (like with "outdated document/promise" crap).
Thank you for writing this. It was much better stated that I could have accomplished.
I agree the 3.5 years remaining on CentOS 7 still enough potential to work with. If we still had 3.5 years remaining on CentOS 8 then accepting this change would be much easier. The infrastructure for being a CentOS 7 and 8 downstream is already in place and will remain for CentOS 7. So that CentOS 8 needs to end in 1 year seems arbitary and self-serving when combined with the lack of any board meeting transcript.
Mike McGrath seems to be asking us to just look forward and ignore what has taken place. He wants to to know what goals we have. The types of goals I have require knowing what exactly this change means. I can't look forward by ignoring what the change is. I want to work on addressing kernel regressions and kpatch.
Previously it was stated the need for the individual patches was for the upstream provider. Since Fedora is an upstream, we got them. Since CentOS is a downstream, we didn't.
But with this change it is stated CentOS is going from being the downstream to being the upstream. Yet, the Stream SRPM kernel still doesn't have individual patches. So, we are getting the responsiblity of being the upstream without the respect and tools that should come with it.
Wade's platitude Red Hat now cares about the "openness gap" also is not helpful in being able to look forward.
Now we have Mike McGrath's revelation that fundamentals silently go out of date. That throws everything out the window. We don't know if CentOS 7's EoL date is set in stone. Maybe at the end of 2021 we will discover the document expired and the real EOL is in the middle or end of 2022.
What we are being told is Red Hat was never involved in a conspiracy against the community or being malicious. Instead, we are being told something far worse, that Red Hat is incompetent when it comes to being open and transparent with the community. That internally to Red Hat key concepts went out of date and they lacked the skills to tell anyone when they did. If that is the foundation we are building on now, I don't see any method to go forward with community goals.
On Fri, Dec 25, 2020 at 3:02 PM Gordon Messmer gordon.messmer@gmail.com wrote:
On 12/25/20 5:24 AM, redbaronbrowser via CentOS-devel wrote:
Con of using CentOS Stream is it .. packages will be released before getting the same level of QA of RHEL 8 or CentOS 8.
Several Red Hat and CentOS engineers have said that each CentOS Stream package will have passed QA before they are published.
That's not necessarily a well-defined phrase. I've seen extensive hardware compatibility tests fail with a "tested" kernel because the particular hardware had unannounced hardware changes, and the leading edge kernels were all compatible, but the kernel that passed QU didn't run on any machines with the new hardware. The kernel team had been compiling kernels from their laptops with source code never checked in, never merging their code with each other's changes, and each handing them over directly to QA, a certain amount of screaming occurred when I noticed this.
RHEL and CentOS have been much, much better than this. The visibility of the codebase is one of the reasons I like it.
El vie, 25-12-2020 a las 13:24 +0000, redbaronbrowser via CentOS-devel escribió:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 25, 2020 4:54 AM, Pablo Sanz Mercado < pablo.sanz@uam.es> wrote:
I have been reading a lot about the new CentOS stream"revolution", but now I am trying to understand the dilemma most of "regular" sysadmin have:
What should I do?
As you know there are a lot of computational centers working with CentOS. Sometimes because it is the best OS sysadmin knows, sometimes because of a low budget problem.
Now we have this important change, so we have to decide. We have to choose the OS we are going to install in our servers, moreover we have to decide as quickly as we can, because as you know changes should be done as calm as posible.
Could we list pros/cons about using CentOS stream in a computational Center?
Are we going to see CentOS stream in the top500 list?
Best regards,
Pablo Sanz
To start off for a computational cluster running in-house written applications, I would have three primary/storage nodes running RHEL 8.
All of the other nodes would be diskless. I would boot Fedora (one version previous to latest) via PXE/NFS and then non-OS application/data would be on a gluster mount.
I want my focus for high availability and administration to be on just three servers. The rest of the servers should be easy to spin up/down as well as upgrade/replace as needed.
Pro of using CentOS Stream would be you get features before they are released for RHEL.
Con of using CentOS Stream is it won't get offcial support and packages will be released before getting the same level of QA of RHEL 8 or CentOS 8. The other con is CentOS Stream will not be getting major software updates/features as frequently/soon as Fedora.
It is /possible/ you may see CentOS Stream appear on the top 500. I think it is unlikely. To make it on the bottom of the list you need over 20,000 cores. With a budget that can get you that much equipment and the resulting on-going costs, paying for RHEL and getting the support probably will seem worth it.
The majority of my nodes wouldn't be running RHEL to save money. It is just Fedora would provides me the kernel and library versions I would prefer to work with on the computation nodes. I would also rather self-support the OS for those nodes.
It is a good idea in order to work with comercial software but, how are you sure your users will obtain binaries that work correctly in the Fedora servers when compiling in the RHEL servers?
If there is a specific application you are building the cluster for then you may want to ask the software vendor what OS/distribution they recommend using.
This is another key problem. As I have said in other message, we have to wait for software as Lustre, OFED, etc.
Best regards,
Pablo
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Sat, Dec 26, 2020 at 1:18 PM Pablo Sanz Mercado pablo.sanz@uam.es wrote:
It is a good idea in order to work with comercial software but,how are you sure your users will obtain binaries that work correctly in the Fedora servers when compiling in the RHEL servers?
Binaries? Heck, python modules and init scripts!
-
Gordon Messmer -
Jean-Marc Liger -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Mike McGrath -
Neal Gompa -
Nico Kadel-Garcia -
Pablo Sanz Mercado -
redbaronbrowser