Bug 1692869 - Unable to enable propagation of new types once "deployments.apps" type is enabled
Summary: Unable to enable propagation of new types once "deployments.apps" type is ena...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Federation
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 4.1.0
Assignee: Maru Newby
QA Contact: Qin Ping
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-26 15:42 UTC by Mario Vázquez
Modified: 2019-10-22 08:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:46:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:46:33 UTC

Description Mario Vázquez 2019-03-26 15:42:56 UTC
Description of problem:

Enabling new types fails if "deployments.apps" type has been enabled before.


Version-Release number of selected component (if applicable):

OCP ClusterVersion 4.0.0-0.7

Federation deployed using the 0.0.7 CSV

kubefed2 version: version.Info{Version:"v0.0.7", GitCommit:"3e251608ca5357080b95a0bedc45759652f17d29", GitTreeState:"clean", BuildDate:"2019-03-22T22:30:26Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

Federation Controller Image: quay.io/kubernetes-multicluster/federation-v2:v0.0.7
 

How reproducible:

Always


Steps to Reproduce:

./kubefed2 enable deployments.apps --federation-namespace federation-test
customresourcedefinition.apiextensions.k8s.io/federateddeployments.types.federation.k8s.io created
federatedtypeconfig.core.federation.k8s.io/deployments.apps created in namespace federation-test

./kubefed2 enable namespaces --federation-namespace federation-test
F0326 16:27:45.753569   18104 enable.go:112] error: Error initializing validation schema accessor: Error loading openapi schema: SchemaError(io.k8s.federation.types.v1alpha1.FederatedDeployment.spec.retainReplicas): Unknown primitive type: "bool"

./kubefed2 disable deployments.apps --federation-namespace federation-test
Disabled propagation for FederatedTypeConfig "federation-test/deployments.apps"

./kubefed2 enable namespaces --federation-namespace federation-test
F0326 16:28:06.602719   18303 enable.go:112] error: Error initializing validation schema accessor: Error loading openapi schema: SchemaError(io.k8s.federation.types.v1alpha1.FederatedDeployment.spec.retainReplicas): Unknown primitive type: "bool"


Actual results:

You cannot enable any type after enabling "deployments.apps" type

Expected results:

You can enable any type after enabling "deployments.apps" type


Additional info:

eg. If I enable namespaces and then deployments, I can propagate deployments across multiple clusters. So it seems this is only affecting to new types propagation enablement.

Comment 1 Paul Morie 2019-03-27 20:51:04 UTC
I've had a few different users come to me about this bug.

One thing that looks weird to me:

   io.k8s.federation.types.v1alpha1.FederatedDeployment.spec.retainReplicas

That seems incorrect. I would have expected to see:

   io.k8s.federation.types.v1alpha1.FederatedDeployment.spec.template.retainReplicas

Perhaps that's related to this issue.

Comment 2 Maru Newby 2019-03-27 22:07:19 UTC
`spec.retainReplicas` is correct:

https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#scalable

The field type was incorrectly specified as `bool` instead of `boolean`. Upstream fix is https://github.com/kubernetes-sigs/federation-v2/pull/698

This bug does not exhibit on kubernetes 1.12, the current upstream test target, and presumably the 1.13 base of openshift 4.0 enables validation of openapi schema.  The version of kubernetes used for testing is tied to the version of kubebuilder we're using, so shashi's work to update to latest kubebuilder should also ensure the upstream testing uses the most recent kube release.

Comment 3 Maru Newby 2019-04-10 22:06:47 UTC
This is fixed in upstream, and this issue will need to be moved to ON_QA after the next operator release.

Comment 4 Qin Ping 2019-04-23 04:05:23 UTC
Verified with:
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.1.0-0.nightly-2019-04-22-005054   True        False         16h     Cluster version is 4.1.0-0.nightly-2019-04-22-005054

Federation v2 controller-manager version: version.Info{Version:"v0.0.8", GitCommit:"0d12bc3d438b61d9966c79a19f12b01d00d95aae", GitTreeState:"clean", BuildDate:"2019-04-11T04:57:35Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

kubefed2 version: version.Info{Version:"v0.0.8", GitCommit:"0d12bc3d438b61d9966c79a19f12b01d00d95aae", GitTreeState:"clean", BuildDate:"2019-04-11T04:26:34Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

Comment 6 errata-xmlrpc 2019-06-04 10:46:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0758


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