Rohit,
Agreed. on the el8 rename for the repos. I'd recommend keeping a
symlink back to centos just for folks running automated scripts and such
downstream. Make sure the rsync daemon still works for both, too.
Do you know how difficult it would be to change the CI/CD build
processes to point to point to either multiple OSes or change to another
OS for testing? E.g. Don't actually switch off of CentOS 8 quite yet,
but be able to test alternatives before the end of the year.
Thanks,
-Nathan McGarvey
On 6/28/21 6:02 AM, Rohit Yadav wrote:
> Great thanks all for the discussion, so what we mostly agree on are:
>
> * CentOS8, Rocky Linux 8 and other initiatives may all be binary
> compatible
> * We can host all el8 repos which these distros may use
> * The community may help validate the CloudStack el8 pkgs among one or
> more clear winner with time
>
> As an immediate action, let's us publish all "centos8" or "rocky8" package
> repos under generic "el8" repos? For example,
> http://download.cloudstack.org/testing/nightly/latest/ we can add symlink or
> rename dirs as "el8", "el7".
>
>
> Regards.
>
> ________________________________
> From: n...@li.nux.ro <n...@li.nux.ro>
> Sent: Thursday, June 24, 2021 21:12
> To: d...@cloudstack.apache.org <d...@cloudstack.apache.org>
> Cc: Nathan McGarvey <nathanmcgar...@gmail.com>
> Subject: Re: [DISCUSS] Rocky 8.4 and CloudStack
>
> That's a very good suggestion, I'm sure we can sort out something.
>
> Regards,
> Lucian
>
>
>
>
> On 2021-06-24 14:40, Nathan McGarvey wrote:
>> Nux,
>> Also agree regarding EL8.
>>
>> I wonder if it is possible to build on a RHEL "development" license
>> where builds and smoke tests and such can be done without licensing
>> cost.
>> (https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux,
>> https://developers.redhat.com/terms-and-conditions)
>>
>> I'm not a lawyer and the terms seem murky as to how an Open-Source
>> project like CloudStack would interact with those terms, even in a
>> non-production sense. Do any other ASF projects use RHEL for build/test
>> servers or anything like that?
>>
>>
>> Thanks,
>> -Nathan McGarvey
>>
>>
>>
>> On 6/24/21 8:17 AM, Sven Vogel wrote:
>>> @nux
>>>
>>> „Might be then worth going for supporting "EL8" and by that include
>>> any
>>> of Rocky, Alma, OtherClone etc.“
>>>
>>> Agree
>>>
>>> __
>>>
>>> Sven Vogel
>>> Senior Manager Research and Development - Cloud and Infrastructure
>>>
>>> EWERK DIGITAL GmbH
>>> Brühl 24, D-04109 Leipzig
>>> P +49 341 42649 - 99
>>> F +49 341 42649 - 98
>>> s.vo...@ewerk.com
>>> www.ewerk.com<http://www.ewerk.com>
>>>
>>> Geschäftsführer:
>>> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
>>> Registergericht: Leipzig HRB 9065
>>>
>>> Support:
>>> +49 341 42649 555
>>>
>>> Zertifiziert nach:
>>> ISO/IEC 27001:2013
>>> DIN EN ISO 9001:2015
>>> DIN ISO/IEC 20000-1:2018
>>>
>>> ISAE 3402 Typ II Assessed
>>>
>>> EWERK-Blog<https://blog.ewerk.com/> |
>>> LinkedIn<https://www.linkedin.com/company/ewerk-group> |
>>> Xing<https://www.xing.com/company/ewerk> |
>>> Twitter<https://twitter.com/EWERK_Group> |
>>> Facebook<https://de-de.facebook.com/EWERK.Group/>
>>>
>>>
>>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>>
>>> Disclaimer Privacy:
>>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>>> ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht
>>> der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>>> informieren Sie in diesem Fall unverzüglich den Absender und löschen
>>> Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>>> System. Vielen Dank.
>>>
>>> The contents of this e-mail (including any attachments) are
>>> confidential and may be legally privileged. If you are not the
>>> intended recipient of this e-mail, any disclosure, copying,
>>> distribution or use of its contents is strictly prohibited, and you
>>> should please notify the sender immediately and then delete it
>>> (including any attachments) from your system. Thank you.
>>>
>>> ________________________________
>>> Von: n...@li.nux.ro <n...@li.nux.ro>
>>> Gesendet: Thursday, June 24, 2021 2:57:24 PM
>>> An: d...@cloudstack.apache.org <d...@cloudstack.apache.org>
>>> Betreff: Re: [DISCUSS] Rocky 8.4 and CloudStack
>>>
>>> Point taken. Good find with gdm, wonder if there are others.
>>> I'm hoping this kind of problems disappear in time as the machine gets
>>> "oiled" better.
>>>
>>> What I wanted to underline is that the situation is sort of like this:
>>> Updates -> QA -> Stream -> RHEL
>>>
>>> Might be then worth going for supporting "EL8" and by that include any
>>> of Rocky, Alma, OtherClone etc.
>>>
>>>
>>>
>>> On 2021-06-23 19:03, Nathan McGarvey wrote:
>>>> Nux,
>>>> Overall, I agree that it should be possible to use any other
>>>> clone
>>>> as they should be binary compatible.
>>>>
>>>> I don't quite understand your "pass through QA" and "basically
>>>> RHEL
>>>> packages" comment. There are already instances of breaking changes in
>>>> CentOS 8 Stream that didn't make it into RHEL or CentOS non-stream.
>>>> CentOS Stream is the only one where you *don't* know exactly what you
>>>> are getting since it is no longer downstream of RHEL:
>>>>
>>>>
>>>> Just one example:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1911827
>>>>
>>>>
>>>> RHEL 8 versions published (at least that I could find on their errata
>>>> pages)
>>>> gdm-3.28.3-34.el8.x86_64.rpm <-- not broken
>>>> gdm-3.28.3-39.el8.x86_64.rpm <-- not broken
>>>>
>>>>
>>>>
>>>> CentOS 8 (not stream) versions line up with RHEL as expected:
>>>> gdm-3.28.3-34.el8.src.rpm 2020-09-17 17:27 <-- not broken
>>>> gdm-3.28.3-39.el8.src.rpm 2021-01-28 22:09 <-- not broken
>>>>
>>>>
>>>>
>>>> CentOS 8 Stream versions (hard to track down since all mirrors wipe
>>>> previous versions now, but this is what I gathered):
>>>>
>>>> gdm-3.28.3-34.el8.x86_64.rpm 18-Sep-2020 00:27 <-- not broken
>>>> gdm-3.28.3-35.el8.x86_64.rpm 02-Dec-2020 23:33 <-- breaking change
>>>> gdm-3.28.3-37.el8.x86_64.rpm 21-Jan-2021 22:55 <-- broken still
>>>> gdm-3.28.3-39.el8.x86_64.rpm 29-Jan-2021 05:09 <-- fixed (via a
>>>> reverted change)
>>>>
>>>>
>>>> Even in this single example, there was a 2-month period where
>>>> CentOS
>>>> 8 Stream had a regression and both RHEL and CentOS did not and they
>>>> skipped the broken versions entirely.
>>>>
>>>>
>>>> The lag is bad for feature updates and version updates, but really
>>>> good for stability and knowing what you're getting since you are
>>>> literally building from the same source and won't have instances of
>>>> reverted commits like the one above.
>>>>
>>>>
>>>> Thanks,
>>>> -Nathan McGarvey
>>>>
>>>>
>>>> On 6/23/21 8:13 AM, n...@li.nux.ro wrote:
>>>>> Nathan,
>>>>>
>>>>> So with Stream you'll be getting basically RHEL packages, after they
>>>>> pass through QA and before it lands in actual RHEL.
>>>>> In fact, it's only with CentOS that you know exactly what you are
>>>>> getting. The clones will undoubtedly lag behind at various times,
>>>>> just
>>>>> like old CentOS did.
>>>>>
>>>>> However, this needn't be a problem, if all works as planned, you
>>>>> should
>>>>> be able to use RockyLinux or any other clone's packages on CentOS
>>>>> Stream, since they should be binary compatible.
>>>>>
>>>>>
>>>>>
>>>>> On 2021-06-22 18:50, Nathan McGarvey wrote:
>>>>>> CentOS Stream could be fine or a disaster, and it is hard to
>>>>>> tell:
>>>>>> "a
>>>>>> rolling preview of future RHEL kernels and features." as the RedHat
>>>>>> CTO
>>>>>> said seems to imply cloudstack might run into a lot more issues due
>>>>>> to
>>>>>> the squishy nature of kernel releases, kvm/libvirt, etc. I don't
>>>>>> think
>>>>>> it will be unusable, but it will be hard to say what is supported.
>>>>>> (E.g.
>>>>>> what version is "Centos 8 Stream"? Stuff can change out from under
>>>>>> you
>>>>>> pretty quickly in that paradigm. Even rolling distros like Debian
>>>>>> have
>>>>>> point releases.
>>>
>
