Skip to content
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

hetzner-k3s delete does not remove worker pool placement groups #321

Open
shadshar opened this issue Feb 20, 2024 · 4 comments
Open

hetzner-k3s delete does not remove worker pool placement groups #321

shadshar opened this issue Feb 20, 2024 · 4 comments

Comments

@shadshar
Copy link

Hi! When running hetzner-k3s delete, it uses the wrong names when it refers to the names of the worker pool placement groups that were created. On creation, the placement groups get named name-X, where X is a number. That number is not being used during the deletion process, so the placement groups remain and need to be deleted by hand using the cloud console.

So for example, with a config snippet as follows:

worker_node_pools:
- name: small-static-1
  instance_type: cax11
  instance_count: 2
  location: nbg1
  labels:
    - key: purpose
      value: k3s-worker
- name: small-static-2
  instance_type: cax11
  instance_count: 2
  location: nbg1
  labels:
    - key: purpose
      value: k3s-worker

During creation, the output confirms the creation like this:

Creating placement group k3s-playground-masters...done.
Creating placement group k3s-playground-small-static-1-1...done.
Creating placement group k3s-playground-small-static-2-1...done.

And deletion fails like this:

Deleting placement group k3s-playground-masters...done.
Placement group k3s-playground-small-static-1 does not exist, skipping.
Placement group k3s-playground-small-static-2 does not exist, skipping.
@vitobotta
Copy link
Owner

Hi, yeah I'm aware of this and it's on my list of things to fix for the next release. Placement groups don't cost money nor cause any problems so I haven't given this higher priority.

@vitobotta
Copy link
Owner

@peterdieleman
Copy link

peterdieleman commented May 13, 2024

Not sure this is the right place to comment as this is about placement groups, but: I have set up a project and ran create/delete repeatedly (very cool stuff :) ). I also went through the README and found:

NOTE: at the moment instances created by the cluster autoscaler, as well as load balancers and persistent volumes created by deploying your applications must be deleted manually. This may be addressed in a future release.

I would actually say that not deleting the LB can be quite a nice behaviour. When combining it together with something like Cloudflare DNS it avoids reconfiguring the IP in CF. I guess the default should be to delete it as people may run into unexpected costs, but perhaps this behaviour (not deleting the LB) could be supported through a flag.

@vitobotta
Copy link
Owner

Not sure this is the right place to comment as this is about placement groups, but: I have set up a project and ran create/delete repeatedly (very cool stuff :) ). I also went through the README and found:

NOTE: at the moment instances created by the cluster autoscaler, as well as load balancers and persistent volumes created by deploying your applications must be deleted manually. This may be addressed in a future release.

I would actually say that not deleting the LB can be quite a nice behaviour. When combining it together with something like Cloudflare DNS it avoids reconfiguring the IP in CF. I guess the default should be to delete it as people may run into unexpected costs, but perhaps this behaviour (not deleting the LB) could be supported through a flag.

The README doesn't expand on this but the idea is to ask the user for a confirmation before deleting load balancers and persistent volumes, so you can choose :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants