Bug 1690276
| Summary: | non-federated namespace scoped objects still can be created by federated object after the namespace API federation disabled | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Qin Ping <piqin> |
| Component: | Federation | Assignee: | Ivan Font <ifont> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Qin Ping <piqin> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.1.0 | CC: | bbennett, mnewby, pmorie |
| Target Milestone: | --- | ||
| Target Release: | 4.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-17 15:31:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This is expected behavior in a namespaced control plane since namespace propagation is never enabled for a namespaced control plane (this will be indicated in the controller manager logs). Placement for a namespaced federated resource (e.g. FederatedSecret) is determined by the intersection of its own placement and the placement of the FederatedNamespace in the same namespace, regardless of whether propagation is enabled for FederatedNamespace. I'm guessing this is suggestive of a doc bug. What exactly does this step mean?
5. Disable the Namespace API federation.
Maru and I read this different ways. Maru read it to mean a change to the placement of the federated namespace resource. I read it to mean "kubefed2 disable namespaces".
Would you clarify?
Actually, I don't know, how we want the end user to use the federation. From my using experience, E1. If one namespace-scoped API federation enabled after Namespace API federation, in spite of the Namespace API federation is disabled or enabled again, it will not effect the object propogation E2. If one namespace-scoped API federation enabled before Namespace API federation, the object propogation will not work until enabled the Namespace API federation. E3. In E1, after the Namespace API federation disabled, namespace-scoped object still can propogate, but if the federationv2 control plane pod was deleted, then the object can not propogate. Seems, there is no a consistent rule about the object propogation. (In reply to Qin Ping from comment #3) > Actually, I don't know, how we want the end user to use the federation. I think Paul's question was regarding what you meant by your reproduction step 'Disable the Namespace API federation'. It would also be helpful if you would confirm the scope of the control plane (namespace-scoped vs cluster-scoped). A namespace-scoped federation control plane doesn't run a sync controller for namespaces, since there are no namespaces to propagate (the federation namespace is guaranteed to exist on all member clusters thanks to `kubefed2 join`). Therefore, setting `propagationEnabled: false` in the FederatedTypeConfig for namespaces will have no effect. A FederatedNamespace resource is still necessary, but only for defining resource propagation for its sibling federated resources. The command used to disable Namespace API federation is: kubefed2 disable namespaces --federation-namespace=default --delete-from-api. Installed a namespace-scoped federation contol plane from the OperatorHub. $ oc exec federation-controller-manager-98df8c99-rmncj -- ps -ef|grep controller-manager 1001 1 0 0 06:00 ? 00:00:13 /root/controller-manager --federation-namespace=default --install-crds=false --limited-scope=true --registry-namespace=default -v=5 --logtostderr Join cluster with command: kubefed2 join cluster1 --cluster-context=admin --host-cluster-context=admin --federation-namespace=default --registry-namespace=default --add-to-registry I think for this issue, it's not about namespace sync controller, it's about secret sync controller. Before the secret can be propagation, it need to confirm namespaces federationtypeconfig is exists. Once the sync controller get the namespaces federatedtypeconfig one time, it will not check the namespaces federatedtypeconfig is existing or not? (In reply to Qin Ping from comment #6) > I think for this issue, it's not about namespace sync controller, it's about > secret sync controller. Before the secret can be propagation, it need to > confirm namespaces federationtypeconfig is exists. Once the sync controller > get the namespaces federatedtypeconfig one time, it will not check the > namespaces federatedtypeconfig is existing or not? The sync controller for any namespaced federated type (e.g. secrets) requires the ftc for namespaces to learn the group/version/resource of the FederatedNamespace type so that it can watch it and consider namespace placement when determining the placement for the namespaced federated type. The FTC for namespaces is cached by the ftc controller (responsible for launching sync controllers), and removal of the FTC once cached has no effect. As per a comment in the code, mention of this needs to be included in the documentation: https://github.com/kubernetes-sigs/federation-v2/blob/master/pkg/controller/federatedtypeconfig/controller.go#L346 Yes, controller manager restart can fix this issue. It will make the sync controller cache of ftc to be consistent with the real status. I don't think documentation is sufficient here. The triggering operation to enable this for a namespace is api-driven, there should be a symmetric operation to disable it that works without restarting the controller. I've filed an upstream bug whose resolution should satisfy this bz: https://github.com/kubernetes-sigs/federation-v2/issues/722 Moving back to assigned - there is an upstream issue but work has not started yet. Fixed in version 0.0.10. Verified with:
Federation v2 controller-manager version: version.Info{Version:"v0.0.10", GitCommit:"71d233ede685707df554ef653e06bf7f0229415c", GitTreeState:"clean", BuildDate:"2019-05-06T22:54:46Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
kubefedctl version: version.Info{Version:"v0.0.10-dirty", GitCommit:"71d233ede685707df554ef653e06bf7f0229415c", GitTreeState:"dirty", BuildDate:"2019-05-06T22:30:31Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
|
Description of problem: non-federated namespace scoped objects still can be created by federated object after the namespace API federation disabled Version-Release number of selected component (if applicable): 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"} $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-03-15-063749 True False 3h32m Cluster version is 4.0.0-0.nightly-2019-03-15-063749 How reproducible: 100% Steps to Reproduce: 1. Enable Namespace API federation 2. Eanble Secret API federation 3. Create a federatedsecret object with the following yaml file: $ cat federatedsecret.yaml apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedSecret metadata: name: test-secret namespace: default spec: template: data: A: YWxhIG1hIGtvdGE= type: Opaque placement: clusterNames: - cluster1 overrides: - clusterName: cluster1 clusterOverrides: - path: data value: A: null - path: type value: TestSecret 4. Check the test-secret secret object created successfully. 5. Disable the Namespace API federation. 6. Delete the federatedsecret object test-secret 7. Check the secret object test-secret was deleted too. 8. Recreate the federatedsecret object test-secret 9. Check the secret object is created or not. Actual results: The secret object test-secret was created successfully. $ oc get secret test-secret NAME TYPE DATA AGE test-secret TestSecret 1 6m21s $ oc get federatedtypeconfig NAME AGE secrets 32m services 38m Expected results: No secret object was created. Additional info: