[CentOS-devel] What should I do in my cluster? CentOS streams dilemma.

On Friday, December 25, 2020 9:18 PM, Mike McGrath <mmcgrath at redhat.com> wrote:

> On Fri, Dec 25, 2020 at 8:05 PM redbaronbrowser <redbaronbrowser at protonmail.com> wrote:
>
>> On Friday, December 25, 2020 6:15 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
>>
>>> On Fri, Dec 25, 2020 at 5:27 PM redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote:
>>>
>>>> On Friday, December 25, 2020 5:05 PM, Ljubomir Ljubojevic <centos at 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-liaison-responsibilities

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201226/0d9c7e73/attachment.html>