Personally, I have no patience in continuing to chase this subject, so I'll just sign off on this and mute this thread for my personal sanity  🙂


At the end of the day, we're importing an implementation that was built outside​ governance, with dependencies outside our governance​, and the whole subject of discussion wasn't on the implementation, but "which one gets imported by default".   I will ask respectfully not to say this was built in our four open with governance.

The driver had every opportunity to live out of tree (inside governance), be developed and then merged after deciding the path forward – but instead, we're speed running straight into merging to the main project.

I've repeatedly​ mentioned that if we see active participation and see that it makes sense to bring it to a neutral ground, we'll be happy to.  However, since the only contributions have been taking parts of our code for the other driver & requesting a relicense to do that, we don't see why we'd change our entire workflow to accommodate when we're the (unfortunately) the primary maintainers.

We'll continue to maintain our Apache 2.0 licensed out of tree driver for those who want to continue to use it and document the differences for those users such as creating isolated clusters.  We hope that there will be real​ open development and participation from those who are interested in contributing to it. 
From: Stig Telfer <stig@telfer.org>
Sent: February 27, 2024 6:44 PM
To: Mohammed Naser <mnaser@vexxhost.com>
Cc: Thomas Goirand <zigo@debian.org>; openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org>
Subject: Re: [magnum] Dropping default Cluster API driver
 
[You don't often get email from stig@telfer.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Mohammed,

I would prefer to focus on making a positive case rather than have to defend our contribution in this fashion.  There is another side to the story you are presenting and I will make it inline.

> On 27 Feb 2024, at 15:47, Mohammed Naser <mnaser@vexxhost.com> wrote:
>
> Hi Thomas,
>
> The issue is that the StackHPC has gone into a fundamentally different path: using Helm charts with manual resources.  We've taken the more modern path which will be the future of CAPI which is managed topologies.

The Helm charts our driver uses have been used in production since 2021, and have been continuously supported and developed over that time.

ClusterClass is a promising technology and merits investigation into adding to the CAPI Helm charts - particularly once it is out of "experimental (alpha)" status.

> I have not seen an interest in them wanting to explore our path, because they use these Helm charts in their own product (Azimuth?) and want to use them for that AND th Magnum driver.  We have no interest in using plain Helm charts because we're heavily invested into managed topologies feature which has been in use for many months now.

The CAPI Helm charts are a modular component and this is to their advantage.  Besides the Magnum CAPI Helm driver they are used in Azimuth deployments, and also in other significant projects.  A broader user community brings greater coverage and activity.

Once the interoperability issues are resolved, the CAPI Helm charts are proposed to be added and maintained alongside the driver, under Magnum project governance.

Operators have the advantage of being able to supply their own repo of differentiating or extended Helm charts.

> So it's a matter of choice/selection/decision, and I believe we have the better option here.

As I understand it, you are not objecting to merging the driver.

Are you claiming that the Magnum project is best served by defaulting to start with no driver loaded?  Or the Heat driver, perhaps?

> tl;dr: we've taken two approaches, ours is more modern and compatible with future state of things.  the other driver relies on basic Helm charts that were built for some other use case and being retrofitted for this case.

tl;dr: the approaches have significant but not fundamental differences, except in governance.  The advantage of Helm is that it provides a reusable and pluggable way to template resources, which could (once graduated) include ClusterClass resources.

Thanks
Stig

> Thanks
> Mohammed