Hi Mohammed, thanks for raising the discussion. I've been reading with interest the ideas raised here. Firstly, I think support for Cluster API is the way forward for Magnum Kubernetes COE. The features and community effort around it are greater than Magnum can currently provide. It would be easier if there was one driver and we were all contributing to that instead of developing parallel features, but perhaps the drivers will end up in a fairly stable state over time as most change will be concentrated in the Cluster API and kubeadm codebases between Kubernetes versions. My company is actively using the StackHPC magnum-capi-helm driver, and contributing to the development (firstly, in Gerrit patches on top of the large chain, then in Github when it was held merging and moved location). Magnum in the past supported several COEs and drivers. Now, the Magnum project has only one maintained driver; the Fedora CoreOS Heat driver[1]. Once the project has documentation and most folk have moved to some CAPI driver, I'm not sure how long term this will be maintained; especially with in place upgrades removed and if Heat deprecate SoftwareDeployment[2]. That leaves the Magnum project with a bit of a choice: 1. Figure out how the project continues to keep stability with no in-tree drivers. 2. Merge one or more Cluster API drivers. As a Magnum Core member, I'm reviewing and proposing changes with the mindset that we want to actively enable out-of-tree drivers and ensuring these drivers can provide the features that matter to them (eg. CNIs, control plane resizing). It's important to me we do not introduce changes that break out-of-tree drivers or lock users into one driver with no path to migrating to another. However, I'm not sure I'm in support of asking another driver to be relocated and not contributed when it wants to be. That seems like the contentious bit. I don't think that's in line with the Magnum Development Policies[3], specifically the Rule of Thumb and How We Make Decisions sections. Having drivers in another Opendev repo is an option, this seems like the compromise that would suit most. It will need folk to lead that effort and keep the Magnum project stable with (eventually, as I see it) no production-ready in-tree drivers once Heat Fedora CoreOS is unmaintained. I do support the idea from the vPTG of adding documentation to Magnum to help with the decision of which driver to use, including out of tree drivers. A feature compatibility matrix and links to these drivers' documentation would be helpful to this end. Perhaps that's a level playing field enough, as drivers can be disabled or ignored if they aren't required (See: the other drivers removed recently). regards, Dale Smith [1] https://docs.openstack.org/magnum/latest/user/index.html#cluster-drivers [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [3] https://docs.openstack.org/magnum/latest/contributor/policies.html On 17/02/24 08:55, Mohammed Naser wrote:
Hi everyone,
It seems that based on a recent post that I saw on the Twitter-sphere[1], it seems that the Magnum team has decided to move forward with setting a default driver for the Cluster API. I don't agree with this.
Unfortunately, we don't have much recordings of our PTG conversations, and since the notes on the PTG are pretty light[2], I don't see any details of that. I don't see why we should be merging a native Cluster API driver and not allowing the operators and deployment tools decide which one they want to support.
Personally, I think that the Helm driver should be built in a separate repository and then installed by the user as a Python package once they understand what are the backends and their options, as opposed to shipping one out of the box with far less features.
We already have successful users which are using our implementation in production that have also posted blogs and shared their experience, we'd be doing them a disservice by now announcing a 'native' built-in driver.
Can the decision be changed so that there is no built-in driver, and you must decide to install one yourself? Also, I would be really happy to hear feedback from users of the driver for their comments here.
Thanks, Mohmamed
[1]: https://www.stackhpc.com/magnum-clusterapi.html [2]: https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770