In #354 we introduced ownership conflict detection with other ArtifactGenerators for ExternalArtifacts, and in #392 for Namespaces. However, other ArtifactGenerators are not the only objects that could be fighting over our ExternalArtifacts or Namespaces. It could be Flux Kustomizations and HelmReleases, also Flux Operator ResourceSets, external source controllers or anything else.
It's good to detect conflicts at least with other AGs, since we know how AG tracks ownership and poorly-designed .spec.PathPattern values could maybe result in overlaps . But the other things that could be fighting the AG can track ownership in other ways e.g. other labels (Flux/Flux Operator), or maybe ownerReferences (other tools). ExternalArtifact has the standardized .spec.sourceRef, but Namespaces don't.
We should think about the likeliness of conflicts with each tool and decide if we need more observability i.e. detect more types of concurrent managers or not.
I wonder how we can improve this kind of observability also for kustomize-controller, which we know can perfectly be fighting other Kustomizations as well for some objects, or if you think about it also HelmReleases and ResourceSets like here.
In #354 we introduced ownership conflict detection with other ArtifactGenerators for ExternalArtifacts, and in #392 for Namespaces. However, other ArtifactGenerators are not the only objects that could be fighting over our ExternalArtifacts or Namespaces. It could be Flux Kustomizations and HelmReleases, also Flux Operator ResourceSets, external source controllers or anything else.
It's good to detect conflicts at least with other AGs, since we know how AG tracks ownership and poorly-designed
.spec.PathPatternvalues could maybe result in overlaps . But the other things that could be fighting the AG can track ownership in other ways e.g. other labels (Flux/Flux Operator), or maybe ownerReferences (other tools). ExternalArtifact has the standardized.spec.sourceRef, but Namespaces don't.We should think about the likeliness of conflicts with each tool and decide if we need more observability i.e. detect more types of concurrent managers or not.
I wonder how we can improve this kind of observability also for kustomize-controller, which we know can perfectly be fighting other Kustomizations as well for some objects, or if you think about it also HelmReleases and ResourceSets like here.