Description of problem: Enable Service API federation multiple time with different federation-group failed Version-Release number of selected component (if applicable): $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-03-25-180911 True False 57m Cluster version is 4.0.0-0.nightly-2019-03-25-180911 kubefed2 version: version.Info{Version:"0.0.6", GitCommit:"de6a0a909418f5ddf2d04d232b0ca55aa9cffb49", GitTreeState:"clean", BuildDate:"2019-03-14T00:43:37Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Federation v2 controller-manager version: version.Info{Version:"0.0.6", GitCommit:"de6a0a909418f5ddf2d04d232b0ca55aa9cffb49", GitTreeState:"clean", BuildDate:"2019-03-14T00:43:37Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} How reproducible: 100% Steps to Reproduce: 1. Install a namespace scoped federation controller manager 2. Join a cluster to a federation 3. Enable service federation with cmd: ./kubefed2 enable svc --federation-group="types.federation.openshift.io" $ ./kubefed2 enable svc --federation-group="types.federation.openshift.io" customresourcedefinition.apiextensions.k8s.io/federatedservices.types.federation.openshift.io created federatedtypeconfig.core.federation.k8s.io/services created in namespace federation-system 4. Enable service federation with cmd(with different federation-group): $ ./kubefed2 enable svc Actual results: customresourcedefinition.apiextensions.k8s.io/federatedservices.types.federation.k8s.io created F0326 15:53:15.219766 7969 enable.go:109] error: Error creating FederatedTypeConfig "services": federatedtypeconfigs.core.federation.k8s.io "services" already exists Expected results: 1. Do not create crd: federatedservices.types.federation.k8s.io created 2. And report service federation has aready been enabled. Additional info:
This one is actually a little more interesting than it may seem on the surface. In terms of what we've discussed as a group so far, and what federation does today, the desire for an error message saying that federation has already been enabled for a type makes sense. However, we haven't yet talked about updating the federated APIs from version to version of the targeted API. Marking for 4.2
I've filed an upstream issue, and intend to see it fixed for the upstream beta release: https://github.com/kubernetes-sigs/federation-v2/issues/743
743 is fixed and will be released in the next release of federation (later this week).
Fix is included in releases rc1 and greater.
Verified with kubefedctl version: version.Info{Version:"v4.2.0", GitCommit:"ee84d241d0d8038640f9dad7cbeb0ea8cce58b6c", GitTreeState:"clean", BuildDate:"2019-08-06T18:27:54Z", GoVersion:"go1.12.6", Compiler:"gc", Platform:"linux/amd64"} $ kubefedctl enable svc --kubefed-namespace=federation-system customresourcedefinition.apiextensions.k8s.io/federatedservices.types.kubefed.io created federatedtypeconfig.core.kubefed.io/services created in namespace federation-system $ kubefedctl enable svc --kubefed-namespace=federation-system --federated-group=test.io F0808 16:08:30.089727 3740 enable.go:110] Error: Federation is already enabled for "services/v1" with federated type "federatedservices.types.kubefed.io/v1beta1". Changing the federated type to "federatedservices.test.io/v1beta1" is not supported. $ oc get crd |grep federatedservice federatedservices.types.kubefed.io 2019-08-08T08:07:50Z federatedservicestatuses.core.kubefed.io 2019-08-08T02:14:31Z $ oc get federatedtypeconfig services -n federation-system -ojson|jq .spec { "federatedType": { "group": "types.kubefed.io", "kind": "FederatedService", "pluralName": "federatedservices", "scope": "Namespaced", "version": "v1beta1" }, "propagation": "Enabled", "targetType": { "kind": "Service", "pluralName": "services", "scope": "Namespaced", "version": "v1" } }
Does this bug require doc text? The Doc Type/Text field is not currently set. Thanks!
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:2922