Open jawabuu opened 3 years ago
Hi @jawabuu
Thanks for the suggestion! This sounds reasonable. Unfortunately I don't have any time left to commit to this project right now, so I can't say if/when this would be done :disappointed:
I would gladly look over PRs though!
Hey @costela Thank you for getting back to me. I would like to take a stab at it but you should probably advise with an overview of how you would prefer it refactored. Just a general one.
Would also appreciate if you can share how you mock/test with a cloud provider outside a cluster if possible.
Hi @jawabuu, sorry for the late reply.
I'd say we'd need some common interface
that wraps the few opperations we use in the individual cloud SDKs. So hcloudClienter
would probably become something like cloudClienter
and we'd have different implementations of it for each cloud provider.
As for testing, hcloudClienter
basically exists to allow better testing, but I never got around to actually writing useful tests :shrug:
This would be nice, but for vultr is completely unneccessary, vultr already does BGP which metallb supports natively, or is there some reason you dont want to do BGP with vultr?
Hey @costela I would like to propose extending ip-floater to support other clouds. This could be done gradually based on provider support and ease of implementation. We could probably start with the following clouds;
Digitalocean could provide the quickest POC as it's API is most similar to Hetzner's. Based on code structure, I think most changes will be made here https://github.com/costela/hcloud-ip-floater/tree/master/internal/fipcontroller with an additional provider flag (default: hcloud) DigitalCean, Linode & Vultr also use an api_token similar to OVH cloud.