Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

provide cluster-config in config.openshift.io #680

Closed
deads2k opened this issue Nov 15, 2018 · 6 comments
Closed

provide cluster-config in config.openshift.io #680

deads2k opened this issue Nov 15, 2018 · 6 comments
Assignees
@crawford @abhinavdahiya

Comments

@deads2k
Copy link
Contributor

deads2k commented Nov 15, 2018

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
Copy link
Member

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

@wking
Copy link
Member

wking commented Nov 15, 2018 •
edited
Loading

  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
Copy link
Contributor Author

deads2k commented Nov 15, 2018

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
Copy link
Member

wking commented Nov 28, 2018

#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
Copy link
Contributor

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.

@wking wking mentioned this issue Dec 19, 2018
Merged
@wking wking mentioned this issue Jan 2, 2019
Closed
@wking wking mentioned this issue Jan 30, 2019
Merged
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Jan 30, 2019
@abhinavdahiya
machines: add the authorized keys for a pool using a machine config
87f5c3d 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Jan 30, 2019
@abhinavdahiya
asset/manifests: update status of Infrastructure
e86ff6c 
This updates the `Infrastructure.config.openshift.io` object to catch up with [1].

Machine Config Operator uses the `APIServerURL` to point the kubelet on machines to apiserver, and `EtcdDiscoveryDomain` to setup the etcd
members to bootstrap the etcd cluster using dns discovery [2].

This is required as Machine Config Operator currently uses the `cluster-config-v1` to creates these values and as `cluster-config-v1` is getting deprecated [3], Machine Config Operator will move to
using the status of `Infrastructure.config.openshift.io` for sourcing that information.

[1]: openshift/api#189
[2]: https://github.com/etcd-io/etcd/blob/583763261f1c843e07c1bf7fea5fb4cfb684fe87/Documentation/op-guide/clustering.md#dns-discovery
[3]: openshift#680
@abhinavdahiya abhinavdahiya mentioned this issue Jan 31, 2019
Merged
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Jan 31, 2019
@abhinavdahiya
asset/manifests: update status of Infrastructure
f4ba180 
This updates the `Infrastructure.config.openshift.io` object to catch up with [1].

Machine Config Operator uses the `APIServerURL` to point the kubelet on machines to apiserver, and `EtcdDiscoveryDomain` to setup the etcd
members to bootstrap the etcd cluster using dns discovery [2].

This is required as Machine Config Operator currently uses the `cluster-config-v1` to creates these values and as `cluster-config-v1` is getting deprecated [3], Machine Config Operator will move to
using the status of `Infrastructure.config.openshift.io` for sourcing that information.

[1]: openshift/api#189
[2]: https://github.com/etcd-io/etcd/blob/583763261f1c843e07c1bf7fea5fb4cfb684fe87/Documentation/op-guide/clustering.md#dns-discovery
[3]: openshift#680
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Jan 31, 2019
@abhinavdahiya
asset/manifests: update status of Infrastructure
218aa9b 
This updates the `Infrastructure.config.openshift.io` object to catch up with [1].

Machine Config Operator uses the `APIServerURL` to point the kubelet on machines to apiserver, and `EtcdDiscoveryDomain` to setup the etcd
members to bootstrap the etcd cluster using dns discovery [2].

This is required as Machine Config Operator currently uses the `cluster-config-v1` to creates these values and as `cluster-config-v1` is getting deprecated [3], Machine Config Operator will move to
using the status of `Infrastructure.config.openshift.io` for sourcing that information.

[1]: openshift/api#189
[2]: https://github.com/etcd-io/etcd/blob/583763261f1c843e07c1bf7fea5fb4cfb684fe87/Documentation/op-guide/clustering.md#dns-discovery
[3]: openshift#680
@eparis
Copy link
Member

eparis commented Feb 19, 2019

install config is not something others should be using, so I believe this can be closed....

@eparis eparis closed this as completed Feb 19, 2019
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Mar 25, 2019
@abhinavdahiya
machines: add the authorized keys for a pool using a machine config
362106c 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
abhinavdahiya added a commit to abhinavdahiya/machine-config-operator that referenced this issue Mar 26, 2019
@abhinavdahiya
operator: remove the generated ssh key machineconfig
0b56194 
The original feature of syncing the ssh key for authorized users from `cluster-config-v1` config map was added in [1]. The original assumption was
that as `cluster-config-v1` was being deprecated in favor of global configs [2] and we will be able to find new home for the source of authorized keys for `core` user.

Based on several discussions like [3], The better UX for users is that machineconfig with authorized keys is not owned by the controller and is rather pushed by the installer at install time.
This allows users to edit the machineconfig directly to remove, add and manage the list of authorized keys.

[1]: openshift@a46fcad
[2]: openshift/installer#680
[3]: https://projects.engineering.redhat.com/browse/COREOS-1059
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Mar 27, 2019
@abhinavdahiya
machines: add the authorized keys for a pool using a machine config
8967ccd 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Mar 27, 2019
@abhinavdahiya
machines: add the authorized keys for a pool using a machine config
c1ae013 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this issue Mar 27, 2019
@abhinavdahiya
machines: add the authorized keys for a pool using a machine config
5623cbd 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
vrutkovs pushed a commit to vrutkovs/installer that referenced this issue Apr 1, 2019
@abhinavdahiya @vrutkovs
machines: add the authorized keys for a pool using a machine config
52f66d4 
`cluster-config-v1` is being deprecated in favor of global configs [1] and Machine Config Operator needs to
drop using the `SSHKey` in install-config [2] to setup the `SSHAuthorizedKeys` for `core` user.

This pushes a machineconfig with the `SSHAuthorizedKeys` sourced from [2] for each machinepool, so that Machine Config Operator can drop
generating the machineconfig using the `cluster-config-v1` config map in the cluster.

[1]: openshift#680
[2]: https://godoc.org/github.com/openshift/installer/pkg/types#InstallConfig
wking added a commit to wking/cluster-image-registry-operator that referenced this issue Apr 23, 2019
@wking
pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshif…
cc3b2c9 
…t.io

Mostly, this is replacing cluster-config-v1 (which is deprecated [1])
with the Infrastructure config object.  As part of that, I'm dropping
UserTags support (see discussion in [2,3]).  I'm also replacing the
openshiftClusterID tag with a "kubernetes.io/cluster/{infraName}:
owned" tag [4,5].

[1]: openshift/installer#680
[2]: openshift/api#231 (comment)
[3]: openshift/api#266
[4]: openshift/installer#1280
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1685089#c11
@wking wking mentioned this issue Apr 23, 2019
Closed
wking added a commit to wking/cluster-image-registry-operator that referenced this issue Apr 23, 2019
@wking
pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshif…
7244438 
…t.io

Mostly, this is replacing cluster-config-v1 (which is deprecated [1])
with the Infrastructure config object.  As part of that, I'm dropping
UserTags support (see discussion in [2,3]).  I'm also replacing the
openshiftClusterID tag with a "kubernetes.io/cluster/{infraName}:
owned" tag [4,5].

UnversionedRESTClientFor (vs. RESTClientFor) avoids errors like:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-fc9948cc-b767n_cluster-image-registry-operator.log.gz | gunzip
  I0423 05:43:03.599910       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g38fc8f9-dirty
  ...
  I0423 05:43:04.942285       1 bootstrap.go:38] generating registry custom resource
  E0423 05:43:04.942775       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing

InClusterConfig does not set GroupVersion [6] and RESTClientFor
requires it [7] while UnversionedRESTClientFor can fill it in [8].

[1]: openshift/installer#680
[2]: openshift/api#231 (comment)
[3]: openshift/api#266
[4]: openshift/installer#1280
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1685089#c11
[6]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L422-L428
[7]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L269-L270
[8]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L331-L333
wking added a commit to wking/cluster-image-registry-operator that referenced this issue Apr 23, 2019
@wking
pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshif…
843c843 
…t.io

Mostly, this is replacing cluster-config-v1 (which is deprecated [1])
with the Infrastructure config object.  As part of that, I'm dropping
UserTags support (see discussion in [2,3]).  I'm also replacing the
openshiftClusterID tag with a "kubernetes.io/cluster/{infraName}:
owned" tag [4,5].

The trip through clientcorev1.NewForConfig is because calling
RESTClientFor on the InClusterConfig raises:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-fc9948cc-b767n_cluster-image-registry-operator.log.gz | gunzip
  I0423 05:43:03.599910       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g38fc8f9-dirty
  ...
  I0423 05:43:04.942285       1 bootstrap.go:38] generating registry custom resource
  E0423 05:43:04.942775       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing

InClusterConfig does not set GroupVersion [6] and RESTClientFor
requires it [7] while UnversionedRESTClientFor can fill it in [8].
But UnversionedRESTClientFor leaves NegotiatedSerializer unset:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1305/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-66d8b56784-5wt9v_cluster-image-registry-operator.log.gz | gunzip
  I0423 09:21:42.998300       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g64d5f62-dirty
  ...
  I0423 09:21:44.345677       1 bootstrap.go:38] generating registry custom resource
  E0423 09:21:44.346403       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: NegotiatedSerializer is required when initializing a RESTClient, requeuing

So I'm washing through clientcorev1.NewForConfig to get defaults for
both [9].

[1]: openshift/installer#680
[2]: openshift/api#231 (comment)
[3]: openshift/api#266
[4]: openshift/installer#1280
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1685089#c11
[6]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L422-L428
[7]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L269-L270
[8]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L331-L333
[9]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/kubernetes/typed/core/v1/core_client.go#L144-L155
wking added a commit to wking/cluster-image-registry-operator that referenced this issue Apr 23, 2019
@wking
pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshif…
4b2bbe5 
…t.io

Mostly, this is replacing cluster-config-v1 (which is deprecated [1])
with the Infrastructure config object.  As part of that, I'm dropping
UserTags support (see discussion in [2,3]).  I'm also replacing the
openshiftClusterID tag with a "kubernetes.io/cluster/{infraName}:
owned" tag [4,5].

The trip through clientcorev1.NewForConfig is because calling
RESTClientFor on the InClusterConfig raises:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-fc9948cc-b767n_cluster-image-registry-operator.log.gz | gunzip
  I0423 05:43:03.599910       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g38fc8f9-dirty
  ...
  I0423 05:43:04.942285       1 bootstrap.go:38] generating registry custom resource
  E0423 05:43:04.942775       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing

InClusterConfig does not set GroupVersion [6] and RESTClientFor
requires it [7] while UnversionedRESTClientFor can fill it in [8].
But UnversionedRESTClientFor leaves NegotiatedSerializer unset:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1305/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-66d8b56784-5wt9v_cluster-image-registry-operator.log.gz | gunzip
  I0423 09:21:42.998300       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g64d5f62-dirty
  ...
  I0423 09:21:44.345677       1 bootstrap.go:38] generating registry custom resource
  E0423 09:21:44.346403       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: NegotiatedSerializer is required when initializing a RESTClient, requeuing

So I'm washing through clientcorev1.NewForConfig to get defaults for
both [9].

The RBAC change avoids:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1306/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-7f59899bf6-8c8x8_cluster-image-registry-operator.log.gz | gunzip | head -n7
  I0423 10:44:51.121540       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-gfa5b59b-dirty
  ...
  I0423 10:44:52.461691       1 bootstrap.go:38] generating registry custom resource
  E0423 10:44:52.464035       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: infrastructures "cluster" is forbidden: User "system:serviceaccount:openshift-image-registry:cluster-image-registry-operator" cannot get resource "infrastructures" in API group "" at the cluster scope, requeuing

[1]: openshift/installer#680
[2]: openshift/api#231 (comment)
[3]: openshift/api#266
[4]: openshift/installer#1280
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1685089#c11
[6]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L422-L428
[7]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L269-L270
[8]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L331-L333
[9]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/kubernetes/typed/core/v1/core_client.go#L144-L155
wking added a commit to wking/cluster-image-registry-operator that referenced this issue Apr 23, 2019
@wking
pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshif…
bb90d24 
…t.io

Mostly, this is replacing cluster-config-v1 (which is deprecated [1])
with the Infrastructure config object.  As part of that, I'm dropping
UserTags support (see discussion in [2,3]).  I'm also replacing the
openshiftClusterID tag with a "kubernetes.io/cluster/{infraName}:
owned" tag [4,5].

The trip through clientcorev1.NewForConfig is because calling
RESTClientFor on the InClusterConfig raises:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-fc9948cc-b767n_cluster-image-registry-operator.log.gz | gunzip
  I0423 05:43:03.599910       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g38fc8f9-dirty
  ...
  I0423 05:43:04.942285       1 bootstrap.go:38] generating registry custom resource
  E0423 05:43:04.942775       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing

InClusterConfig does not set GroupVersion [6] and RESTClientFor
requires it [7] while UnversionedRESTClientFor can fill it in [8].
But UnversionedRESTClientFor leaves NegotiatedSerializer unset:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1305/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-66d8b56784-5wt9v_cluster-image-registry-operator.log.gz | gunzip
  I0423 09:21:42.998300       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g64d5f62-dirty
  ...
  I0423 09:21:44.345677       1 bootstrap.go:38] generating registry custom resource
  E0423 09:21:44.346403       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: NegotiatedSerializer is required when initializing a RESTClient, requeuing

So I'm washing through clientcorev1.NewForConfig to get defaults for
both [9].

The RBAC change avoids:

  $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1306/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-7f59899bf6-8c8x8_cluster-image-registry-operator.log.gz | gunzip | head -n7
  I0423 10:44:51.121540       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-gfa5b59b-dirty
  ...
  I0423 10:44:52.461691       1 bootstrap.go:38] generating registry custom resource
  E0423 10:44:52.464035       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: infrastructures "cluster" is forbidden: User "system:serviceaccount:openshift-image-registry:cluster-image-registry-operator" cannot get resource "infrastructures" in API group "" at the cluster scope, requeuing

[1]: openshift/installer#680
[2]: openshift/api#231 (comment)
[3]: openshift/api#266
[4]: openshift/installer#1280
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1685089#c11
[6]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L422-L428
[7]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L269-L270
[8]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/rest/config.go#L331-L333
[9]: https://github.com/kubernetes/client-go/blob/59781b88d0faa9d51be48b4ca49eb08e05246de4/kubernetes/typed/core/v1/core_client.go#L144-L155
@wking wking mentioned this issue May 7, 2019
Closed
@celebdor celebdor mentioned this issue Jun 6, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@crawford crawford

@abhinavdahiya abhinavdahiya

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wking @crawford @jwforres @abhinavdahiya @eparis @deads2k