Rename existing proxmox provider to ionos-proxmox and add new proxmox provider

[sp-yduck]

What would you like to be added (User Story)?

rename recently added proxmox provider to ionos-proxmox
and add new proxmox provider https://github.com/k8s-proxmox/cluster-api-provider-proxmox

Detailed Description

There is 2 different proxmox provider implementation right now. one is k8s-proxmox/cluster-api-provider-proxmox and the other is ionos-cloud/cluster-api-provider-proxmox.
We (k8s-proxmox) also want to add our provider to clusterctl as proxmox.

There are some reason we want to add our provider as proxmox. Our proxmox provider (CAPPX) has been developed since 8 month ago and more mature than their proxmox provider (CAPMOX). CAPPX has more feature, community popularity than CAPMOX sine CAPMOX is opened just 2 weeks ago. Also their CAPMOX is focused on their (ionos-cloud) business requirement/needs. As a community perspective there is no reason to choose their CAPMOX as proxmox provider.

In the end we CAPPX and CAPMOX may be merged into one place but certainly it will take long time. They (ionos-cloud) has specific requirement (as their business requirement) for proxmox provider, so it's difficult to switch to CAPPX as CAPMOX perspective. We CAPPX has bigger community/code bases and side projects (cloud-controller-manager for proxmox), so it's also difficult to migrate our efforts to their CAPMOX repo.

So until we get merged into one place we CAPPX also want to register our provider to clusterctl as proxmox so that community can choose our CAPPX for first choice of proxmox provider implementation.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[chrischdi]

Would be great to also get @mcbenjemaa 's feedback!

[mcbenjemaa]

    Hey,

we're confused.

Why would you rename stuff?

What you mentioned is not exactly true.

The IONOS proxmox provider was under development since July and we needed internal approval before open sourcing it. We just didn't release our internal (archived) development repository, as it's history contains internals. But as said, we started development in July.

Our Proxmox provider has a lot of features, which make it more suitable for production:

• Static IP allocation via IPAM (they support DHCP instead, something we would like to implement as well at a later point - contributions welcome)

• Creating VMs with multiple network interfaces

• Support for dual-stack and/or IPv6 deployments

• Supporting CRS to auto install CNI plugin

• Automatic VM scheduling on multiple nodes based on resource allocation.

• Multiple flavors for different setups

• Additionally, especially when it comes to productive / business environments, our Provider supports token based authentication and is therefore much more secure for general use.

Regarding CCM: We decided to not initialize the nodes by a CCM, but via cloud-init.

Final thoughts: 

The Proxmox provider by IONOS has more maintainers (6) and contributors. We started building our version of the proxmox cluster-api provider, because we had a need for it at that time nothing showed up in search results. That's also why we open sourced it for the benefit of the community and are hoping to hand it over eventually.. But instead we get dragged into a "ours is better" discussion..

Also, during development of this we also contributed the proxmox provider to the image-builder project.

We are open for any discussions and feedbacks.

We are against renaming.
As we might endup in future of having many of this kind of renaming.

That would mean we could have a strange stuff in the config:

something-aws, something-azure ...

The clusterctl config must remain clean.

But, we suggest adding a note in the quickstart to mention that:

"If you prefer using the other provider please take a look."

[sp-yduck]

we're confused.

Yeah this is exactly what we are feeling actually. We are confused. Since we have been developed proxmox provider fully open and with community for a long time and were getting bigger/popularity. Suddenly another proxmox provider came out and snitched the name of proxmox. I understand you have some reason to wait until opening the repository, However you should have noticed our project and developed together. It's not our fault at all. It's your fault I would say. I can not understand why we can not have proxmox name but you can. Because just applied the PR earlier? It's very rude to the community isn't it ? Now you noticed there is another proxmox provider being developed for a long time. You can revise your request if you really think about the benefit of the community. It's time to back to what should be. The name of proxmox is not yours at first. That's it. What you are doing is just snitching the community's long time efforts due to your lack of investigation. I am not saying that do not start another project similar to ours but I am saying do not snitch our long time efforts and the project and the name.

We are against renaming.
As we might endup in future of having many of this kind of renaming.

It's same to us... Do not try to justify the reason of against renaming which is totally caused your lack of investigation.

[fabriziopandini]

Hey folks, if I can give my humble two cents, you should look at this as big opportunity to join forces in maintaining a provider, because this is a marathon and everyone can benefit from some help when soon or later fatigue will kick in.

As a CAPI project, we always have been more than happy to give visibility to all the providers no matter if they are developed under the SIG umbrella or not, but I don’t feel I’m entitled to enter into discussion about projects developed outside of the SIG scope.

I will bring this up with the other maintainers during today's office hours, and together with them consider what options we have before coming back to this thread, but of all the options, the best one probably will be if you all figure out together a way forward.

I'm I right in assuming that the changes in clusterctl being discussed here are not part of any release yet?

[mcbenjemaa]

They have been selected into the v1.6 release.

[sp-yduck]

@fabriziopandini Thank you for enlightening me. I think I was too tired as I felt like all my long time efforts on the project were being wasted.
For other options I can think of now are

• make clusterctl support same name provider
  I'm not sure how much difficult it is.

• just use another name for provider name
  when I started the project, there was another candidate for the name and maybe we can compromise; pve (stands for ProxmoxVirtualEnvironment)

[fabriziopandini]

They have been selected for the v1.6 release.

yes, I saw this, but if I'm not wrong they are not part of a release yet

noted

[wikkyk]

Indeed, we developed CAPMOX as a solution to our business needs but we open-sourced it in the hope that it might be useful to others. As such, we support developing in the open. We welcome contributions and feedback and are delighted to be able to support the community. We're not quite 'focused' on our own business needs, we just couldn't possibly know everyone else's use cases and this typically is where the open source community steps in and extends the project.

We don't want to get into a contest here. I don't know whose project is more complete or has more usage. CAPMOX is deployed in our infra and we're using it actively to build products, so it's seeing some usage and it's definitely complete enough to actually be useful.

As for joining forces, we're open to cooperation. We propose merging features from CAPPX and developing the resulting project further in the open. The project would continue benefitting from dedicated resources and would end up with a larger community. It would be a shame to waste the anybody's efforts.

[fabriziopandini]

Great work folks in sorting this out!
Appreaciated