-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
EnqueueRequestForOwner creates reconcile.Request with wrong data #214
Comments
/kind bug So, we definitely need to handle non-namespaced objects, and namespaces themselves (we can use discovery info for that) |
/priority important-soon |
Owner references in Kubernetes are:
This is an intentional policy decision upstream. There's some prior conversation about it in the context of garbage collection. Bottom line is I think EnqueueRequestForOwner is behaving as expected since, per the upstream design, it's safe/necessary to assume that the owner and owned object are both namespace-scoped and in the same namespace. |
Intentional policy decisions notwithstanding, didn't kubernetes/kubernetes#57211 add support for garbage collecting dependents of cluster-scoped objects? That seems like practical acknowledgment that the cluster-scoped owner scenario is valid, or at least common enough that it should be supported. |
I think there are two orthogonal things to consider:
It's possible to get the garbage collector to process cluster scoped resources because of behavior that's considered buggy. However, the semantics of an The garbage collector's behavior around
I think this attributes a motive to people who made the GC changes, but as one of those people, I think I can say it wasn't because of either widespread demand or a desire to promote the behavior. That the garbage collector currently does something useful with undefined I think the only way it makes sense to propagate the garbage collector's behavior around cluster scoped relationships is to change |
ownerRefs to cluster-scoped objects are allowed: ownerRefs from cluster-scoped objects to namespaced objects are not supported. |
Oh, hi there! 😀 👋
Hey, that's new! How does Kubernetes versioning apply with a purely semantic change like this? All this said, I think the original request in this PR was about inter-namespace dependencies, which still aren't supported (right?) |
Yes! The request to "fix" the behaviour would be:
|
I think my earlier diatribe accidentally applies more clearly to your request — those two types of relationships are explicitly disallowed and so I still think the change would have to originate with |
That's true. I was just curious about the behaviour of the Do you know if there are plans to implement the |
To avoid hijacking this thread with a different request, I opened #228 for the specific case of cluster-scoped owners. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
I think this can be closed -- the sub-issue was fixed, and the other issue here is not possible with owner refs. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
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. |
I might be wrong but I find the following behaviour strange.
Lets define the following:
I'm watching for Object2 using
EnqueueRequestForObject
and Object1 withEnqueueRequestForOwner
. Object1 is created during the reconcile of Object2. There is a reconcile function for objects of type Object2.In this line it is defined that the Namespace of the Object that should be reconciled is the Namespace of Object1. This means that if the Object2 is in a different Namespace than Object1 or Object1 has no Namespace at all (Object1 Type is i.e. Namespace) the Reconciler will not find the Object2.
In my case, I'm building an operator that will create Namespaces. If I delete the namespace, then the reconciler cannot find the CR which is the owner of the Namespace and the Namespace will never be recreated.
I could tweak the code to check for the CR in a specific Namespace if the
reconcile.Request
doesn't contain any Namespace but I would like to know if the behaviour that I'm facing is the correct one.The text was updated successfully, but these errors were encountered: