[CentOS-devel] CentOS Streams q&a

Tue Sep 24 20:10:41 UTC 2019
Alexander Bokovoy <abokovoy at redhat.com>

On ti, 24 syys 2019, David wrote:
>On 2019-09-24 1:03 p.m., Greg Bailey wrote:
>>On 9/24/19 11:24 AM, Jim Perrin wrote:
>>>Okay, now that the release is out, and everything is announced properly.
>>>I'm happy to answer questions about Stream.
>>
>>I assume that the FAQ page at https://wiki.centos.org/FAQ will grow 
>>to include some of the Q&A discussed here?
>>
>>My question originates from the (lack of) available desktops 
>>available with CentOS 8.  Would alternative desktops such as MATE 
>>(or KDE, etc.) continue to be published via the EPEL repository, or 
>>could new packages be introduced via "streams"?  How does the 
>>contribution model for streams differ from EPEL packagers?
>
>The name is just 'stream' I think, not 'streams' implying there really 
>is just one path of:
>
>CentOS stream -> CentOS release + RedHat release
I hope we'll get some 'side-streams', in a way similar to how modules'
streams used in RHEL 8, to allow such alternative versions to exist for
those who wants them. They don't need to be fully supported but at least
would provide a way to test new versions before updating CentOS Stream
primary content.

Though, I think first a bit of definitions would help here. Even in a
sentence above I had to invent new terms as there are none defined yet.

For now, my understanding is that whatever consitutes CentOS Stream is
built off CentOS 8 branches in git.centos.org. Let me take FreeIPA
example. For many years our CentOS users asked for new versions of
FreeIPA to be available in CentOS from FreeIPA upstream and we weren't
able to achieve that as we needed to go with multiple changes through
RHEL first.

RHEL 8 packages FreeIPA in a module, with two streams: idm:client and
idm:DL1, representing client-only and server-side parts of FreeIPA
packaging and dependencies. The naming of branches in CentOS is
following RHEL naming, not CentOS Stream itself (here it is a bit
confusing for uninitiated but those 'stream' parts in the branch names
are really after module streams, not CentOS Stream), so there are no separate
branches for CentOS Stream: c8-stream-DL1 and c8-stream-client are
direct counterparts of stream-idm-DL1 and stream-idm-client in RHEL 8.0.
(see https://git.centos.org/modules/idm/c/86698e5c597737f26cde6ff11536d6707dfd4802?branch=c8-stream-DL1
for context)

With CentOS Stream, technically we can create additional module streams
that correspond to additional versions of the same content. 

Suppose, I want to get FreeIPA ipa-4-8 upstream git branch (or even just
git master branch) provided with daily rebuilds. I'd imagine this would
need to go into a separate branch. Let's say there would be
c8-stream-DL1-daily and c8-stream-client-daily branches for idm module
and IPA packages involved.

Those two branches could be built and two new streams would be available
for idm module in CentOS Stream. Users then could test / use these
idm:DL1-daily and idm:client-daily streams instead of the idm:DL1 and
idm:client streams.

So far, so good. These new two streams go through some development,
bug-fixes and accumulate some content changes. They do not affect normal
idm:DL1 and idm:client module streams from RHEL even in CentOS Stream.


Eventually, we would propose those changes for integration into
c8-stream-DL1 / c8-stream-client.  Ideally, this would be as simple as
proposing a pull request in git.centos.org pagure instance. I wonder if
such flow would be acceptable -- it actually would be pretty cool if
such a pull request could be automatically relayed into whatever is
powering dist-git for RHEL 8. Of course, the other side would need to
see if those changes could get in due to whatever regulatory
requirements Red Hat has.  Certainly, this would make my integration
work for newer upstream releases easier -- given that it would also be
available to CentOS Stream users to test way before RHEL customers would
get the packages delivered, in ideal world.

It looks brighter for modules because each module stream can be fairly
isolated here. We can, for example, go extreme and pull newer krb5 build
into the idm:DL1-daily so that all shiny work that relies on new MIT
Kerberos APIs (and ABIs) would be encapsulated in the module stream for
testing purposes. After it is all tested/coordinated, we can look at
providing a pull request that updates primary krb5 build and primary idm
streams in one go and get it all delivered to CentOS Stream / RHEL.

This doesn't look so bright for non-modular packages. They don't have
ways to isolate themselves other than becoming a package in a separate
module:stream just for that purpose. Or being delivered in a completely
separate repository.

So, I guess, there are many technical questions to answer but I have few
related to what I'd see as stumbling blocks with my RHEL workflow
experience:

 - how to get pull requests back and forth between CentOS Stream and
   RHEL proper

 - how to handle these backward pull requests in RHEL workflow where
   there are certain limits on what goes into which minor release to
   keep ABI/API changes under control, etc

 - how to make these pull requests usable on both sides for packages
   which passed through debranding

 - how to handle module stream renaming for these pull requests

So far all the answers for these in Fedora-RHEL pairing were 'it is all
manual work'. We don't use modules for FreeIPA in Fedora, for example.
We do use them in RHEL. With CentOS Stream we already have modules on
both sides but they use different naming and still would require manual
work. However, it is promising -- if we could get it automated, that
will really help all of us.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland