Bug 1265120

Created attachment 1082927 [details]
Activation Key page

One can override the 'enable' setting for products, both custom and RH, in the activation key's "Product Content" page.

Moving 6.2 bugs out to sat-backlog.

I think an effective way to solve this issue would be to allow the user to define major OS release version and/or architecture for a custom products repos. 



This way you can have a single Custom Product, but the client (subscription-manager) will enable the correct repo based upon os/architecture.


EPEL
---- EPEL EL6 x86_64 repo
---- EPEL EL7 x86_64 repo


As a point of comparison, if you put both RHEL6 and RHEL7 content in the same content view and register a RHEL6 host to use it, only the RHEL6 repos show up. 


This is due to the 'required tags' field in the product/entitlement certs. 


rct cat-cert /etc/pki/product-default/69.pem

+-------------------------------------------+
	Product Certificate
+-------------------------------------------+

Certificate:
	Path: /etc/pki/product-default/69.pem
	Version: 1.0
	Serial: 12750047592154746560
	Start Date: 2016-01-04 13:07:32+00:00
	End Date: 2035-12-30 13:07:32+00:00

Subject:
	CN: Red Hat Product ID [b0918f42-730b-4ee9-b4ee-9504e60fcb1a]

Issuer:
	C: US
	CN: Red Hat Entitlement Product Authority
	O: Red Hat, Inc.
	OU: Red Hat Network
	ST: North Carolina
	emailAddress: ca-support

Product:
	ID: 69
	Name: Red Hat Enterprise Linux Server
	Version: 7.3
	Arch: x86_64
	Tags: rhel-7,rhel-7-server
	Brand Type: 
	Brand Name: 


Effectively the customer is asking for the same, but for custom products. Then they can have all the repos in a Custom product (and Content View) and they dont have to worry about activation key sprawl.

In our case it would be important to allow disabling in the product not in the activation key.

E.g. right now we create activation keys using hammer, then we have to call hammer to deactivate all active repositories on that newly created key and enable the ones we want afterwards.

*** Bug 1444156 has been marked as a duplicate of this bug. ***

*** Bug 1634108 has been marked as a duplicate of this bug. ***

*** Bug 1804101 has been marked as a duplicate of this bug. ***

Connecting redmine issue https://projects.theforeman.org/issues/29951 from this bug

Upstream bug assigned to paji

Upstream bug assigned to paji

*** Bug 1853497 has been marked as a duplicate of this bug. ***

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/29951 has been resolved.

We had tried allowing the user to disable/enable custom repos by default. But due to the way Candlepin works this would change the enablement of the repos retroactively for all clients, and there was no way to only change enablement at registration. This was considered dangerous/confusing and not acceptable by PM, and so we ended up reverting the change upstream (https://github.com/Katello/katello/pull/8947) and implementing https://bugzilla.redhat.com/show_bug.cgi?id=1526564 as an alternate approach.

I wouldn't consider https://bugzilla.redhat.com/show_bug.cgi?id=1526564 
an alternate approach as it doesn't fix the reported issue in this bz.

Customers still need to run bulk actions on every registered host to
disable a newly added custom repository. If a customer forgets this
they may install packages on clients that shouldn't be there.

>> this would change the enablement of the repos retroactively for all clients

That is true. But having the option to override the default behaviour at least
leaves the choice to the customer. We can add a warning message for changing 
the option.

Hello,
 Would it be possible to reconsider this BZ?
 I fully agree with Stefan above and would also suggest to have an option to override the default behavior.
 Maybe adding a warning when adding a custom repo to an AK, that this does not enable it automatically: what do you think?

Kind Regards,
 Cisco.

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/29951 has been resolved.

I'm going to defer to @rjerrido for further comment..

If I am understanding the request (and the PRs 8805/8947), the concern here is that repositories provided custom products are enabled by default, both in entitlement and SCA mode. 

The question, I will ask in response is 'will the users be OK with disabling these repositories by default (and enabling repos via AK)?', because that is the only alternative.

Hi @rjerrido I asked this to my customer and the answer was clearly, that if

a) any new (custom) repository is by default: disabled for EXISTING systems

and

b) the new (custom) repository is by default disabled for all Activation Keys i.e. you have to 'override to enabled' to make it available to new deployments.

well then that is exactly what should happen, yes.

Hope that clarifies it.

Kr,
 Cisco.


(In reply to Rich Jerrido from comment #50)
> If I am understanding the request (and the PRs 8805/8947), the concern here
> is that repositories provided custom products are enabled by default, both
> in entitlement and SCA mode. 
> 
> The question, I will ask in response is 'will the users be OK with disabling
> these repositories by default (and enabling repos via AK)?', because that is
> the only alternative.

I agree with cisco in #51.

If we cant have a a switch for each repo it is better to disable the custom repos by default
and leave it to the customer to set it to enabled in the activation key.

I think more customer input is required and I will ask our TAMs to check with their customers.

Hello, 
 we are eager to have any update about this proposal, if it's viable and what could be a possible timeline.

Thanks in advance,
 Cisco.

I understand that changing the default behaviour also affects pulp and subscription-manager.
If we can not change the default behaviour we should at least give our customers the option
to set a new repository to disabled or enabled. Same as we offer the option to set the arch
and os-release for custom repositories.

*** Bug 1983713 has been marked as a duplicate of this bug. ***

*** Bug 1985907 has been marked as a duplicate of this bug. ***

Customer in Public Sector is interested in this enhancement.  Is there an ETA on this RFE?

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

With legacy entitlement modes going away, I think the absence of this or a similar feature will be one of the biggest pain points for upstream users. So I think this should be kept open for more discussion.

Yet Another Customer who wants this feature.

Our company need this feature too, would be great to finally see it released.

+1 Our company need this feature too.

This feature is critical for customers who are preparing to enable Simple Content Access. Whether the decision is to change new custom repos to disabled by default for existing systems and activation keys or to provide an option to set it to disabled or enabled, it is critically important that this feature enhancement be added ASAP.

I have heard some conjecture about how content views can be leveraged as an alternative to disabling new repos across your entire inventory, but this is not a good alternative. We wrote a custom script to identify the different permutations of subscription sets that our hosts have and we have over 100 unique subscription sets across our hosts. I do not believe that this would be an unusual result for customers. It would be untenable to tightly restrict repository visibility for the sole purpose of fencing off repositories by managing over 100 content views because the project team doesn't want to implement a simple RFE.

The current enabled by default with no option to change it for custom repositories was not disruptive to this point, due to subscriptions being a gatekeeper of sorts while Simple Content Access is disabled. However, once SCA is enabled and that "gatekeeper" is removed, this design choice becomes unreasonable for customers. With SCA enabled, there should be a way to add a custom repository to your environment without having to then manually go and disable it on every existing host and activation keys OR create additional content views that have to be perpetually managed.

+1 to have this feature added. The switch to Simple Content Access will be incredibly disruptive unless we are able to add new repositories as disabled by default.

Also +1 we're moving to SCA and having all of the repos enabled by default is not working for us.

For folks who are having issues preparing for SCA due to custom repos having been set to enabled by default, please feel free to look at this gist of a script that we wrote to assist in our transition (ongoing) https://gist.github.com/JRNC/62ebe4b9045ed06420f26be0d878e7e0. This script will identify and group hosts in Satellite that share the same exact set of subscriptions and create a host collection per grouping. This is helpful for teams that are preparing to enable Simple Content Access; however, need to first disable all of the unsubscribed repositories that set themselves to enabled by default. Instead of disabling unsubscribed repositories host by host, this will trim it down, so that you can disable unsubscribed repositories host collection by host collection. I hope that this can help some folks.

(In reply to James Riley from comment #90)
> For folks who are having issues preparing for SCA due to custom repos having
> been set to enabled by default, please feel free to look at this gist of a
> script that we wrote to assist in our transition (ongoing)
> https://gist.github.com/JRNC/62ebe4b9045ed06420f26be0d878e7e0. This script
> will identify and group hosts in Satellite that share the same exact set of
> subscriptions and create a host collection per grouping. This is helpful for
> teams that are preparing to enable Simple Content Access; however, need to
> first disable all of the unsubscribed repositories that set themselves to
> enabled by default. Instead of disabling unsubscribed repositories host by
> host, this will trim it down, so that you can disable unsubscribed
> repositories host collection by host collection. I hope that this can help
> some folks.

Disclaimer, I am not a Red Hat employee and the script is being made public to help out the community (no support or guarantee of proper functionality).

Updating with the current state of how we're addressing this:

We're going to flip the default enablement for custom repositories (e.g. repositories that are part of custom products).

Previously, custom products were enabled by default.

Now, they're going to be disabled by default.

However, we need to do this with minimal disruption to existing hosts. This will be done with a migration that adds content overrides so that repo enablement on a given host will remain the same after upgrade.

This change will apply to all users, but it's in the context of Simple Content Access soon becoming the only supported entitlement management strategy.

Verification Criteria:

When I create a new custom repository, it's disabled by default (e.g. `subscription-manager repos` shows `Enabled: 0` for that repo) and I can't install packages from it)
When I upgrade Satellite, the enablement of my existing repos on my existing hosts is not affected.
Any repos that were previously "Enabled" are now "Enabled (Overridden)"
subscription-manager repos shows `Enabled: 1` for these repos
I am able to easily add content overrides ("Override to Enabled" / "Override to Disabled") on existing hosts
I am able to easily add content overrides ("Override to Enabled" / "Override to Disabled") on activation keys

*** Bug 1938365 has been marked as a duplicate of this bug. ***