api: Move CVOConfig to final name and location

[smarterclayton]

As discussed in previous review sessions, we want to have all core configuration api objects in the same API group, and we also want to rename CVOConfig to ClusterVersion. This PR changes both - the proposed name for the group is config.openshift.io as in, "the config for an openshift cluster".

Reasons for wanting ClusterVersion as a name:

• Describes what the object does (manage the cluster version)
• More closely aligns with the ClusterVersionOperator

Reasons for wanting config.openshift.io as a group name:

• The cluster version is part of the configuration of a cluster
• When someone asks "where is the configuration for openshift", we can say "the resources in the config.openshift.io API group"

Reasons for wanting one API group for ClusterVersion, ClusterOperator, and top level config (Image, Network)

• Makes it easy for an administrator to find "objects that control the configuration of a cluster"
• Makes generating a client to manage an openshift cluster easy
• Encourages the idea of CVO + top level config as being "all you need to configure a cluster"

Reasons for moving ClusterOperator into config.openshift.io

• The CVO mediates the relationship between the second level operators and the user, so the CVO needs to summarize and report their status back to users.
• The ClusterVersion object is the first object a user should look at with regards to upgrades, but the next natural object they will look at is ClusterOperator (the CVO is a ClusterOperator as well) to find out what is going wrong.

Changes that have been discussed and may influence how people feel about this change, but are not part of this PR:

• Make ClusterVersion have spec and status (spec is what you want the cluster version to be, status is what it is at)
• Update ClusterVersion field naming to match terminology we are using else where
• Move ClusterOperator into config.openshift.io
• Move ClusterVersion and ClusterOperator to be cluster scoped

One example possible final state (assuming we did all above):

apigroup: config.openshift.io

kind: ClusterVersion
apiVersion: config.openshift.io/v1
metadata:
  name: ...
spec:
  channel: production
  overrides: ...
  update:
    version: 4.1.2
status:
  availableUpdates:
  - version: 4.1.3

kind: ClusterOperator
apiVersion: config.openshift.io/v1
metadata:
  name: cluster-version
status:
  version: 4.1.2
  conditions:
  - type: Available
     status: True

kind: Network
apiVersion: config.openshift.io/v1
metadata:
  name: instance
spec:
  serviceCIDR: 10.1.0.0/16
  podCIDRs:
  - 10.2.0.0/16

# find all config related resources for a cluster
$ oc api-resources --api-group=config.openshift.io
NAME            SHORTNAMES   APIGROUP            NAMESPACED   KIND
clusterversion               config.openshift.io false        ClusterVersion
clusteroperator              config.openshift.io false        ClusterOperator
image                        config.openshift.io false        Image
network                      config.openshift.io false        Network

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: smarterclayton

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [smarterclayton]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[smarterclayton]

when this merges we also need to merge openshift/installer#549

[smarterclayton]

@deads2k @abhinavdahiya @crawford we've all talked about aspects of this before, if we're not on the same page completely I'll keep adding detail until we are. This only renames CVOConfig and moves groups.

[deads2k]

this stands out now.

[smarterclayton]

Yeah, I think the spec/status split discussion can happen as a second step here. I will create a PR that has those additional commits so we can look at it.

[deads2k]

pre-existing, but where is the list?

[smarterclayton]

Added

[deads2k]

I'm in favor of the change. I think you accidentally moved a second type with this type though.

[smarterclayton]

It's not easy to make the installer able to tolerate both CRDs, so the best option I can see is to get review and deliver the rename to the CRD into both repos at once.

[deads2k]

lgtm

will leave tagging to @abhinavdahiya or @crawford

[smarterclayton]

Closing in favor of #45 which contains this change is approved by abhinav