Bug 1734063

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

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.

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.

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).

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.

(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)?

> 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