provide cluster-config in config.openshift.io

[deads2k]

Much of the content in https://github.com/openshift/installer/blob/master/pkg/types/installconfig.go#L23 should be moved to specific config.openshift.io types.

For example

1. Platform should move to https://github.com/openshift/api/blob/master/config/v1/types_infrastructure.go#L27 so we can see the cloud information and a secret ref
2. Networking should move to https://github.com/openshift/api/blob/master/config/v1/types_network.go#L29

This doesn't necessarily mean that we have to remove the oc get cm -nkube-system cluster-config-v1 -oyaml, but operators should consume the the information from the source of truth.

I see at least one option for achieving this, but I'm open to other suggestions as well.

1. perhaps there could be to be a renderer that creates these installer driven types from config.openshift.io (as distinct from add-ons like images or oauth). That, in combination with placing them in a CVO payload would allow both initial provisioning and future maintenance.

/assign @crawford @abhinavdahiya
@openshift/api-review for where bits move
@jwforres @derekwaynecarr fyi
@ironcladlou @squeed fyi since you both deal with the first two I saw.

[jwforres]

cc @bparees since i think this what you'll want to follow re: the final home for the cloud provider and cloud creds

[wking]

1. Platform should move to https://github.com/openshift/api/blob/master/config/v1/types_infrastructure.go#L27 so we can see the cloud information and a secret ref
2. Networking should move to https://github.com/openshift/api/blob/master/config/v1/types_network.go#L29

Shouldn't the config information be in InfrastructureSpec and NetworkSpec? From a few lines up:

  // spec holds user settable values for configuration
  Spec NetworkSpec `json:"spec"`
  // status holds observed values from the cluster. They may not be overridden.
  Status NetworkStatus `json:"status"`

Do you also want to push the platform-specific sub-structures over to the API repo? That might make rolling out new platforms or iterating on them more complicated (two repos to touch while you work out installer issues for the new platform). Should these structures incubate in the installer and then be frozen out into the API repo when they're stable on new platforms and ready for out-of-installer consumers?

[deads2k]

Do you also want to push the platform-specific sub-structures over to the API repo?

Yes. We expect openshift/api to be the source of truth for operators running on cluster.

Should these APIs incubate in the installer and then be frozen out into the API repo when they're stable on new platforms and ready for out-of-installer consumers?

We have dependencies growing on this now. We need to provide these as soon as is practical.

[wking]

#717 was a step in this direction. Once we get the config pushed out into custom resources and transition consumers, I think we should drop cluster-config-v1 to avoid confusing cluster admins.

And once we drop cluster-config-v1, we should think about dropping the InstallConfig type completely. The trade off for an installer-only InstallConfig type is pro "isolates openshift-install callers from config.openshift.io resource evolution" vs. con "gives openshift-install callers one more layer of indirection to wrap their heads around". Do we have guesses about how fluxy we expect these custom resources to be? Do we have guesses about how much flux callers will accept? CC @csrwng and @dgoodwin on the Hive side, since they'd be replacing their install-config injection with a few custom-resource injections if we decide to remove the indirection.

[abhinavdahiya]

we should think about dropping the InstallConfig type completely.

The installer still needs a single object to drive its creation. why would we drop InstallConfig?

InstallConfig type's purpose is to be the smallest configuration to create cluster.
The purpose of config.openshift.io is to be complete configuration.