Confirm k8s 1.14 allows namespaced CRDs to own global crds about hyperconverged-cluster-operator

[rthallisey]

@lveyde, try and deploy the hco on k8s 1.14, then see if network-addons-operator gets deleted when you remove the HCO cr. Slack comment for more details.

[lveyde]

@rthallisey No, as far as I can tell the operator stays, but I actually expected it to be a normal behavior.

The CR is removed normally though (networkaddonsconfigs cluster).

Noticed something else though - after removing and then re-creating the HCO CR I noticed the following:

kubectl describe networkaddonsconfigs cluster
Name: cluster
Namespace:
Labels: app=hyperconverged-cluster
Annotations:
API Version: networkaddonsoperator.network.kubevirt.io/v1alpha1
Kind: NetworkAddonsConfig
Metadata:
Creation Timestamp: 2019-06-17T08:51:35Z
Generation: 1
Owner References:
API Version: hco.kubevirt.io/v1alpha1
Block Owner Deletion: true
Controller: true
Kind: HyperConverged
Name: hyperconverged-cluster
UID: 1c71811f-90dd-11e9-8848-001a4a160205
Resource Version: 1322571
Self Link: /apis/networkaddonsoperator.network.kubevirt.io/v1alpha1/networkaddonsconfigs/cluster
UID: 1c7375a9-90dd-11e9-8848-001a4a160205
Spec:
Kube Mac Pool:
Linux Bridge:
Multus:
Status:
Conditions:
Last Probe Time: 2019-06-17T08:52:11Z
Last Transition Time: 2019-06-17T08:51:35Z
Message: could not apply (/v1, Kind=ServiceAccount) multus/multus: could not create (/v1, Kind=ServiceAccount) multus/multus: serviceaccounts "multus" is forbidden: unable to create new content in namespace multus because it is being terminated
Reason: FailedToApply
Status: True
Type: Failing
Events:

[rthallisey]

@rthallisey No, as far as I can tell the operator stays, but I actually expected it to be a normal behavior.

The normal behavior is that if the HCO cr exists, then all component CRs exist. If the HCO cr doesn't exist, then component crs should not exist.

Looks like the multus namespace was deleted before everything was cleaned up. Is the network-addons-operator responsible for deleting that ns? cc @phoracek

[phoracek]

The owner chain is HyperConverged<-NetworkAddonsConfig<-(all network components). Because of we referenced namespaced HyperConverged from cluster-wide NetworkAddonsConfig, Kubernetes GC immediatelly removed NetworkAddonsConfig. However, network addons operator managed to deploy its resources before removed. Due to that, after HCO recreates NetworkAddonsConfig, it tries to setup its components again, while they are being removed from previous run.

(We have to implement finalizers to block until components are removed.)

[rthallisey]

I think finalizers are part of the problem. I think the other half of this issue is that component operators need to report status on their CRs so the HCO can track their state.

[phoracek]

They are not the cause of the removal, they just cause distraction in logs (terminating ns and all). We do report status on our CR https://github.com/kubevirt/cluster-network-addons-operator/blob/master/pkg/apis/networkaddonsoperator/v1alpha1/networkaddonsconfig_types.go#L37

[rthallisey]

@lveyde can we close this? We're you able to verify?

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kubevirt-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kubevirt-bot]

@kubevirt-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.