This is important in the light of sunsetting CentOS and the need to use RHEL instead. We will need to have this resolved in the first half on 2021.

One solution is to take the arch completely out of game.

The other solution can be to accept something like: `subscription-manager --register --arch ARCH` and we can workaround it in mock and in documentation that users can use this certificate. While it will be doable, it is definitelly a bit complicated.

(In reply to Miroslav Suchý from comment #1)
> This is important in the light of sunsetting CentOS and the need to use RHEL
> instead. We will need to have this resolved in the first half on 2021.
> 
> One solution is to take the arch completely out of game.
> 
> The other solution can be to accept something like: `subscription-manager
> --register --arch ARCH` and we can workaround it in mock and in
> documentation that users can use this certificate. While it will be doable,
> it is definitelly a bit complicated.

Hi Miroslav ,

Thanks for opening bug , This is the expected behaviour of subscriptions on RHEL . Today subscriptions do not work on cross arch. Can you please work this through RHEL market problem level, we believe handling this request in bugzilla may not be enough. 


thanks,
Rehana

Possible fallout when this feature will not be implemented:

* Copr will cancel armhpf and s390x arches for epel, or will have to allocate "native" HW for builders (impact on budget in thousands of dollars).

* ISV and 3rd party users on RHEL, CentOS and Fedora will not be able to "cross-compile" epel content anymore using mock

* In case that new version of Developer Subscription will need registration [not defined yet] , then ISV and 3rd party users will not be able to build their packages using Mock for epel-* and therefore for RHEL.


More context:
At this moment community, mock users, Copr, etc. build EPEL stuff against
CentOS+EPEL repositories.

Using CentOS in Copr never was a preferred variant though.  Even though
we'd like to be closer to RHEL, we were not easily able to switch the
builders to RHEL+EPEL.  The Copr builders are Fedora virtual machines
created/terminated dynamically in various public/private clouds, and to
access RHEL repositories we'd have to have the Fedora VMs specifically
subscribed.

At this moment we support builds for all the architectures Fedora Koji
supports, but we don't have the necessary kinds of hardware
architectures.  To work-around this, Copr started to use qemu emulation for
s390x and armhfp architectures (and likely will ppc64le in the future).

The CentOS is changing to the CentOS Stream now, and that's why we seem
that we'll have to switch our epel builds towards RHEL+EPEL (good thing in
general).  But we'll have to start consuming RHEL content on our builders.
So one problem is to obtain the subscriptions there.

What specifically is this request?  That the PEM files for other arches must be present for the dnf tooling to access foreign arch content?  Do the repositories need to be present also or can they be defined separately by a developer?

I have concerns, even for partner developers, of RHSM enabling the other arch repos as accidental installation could cause compatibility and support issues.  So similar to Mock only being present in the build root and not customer facing, I wonder if this problem could be solved in another way than RHSM.  If it only relates to the PEM files and the repos are configured manually by the developer, that might be ok.  But we do not want to add additional clutter to the redhat.repo file as that could have significant support implications.

This is a Red Hat problem, not a Market Problem, so I think either a Jira Feature or Epic at the SST maintenance level is sufficient to escalate priority and awareness.

-Terry

> That the PEM files for other arches must be present for the dnf tooling to access foreign arch content?

Yes.  We need a PEM file (or set of PEM files?) that would enable DNF to
download RHEL content for any architecture.  Not only the native host variant.

> Do the repositories need to be present also or can they be defined
> separately by a developer?

The set of repositories used by Copr/Mock is statically defined in
mock-core-configs.rpm package, e.g. in rhel-8-* config files.

> I have concerns, even for partner developers, of RHSM enabling the other
> arch repos as accidental installation could cause compatibility and
> support issues.

This is not a request to affect the behavior of the dynamically generated
/etc/yum.repos/redhat.repo file, i.e. this RFE should not accidentally
change '$basearch' at all, or start adding static cross-arch links there.

> So similar to Mock only being present in the build root and not customer
> facing, I wonder if this problem could be solved in another way than RHSM.

Ideas are welcome.  But we still need to access the RHEL content from public
places (copr builders, and end-users are controlling those machines).

The only solution is IMO to access CDN (which implies using PEM files).

> If it only relates to the PEM files and the repos are configured
> manually by the developer, that might be ok.  But we do not want to add
> additional clutter to the redhat.repo file as that could have
> significant support implications.

Absolutely.

> This is a Red Hat problem, not a Market Problem, 

Not sure I can tell the difference here, so probably yes.

Though any kind of public "RHEL-targeted" integration testing out there
will have to migrate from CentOS (used to serve good enough to test RHEL
integration) to RHEL content somehow in the future.  So if anyone
had to download cross-arch content from CentOS for *any* reason, now the
the problem will be shifted to RHEL.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.