[scl.org] Installing SCL packages on RHEL

[Nick Coghlan]

On Sat, Sep 17, 2016 at 12:26 AM, Honza Horak <hhorak at redhat.com> wrote:
> On 09/16/2016 04:11 AM, Noah Kantrowitz wrote:
>> The next thing I thought to try is to use the SCLo/CentOS repositories
>> directly for cloud users as they probably don't care too much about support
>> or they would have set up a subscription. I can't figure out a stable way to
>> do that though. From https://github.com/sclorg/centos-release-scl, I can do
>> `yum-config-manager
>> --add-repo=https://copr.fedoraproject.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo`
>> but this only activates the sclo/ repo, not rh/ so I can't install the
>> recompiles of the RHSCL packages (i.e. most of them).
>
> The problem I have with this particular solution is that SCLo packages from
> CentOS were never meant to be run on RHEL, nobody tests them on RHEL and
> simply said for RHEL the solution is RHSCL channel. Although I understand
> you might be frustrated by not being able to do it simply the correct way..

That's the case for all the "RHEL++" solutions like Fedora's EPEL,
Rackspace's IUS, and SCLo itself though - while the main nominal user
base for those services is folks running entirely self-supported
environments on a community Linux distro, there are also lots of times
where they're used as workarounds for challenges that people run into
with the recommended approaches (whether that's the officially
supported channels missing a specific component that someone wants, a
user wanting a newer version of a component for a particular proof of
concept, or, as is the case here, the officially recommended approach
not yet being universally supported by all of Red Hat's redistribution
partners).

Consider the case of Red Hat's own sponsored upstream projects, for
example - we want to make it as easy as possible for them to switch to
SCLs as their recommended deployment environment, and by the very fact
that someone is experimenting with the upstream version rather than
the post-QA commercial Red Hat product, they're already saying they
don't want or need official support for that particular activity. Do
we really want to put those upstream projects in a position where they
*need* to recommend CentOS over RHEL because there aren't any
community-centric SCL enablement instructions that work reliably
across all cloud providers that offer RHEL images?

As long as folks that adopt workarounds are fully aware of the fact
that they *are* temporary workarounds rather than long term
substitutes for properly supported solutions, that's a better
situation than leaving them completely stuck with no guidance that
actually works universally *today*. For example, we could offer SCL
consumption guidance on softwarecollections.org like the following:

- For CentOS, use <existing instructions> to set up the
softwarecollections.org repositories
- For RHEL, use <existing instructions> to set up the Red Hat
supported RHSCL repositories
- If setting up the RHSCL repositories fails, and your organisation
runs Red Hat Satellite, ensure your systems are correctly registered
with Satellite first
- if your system isn't able to subscribe directly to the Red Hat
provided repositories, and you don't (as far as you are aware) have a
Satellite instance available:
    - report the RHSCL enablement problem to your RHEL provider
(whether that's a public cloud service or your internal IT
organisation)
    - while waiting for them to fix the issue, use <new workaround
instructions> to set up the softwarecollections.org repositories
- note explicitly that after the RHSCL channels are enabled, a RHEL
system is also correctly configured to work as a container host for
RHEL based, RHSCL enabled, containers

We could also explicitly note that for Fedora, the typically
recommended approach is to use the CentOS+SCLo approach inside a
container, rather than rebuilding the SCLs themselves specifically for
any given Fedora release.

At the moment, SCLo doesn't offer any central guidance on how to *use*
Software Collections, which makes it a bit of a
choose-your-own-adventure exercise for potential adopters, and means
you end up with a lot of *publisher* centric results (including
softwarecollections.org itself) if you type "using software
collections" into Google.

Explicitly adopting an approach like the one I suggest above would:

1. Make softwarecollections.org a better resource for folks looking to
consume *existing* Software Collections (whether Red Hat supported or
community supported), rather than publish their own;
2. Let people know that we're aware of the current RHEL-specific
cross-provider usability problem Noah pointed out and are working to
fix it properly;
3. Help ensure that folks that encounter RHSCL channel registration
problems are aware of how to troubleshoot and resolve them, rather
than giving up on SCLs in general; and
4. Remove a barrier to wider adoption of SCLs as a deployment
strategy, increasing the utility of softwarecollections.org as a place
to publish community maintained collections for development stacks
that Red Hat doesn't support commercially at all (akin to the
community quickstarts for OpenShift v2, and the "bring your own
container" feature in OpenShift v3)

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Platform Engineering, Brisbane