Another cluster-api-provider-proxmox

[sp-yduck]

*This is not an issue nor feature request

Hi, did you aware of another cluster-api-provider-proxmox? This cluster-api-provider-proxmox is developed by k8s-proxmox since about 8 month ago. When I started our cluster-api-provider-proxmox project, there are no other cluster-api-proxmox implementation, that is why I decided to develop it by myself.
For now we noticed there is another cluster-api-proxmox developed by @ionos-cloud (Thanks @3deep5me for noticing it to us). Of course it's not efficient nor best way that developing two cluster-api-provider-proxmox differently if there is no reason. So let me ask some question to decide whether we should merge our efforts or not etc.

1. Did you aware of our cluster-api-provider-proxmox when you started (or while developing) CAPMOX project?
2. (if yes for 1.) What is the reason to develop another ionos-cloud/cluster-api-provider-proxmox instead of our k8s-proxmox/cluster-api-provider-proxmox ?
3. What do you think about somehow merging our efforts to one repository ? Are you interested in merging/adopting our efforts to one place ?

fyi some of the diffs of our providers are mentioned here : k8s-proxmox/cluster-api-provider-proxmox#163 (reply in thread)

[wikkyk]

Hi!

No, we were not aware of your project when we started, otherwise we would've contributed to it instead of building our own. We started around the same time.

Indeed there is no need to develop two providers and we're not opposed to merging in principle. However, we do have specific needs and our project fulfills those needs. We have engineers working on it and we have infrastructure built on top that we're not willing to overhaul in order to move to another provider that may or may not satisfy our needs. What we are happy to do is to accept contributions.

Therefore, I propose that we merge features from your project into our project. If you're interested, we can discuss how to go about it in more detail (as I imagine this would move a significant amount of code). We can't dedicate engineer time to the merge but we can offer some assistace and are definitely happy to review PRs etc.

One benefit of this arrangement is that we're listed under https://cluster-api.sigs.k8s.io/reference/providers#infrastructure and are looking to eventually have our project accepted into Kubernetes SIGs. Another is that this code is already running on our infra.

What do you think?

[sp-yduck]

Thank you for the reply !

However, we do have specific needs and our project fulfills those needs. We have engineers working on it and we have infrastructure built on top that we're not willing to overhaul in order to move to another provider that may or may not satisfy our needs. What we are happy to do is to accept contributions.

yup, I understand your team has a reason to develop cluster-api-provider-proxmox I don't ask you to migrate your repo to our repo.

looking to eventually have our project accepted into Kubernetes SIGs

and this is what I am thinking since I started my cluster-api-provider-proxmox project. I also want to adopt/donate proxmox provider to kubernetes-sigs community.

from my side, what I am happy to do is proactively contribute on this project. I want to join the discussion about this project as one of the maintainer. to be honest I want to have some ability to triage/review/approve PRs as a maintainer not just a contributor as what I has been doing in current k8s-proxmox org.

btw let me open a PR for kubernetes/community to create the slack channel dedicated to this proxmox provider so to accelerate our further discussion. do you want to be a owner/primary contact of the channel or is it ok that I will be an owner/primary contact ? (maybe we can change it anytime after the channel creation though)

Thank you and looking forward to work with you :)

[sp-yduck]

fyi: kubernetes/community#7648

[wikkyk]

Please understand that we can't add you as a maintainer just because you're developing a similar project. We would need to see some significant contributions first. Let's start getting some code merged. We can discuss maintainership once there is a substantial amount of your code in the project.

We want to develop this project in the open, we're happy to accept features we're not going to use if they are useful to others.