Bug 1734063 - Samples config is under the wrong place
Summary: Samples config is under the wrong place
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Templates
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Adam Kaplan
QA Contact: XiuJuan Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-29 14:38 UTC by Eric Rich
Modified: 2019-10-22 20:59 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 16:15:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Rich 2019-07-29 14:38:27 UTC
Description of problem: Sample Operator config should be under 

> samples.config.openshift.io
NOT
> configs.samples.operator.openshift.io

Version-Release number of selected component (if applicable): 4.1
How reproducible: 100%

Comment 2 Gabe Montero 2019-08-19 14:43:14 UTC
cc:ed Ben, as he was the one that told me to employ `configs.samples.operator.openshift.io` during 4.1 dev.
There were specific reasons for that IIRC, and in fact we might have moved off of `samples.config.openshift.io` at one point.

Hopefully he remembers the details.

image registry operator is also of this ilk I believe 

changing api objects like this are non-trivial if i understand it correctly

Comment 3 Samuel Padgett 2019-08-19 14:45:32 UTC
Note that console is looking for resources in config.openshift.io to populate the Cluster Settings -> Global Configuration tab. If we want samples config to appear there in the current API group, we'd need a special case.

Comment 4 Oleg Bulatov 2019-08-19 14:49:53 UTC
The image registry operator also uses the name "config" for its resource type. And I don't think there is an easy way to change the name without breaking backward compatibility.

Comment 5 Adam Kaplan 2019-08-19 15:33:28 UTC
Echoing Gabe - this is a non-trivial API change that only adds marginal value to the product, while adding a significant amount of maintenance burden. Without an explicit mandate to make all of our operator APIs live in the config.openshift.io group, I vote to close this as WONTFIX.

Sam - you'll at minimum need special case logic for the samples and registry API groups (config.samples.operator.openshift.io, config.imageregistry.operator.openshift.io).

Comment 6 Ben Parees 2019-08-19 17:13:49 UTC
operator.openshift.io is for the resource that controls specific operator/operand behavior

config.openshift.io is for general cluster configuration that may be watched by multiple operators or other consumers.

So we shouldn't consider moving it to config.openshift.io.  This is consistent with our other operators/config resources.

Now, ideally and hindsight being 20/20 we'd probably have put it in "samples.operator.openshift.io" (which aligns with most of the other operator resources in the cluster) instead of "config.samples.operator.openshift.io" because at the time my view was that we'd potentially have other "xxx.samples.operator.openshift.io" and I didn't want the "samples.operator.openshift.io" namespace to be locked to a single "Config" resource type name.

However at this point migrating the config resource group/package name would be a somewhat significant effort.  I would consider it extremely low priority RFE(not a bug), in deference to adequate documentation that points users to the resource and explains what it controls.

As Gabe notes, the image-registry also followed this pattern, so if we were going to try to migrate anything, we would also want to migrate that one.

Comment 7 Eric Rich 2019-10-22 20:53:28 UTC
(In reply to Ben Parees from comment #6)
> However at this point migrating the config resource group/package name would
> be a somewhat significant effort.  I would consider it extremely low
> priority RFE(not a bug), in deference to adequate documentation that points
> users to the resource and explains what it controls.

Bug or RFE (does not matter here). What matters is the lack of focus on making understanding configuration simple, for customers.
If we scatter configurations all over the place and we don't follow a convention the only place they can go is to documentation. Pointing customer to 100 locations in docs, to configure the 100 different things with 1000's of possible options leads to a frustrated customer. 

We should _really_ consider addressing this. 
 
> As Gabe notes, the image-registry also followed this pattern, so if we were
> going to try to migrate anything, we would also want to migrate that one.

It too is doing the wrong thing (IMO) and should take corrective action, as you denote. Should we open a bug/RFE to track both changes (separate trackers or one tracker)?

Comment 8 Ben Parees 2019-10-22 20:59:44 UTC
> If we scatter configurations all over the place and we don't follow a convention the only place they can go is to documentation.

i don't know how else you expect customers to learn the name of the resource they need to edit if they want to tweak settings.  Even if it was "samples.operator.openshift.io" no one is going to just randomly discover that resource name/package by guessing.

So reading the docs and learning the config resource/package is "config.samples.operator.openshift.io" vs reading the docs and learning it's "samples.operator.openshift.io" is a distinction w/o a difference imho.

> Pointing customer to 100 locations in docs, to configure the 100 different things with 1000's of possible options leads to a frustrated customer. 

Not 100 places.  I worked with the docs team to ensure we provided a single place in the docs where we cover all of these resources, pretty much for exactly this reason:
https://docs.openshift.com/container-platform/4.2/installing/install_config/customizations.html#configuration-resources_customizations


Note You need to log in before you can comment on or make changes to this bug.