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
How does Kubeplus handle the case where there are two Kinds and we try to create app instances with the same name for both the Kinds?
Given that we are using app name as the name of application's namespace, do we have to enforce unique app name in a cluster constraint?
Note that just checking if namespace with the provided app name exists or not is not enough. This is because if the NS exists, we treat customer action as an update operation. We have to check the meta.helm.sh/release-name annotation. Get the Kind name from the annotation. If the Kind name is different than the Kind name in app instance, then we can conclude that an app instance cannot be created with that name as an app instance with that name already exists in the cluster, and it belongs to a different Kind than the Kind provided in the app yaml.
The text was updated successfully, but these errors were encountered:
Another way to handle this issue can be to change the logic of naming namespaces to use "kindname-appname" as the namespace name than just "appname". In fact, this will be also line up with how we are naming the underlying helm releases.
If we go with this change then everywhere where we are using the Namespace name as the app name, such as in kubectl plugins, we will have to update the code.
How does Kubeplus handle the case where there are two Kinds and we try to create app instances with the same name for both the Kinds?
Given that we are using app name as the name of application's namespace, do we have to enforce unique app name in a cluster constraint?
Note that just checking if namespace with the provided app name exists or not is not enough. This is because if the NS exists, we treat customer action as an update operation. We have to check the meta.helm.sh/release-name annotation. Get the Kind name from the annotation. If the Kind name is different than the Kind name in app instance, then we can conclude that an app instance cannot be created with that name as an app instance with that name already exists in the cluster, and it belongs to a different Kind than the Kind provided in the app yaml.
The text was updated successfully, but these errors were encountered: