-
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
[YW] [openshift] Add namespace specifier in UI for k8s provider #6702
Labels
Milestone
Comments
iSignal
added
area/kubernetes
Kubernetes support and deployments.
area/platform
Yugabyte Platform
labels
Dec 18, 2020
bhavin192
added a commit
to bhavin192/yugabyte-db
that referenced
this issue
Feb 5, 2021
These set of changes introduces a new key KUBENAMESPACE in the AZ config. Useful for the situations where the platform software does not have access to create, list or delete namespaces in the cluster. When KUBENAMESPACE is present in the AZ config, the deployment in that AZ in done in that namespace only. Platform does not try to create namespace when creating the universe. It does not delete the namespace when destroying the universe. Makes changes to the kubectl, helm commands from KubernetesManager.java to use namespace as well as nodePrefix. The value of nodePrefix and namespace can be same if the AZ does not have KUBENAMESPACE. DestroyKubernetesUniverse now always deletes the volumes before deleting the namespace and uses release label selector to make sure the volumes being deleted are of the universe being destroyed. Deleting a failed universe was deleting volumes of an existing one. Use kubectl apply for the pull secret. This makes sure that we don't fail if the namespace already has a pull secret in it. This will just update the existing pull secret. [Platform UI] Add option to specify namespace in the AZ modal - Adds the given value as KUBENAMESPACE in the zone config. Fixes yugabyte#6551 Fixes yugabyte#6702 Test plan: The following tests have been done on OpenShift, where the Kubernetes ServiceAccount does not have access to create namespaces. - Created a single AZ provider with KUBENAMESPACE set. - Created a universe with it, tried GFlags update, database backup, universe edit operations, these pass as expected. - Destroyed the same universe. - Performed same set of operations with a multi AZ provider and a universe. Signed-off-by: Bhavin Gandhi <[email protected]>
bhavin192
added a commit
that referenced
this issue
Feb 8, 2021
…6807) These set of changes introduces a new key KUBENAMESPACE in the AZ config. Useful for the situations where the platform software does not have access to create, list or delete namespaces in the cluster. When KUBENAMESPACE is present in the AZ config, the deployment in that AZ in done in that namespace only. Platform does not try to create namespace when creating the universe. It does not delete the namespace when destroying the universe. Makes changes to the kubectl, helm commands from KubernetesManager.java to use namespace as well as nodePrefix. The value of nodePrefix and namespace can be same if the AZ does not have KUBENAMESPACE. DestroyKubernetesUniverse now always deletes the volumes before deleting the namespace and uses release label selector to make sure the volumes being deleted are of the universe being destroyed. Deleting a failed universe was deleting volumes of an existing one. Use kubectl apply for the pull secret. This makes sure that we don't fail if the namespace already has a pull secret in it. This will just update the existing pull secret. [Platform UI] Add option to specify namespace in the AZ modal - Adds the given value as KUBENAMESPACE in the zone config. Fixes #6551 Fixes #6702 Test plan: The following tests have been done on OpenShift, where the Kubernetes ServiceAccount does not have access to create namespaces. - Created a single AZ provider with KUBENAMESPACE set. - Created a universe with it, tried GFlags update, database backup, universe edit operations, these pass as expected. - Destroyed the same universe. - Performed same set of operations with a multi AZ provider and a universe. Signed-off-by: Bhavin Gandhi <[email protected]>
polarweasel
pushed a commit
to lizayugabyte/yugabyte-db
that referenced
this issue
Mar 9, 2021
…ugabyte#6807) These set of changes introduces a new key KUBENAMESPACE in the AZ config. Useful for the situations where the platform software does not have access to create, list or delete namespaces in the cluster. When KUBENAMESPACE is present in the AZ config, the deployment in that AZ in done in that namespace only. Platform does not try to create namespace when creating the universe. It does not delete the namespace when destroying the universe. Makes changes to the kubectl, helm commands from KubernetesManager.java to use namespace as well as nodePrefix. The value of nodePrefix and namespace can be same if the AZ does not have KUBENAMESPACE. DestroyKubernetesUniverse now always deletes the volumes before deleting the namespace and uses release label selector to make sure the volumes being deleted are of the universe being destroyed. Deleting a failed universe was deleting volumes of an existing one. Use kubectl apply for the pull secret. This makes sure that we don't fail if the namespace already has a pull secret in it. This will just update the existing pull secret. [Platform UI] Add option to specify namespace in the AZ modal - Adds the given value as KUBENAMESPACE in the zone config. Fixes yugabyte#6551 Fixes yugabyte#6702 Test plan: The following tests have been done on OpenShift, where the Kubernetes ServiceAccount does not have access to create namespaces. - Created a single AZ provider with KUBENAMESPACE set. - Created a universe with it, tried GFlags update, database backup, universe edit operations, these pass as expected. - Destroyed the same universe. - Performed same set of operations with a multi AZ provider and a universe. Signed-off-by: Bhavin Gandhi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
UI side of #6551
The text was updated successfully, but these errors were encountered: