Hey folks,

Like a few others, I've been lurking on this thread.

I work for an Openstack company, we really appreciate the work and ideas that the community does. So hopefully my opinion comes with that in mind. We have selected a solution that works with magnum, that provides us Openstack APi consistency with ClusterAPI, I am not venturing into which one we have chosen, since I don't think it matters in the intent of this discussion. However, the work to improve Magnum from both these contributing Openstack companies is amazing.

I see no reason to "default" a driver. Include them both, include none of them. Why not make it configurable? Magnum is deployed, no configuration for any specific driver, but the service is ready. I can deploy Cinder with no driver, for example. Why couldn't we have mangum assume a Cinder like approach. We have clouds with Netapp, Pure and Powermax that are in cinder. We also have Dell EMC Unity, which is not and leverages StorOps. In or out of tree isn't bad, in tree is definity more conventiant. Perhaps I am over simplifying it or missing a magnum project context? 

I am not sure that it's constructive to pitch VEXXHOST vs StackHPC, both groups are doing great work, solving issues equally shared by themselves and the community, I also don't think that was the intent of the thread either and efforts in the conservation should avoid it.

It's a useful discussion to be had, expected defaults, downstream user impact etc

Cheers
Michael

On Tue, Feb 27, 2024 at 7:09 PM Mohammed Naser <mnaser@vexxhost.com> wrote:
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  🙂

  • The CAPI Helm driver was built outside governance​, on GitHub, by the parties that are pushing to merge it into Magnum: https://github.com/stackhpc/magnum-capi-helm
  • No efforts was done to try and build both the Helm charts or the drivers under Governance, only today​ patches started to show up to add it.
  • No "open decision" was made about the use of managed topologies or not.  It's in use by commercial products and supported by many upstream in CAPI.  Instead, it is simply "being used because the Helm charts use them".

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