SovereignCloudStack / SovereignCloudStack/cluster-stacks

:bug: Workload cluster can't be deleted when itself has service with type LoadBalancer running

Open
#178 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Container
Dominant language
Python
Stars
13
Forks
8
PR merge metrics
No merged PRs in 30d

Description

/kind bug
The deleting status stuck in Deleting, resources needs to be removed by hand from openstack.

What steps did you take and what happened:
Create a workload cluster, get the kubeconfig, create a service with type LoadBalancer in it.
It uses the same router and network as the kube-apiserver, while the management cluster doesn't know anything of the other LoadBalancer, so it can't delete the router because it is in use.

What did you expect to happen:
Delete workload cluster including all LoadBalancers which belongs to that or at least ignore them and delete the workload cluster properly.

Anything else you would like to add:
It can probably be separated using the OCCM cloud config

Environment:

  • Kubernetes version: (use kubectl version)
  • OS (e.g. from /etc/os-release):

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported flow: create a workload cluster, obtain its kubeconfig, create a LoadBalancer service, and delete the cluster. Review workload-cluster deletion and the OCCM cloud configuration to determine how the shared router and network are handled. Done means the cluster deletion completes without manual OpenStack cleanup, while the LoadBalancer resources are either removed or safely ignored.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes, python
Domain
cloud, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.