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.org/message/XAEJWBB6EPZGRWAI3JGS66CAGOZXKDS6/
[3]
https://docs.openstack.org/magnum/latest/contributor/policies.html
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