You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If there are multiple resources of same type we use resource discriminators in Dependent Resources to identify the one that is managed by the dependent resource. Usually those discriminate by name, in most use cases. In terms of KubernetesDependentResource the default behavior could be improved in a way, that it would take a desired state and based on the name/namespace of the desired state would select the managed resource from the resources. So there will be no need for resource discriminator in most of the cases.
This is a bit more problematic for external resources, however there the POJO representing the resource could implement an interface that would mark the id(s) of the managed resource
The text was updated successfully, but these errors were encountered:
Where both Config Map Dependents needs a discriminator:
@KubernetesDependent(resourceDiscriminator = ConfigMap1Discriminator.class)
public class MultipleManagedDependentResourceConfigMap1
However that discriminator typically what just does is maps primary resource to name (+namespaces) of the secondary resource. However based on desired state we already could know the name/namespace of the resource to select. So we could just override in this case for KubernetesDependentResource the getSecondaryResource to get the desired and if there are more of a type select one based on the name+namespace of the desired.
If there are multiple resources of same type we use resource discriminators in Dependent Resources to identify the one that is managed by the dependent resource. Usually those discriminate by name, in most use cases. In terms of
KubernetesDependentResource
the default behavior could be improved in a way, that it would take a desired state and based on the name/namespace of the desired state would select the managed resource from the resources. So there will be no need for resource discriminator in most of the cases.This is a bit more problematic for external resources, however there the POJO representing the resource could implement an interface that would mark the id(s) of the managed resource
The text was updated successfully, but these errors were encountered: