Closed jordiclariana closed 1 month ago
this is an interesting use-case. I am also looking for this solution. Did you found something in the meanwhile?
Hi. No, we just took another approach to our very particular use case (that could be solved without dependsOn
). Is not as pretty, but works for us. I still think this should be addressed.
Hi,
So this is the scenario, I have 2 kustomizations, each one in different namespaces (although I don't think this actually matter), and each one in different shards (that we setup automatically with a mutatingwebhook when a KS is applied/updated in the cluster). These are the snippets of the kustomizations:
Kustomization
#1
:Kustomization
#2
:Whenever Kustomization
#1
tries to reconciliate, we get the error:I was inspecting the code, and the Get for the
checkDependencies
function seems pretty normal, and does not seem like it is limiting what shard should it take the resources from. But then I noticed that in main.go the manager K8s Client is allow cache only for those resources within thewatchSelector
(in this case shards), and I have the feeling that that cache is used always and therefore there are no kustomizations outside its own shard, so can't find the dependency. I think this is fine for most of the cases, but in the case of a dependsOn it does not make sense to me. The dependsOn should not depend on which shard the dependency is in, should it?This issue is between a bug and a feature request, tbh. I will let that up to you to decide, but to me is pretty limiting.
Here's my flux versions: