Hi Mohmamed, all, I would like to contribute a few points from the POV of Magnum PTL and the Magnum Core Team. I think it is important to present my point of view to see how we came to the decisions we did. First of all, let me say we are not merging a 'default' driver for ClusterAPI. In fact, all the work so far has been towards the direction of supporting multiple drivers. A brief sequence of events (that were also captured in StackHPC's blog post): * StackHPC proposed a spec[1] in the beginning of 2022. * Code for CAPI driver was also proposed around the same time[2]. * Work was paused a for a while until 2023. People were busy, Magnum Core Team members moved on. Magnum was leaderless in Zed. I came onboard as PTL in Antelope, midway through this effort. I was unaware of the history and dynamics of this effort, which is important later on. * StackHPC picked up the work on their driver in 2023. It was marked as ready for review in Jun 2023. * VEXXHOST worked on their own driver[3] outside of Magnum. * StackHPC and VEXXHOST announced a talk together about ClusterAPI[4] in Jun 2023 in the Vancouver summit. I had (mistakenly) believed that the driver StackHPC is working on is fine by both VEXXHOST and StackHPC, since they were having a talk together. * Magnum Core was ready to merge StackHPC driver for Bobcat, when jrosser[5] asked out of the blue if this will conflict with VEXXHOST implementation. Realising that is the case, we decided to hold off merging in Bobcat. * This was not an easy decision, given that StackHPC have been putting in effort into getting the driver upstream, and many users have been asking for a Cluster API driver. However, I felt that the most important thing is DO NOT BREAK PRODUCTION implementations, which lead us to holding it off. * Subsequently in the vPTG, we discussed about the state of two drivers. * Magnum Core Team decided that, instead of choosing one driver or another, Magnum should first support multiple drivers. * Improving Magnum driver discovery mechanism became a Caracal goal. There is a spec[6] and an implementation[7]. Which brings us up to current date. --- My view as the PTL is as follow: * I work within OpenStack processes. The community propose changes, the Core Team review and merge (or drop). * StackHPC driver is not the 'default'. It is a driver, albeit the only one, contributed into Magnum code. * We are open to merging more CAPI drivers into Magnum code. (Other users have raised different CAPI ideas, we have encouraged them to send patches) * Magnum is open to supporting out of tree drivers too. * Magnum have put effort into ensuring multiple drivers can co-exist. It is important to us that VEXXHOST (and others) can continue using its driver. * Deployment tools like OpenStack-Ansible can continue to package any driver as an add-on, and use that instead as their default. (there are more thoughts... but these should suffice for now...) --- Mohammed, I will respond to your comments separately, but I may await the community's input first, since the initial email was directed the community. Regards, Jake [1] https://review.opendev.org/c/openstack/magnum-specs/+/824488 [2] https://review.opendev.org/c/openstack/magnum/+/815521 [3] https://github.com/vexxhost/magnum-cluster-api [4] https://www.youtube.com/watch?v=GjSsP4-p-SQ [5] https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-08-30-09.01.lo... [6] https://review.opendev.org/c/openstack/magnum-specs/+/900410 [7] https://review.opendev.org/c/openstack/magnum/+/907297 On 17/2/2024 6:55 am, 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 <https://www.stackhpc.com/magnum-clusterapi.html> [2]: https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770 <https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770>