-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Rename existing proxmox provider to ionos-proxmox and add new proxmox provider #9869
Comments
This issue is currently awaiting triage. If CAPI contributors determines this is a relevant issue, they will accept it by applying the The 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. |
Would be great to also get @mcbenjemaa 's feedback! |
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:
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. 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." |
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
It's same to us... Do not try to justify the reason of against renaming which is totally caused your lack of investigation. |
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? |
They have been selected into the v1.6 release. |
@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.
|
noted |
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. |
Great work folks in sorting this out! |
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.
The text was updated successfully, but these errors were encountered: