Hello Mohammed - I am surprised at your reaction to this. Broadly speaking this driver is a subject that has been undergoing the open design process since the Yoga PTG, and i do agree with Dmitriy that the consensus in the last PTG was that there is benefit to an in-tree driver. Development does appear to be following a course. The October 2023 PTG etherpad also begins with notes that the CAPI Helm driver cannot be merged until Magnum is refactored to accommodate it alongside the Vexxhost driver without conflict. There has been a delay of at least two cycles to support that. In short I don't think there are negative user impacts for Vexxhost's driver by this driver's introduction. The Vexxhost team has benefited from a rapid pace of development by doing so outside of OpenStack's governance and the four opens. Is it fair to obstruct the delivery of a driver that has attempted to follow those guidelines? Best wishes, Stig
On 16 Feb 2024, at 20:45, Mohammed Naser <mnaser@vexxhost.com> wrote:
Hi Dmitriy,
I am really glad you're taking the time to respond – any feedback is greatly appreciated.
With regards to the service being "functional" out of the box. The way that I see this, is that this is a decision that needs to be taken by the operator: what is the backend that I will be using? I see this in the same way that "Cinder" out of the box has no default: you need a storage backend. While we (I think?) mostly test with LVM in the CI (and some Ceph CI and what not). Deployment tools can be a bit "nuanced" in that they may support one backend over another out of the box, but for something like Cinder, you need to decide what you're using.
With regards to those "drivers" not being usable or not being able to have "influence". I can't speak on any of the other ones, but on our side, I'm hoping we have enough "good karma" with the community knowing that we're welcome at working together with folks. I can't speak on behalf of others but we've had contributions from countless organizations that have added features such as Flatcar, support for HTTP proxies, and many other changes that we've merged with no issues from those organizations.
I don't entirely agree on the Cinder aspect, since Cinder third party CI mostly exists because OpenDev doesn't want to own a rack with 40 different types of storage systems.. but instead the 'built-in' CI works for the open source software backends (say, Ceph or LVM) and then third party is needed for those needing physical access to the machines. I think a CI that tests drivers would be productive if there's a "no built-in approach".
In this case, I do understand the concern that it seems to feel like a single organization driven project -- however, we've had contributors from all over – https://github.com/vexxhost/magnum-cluster-api/graphs/contributors – and the way I would see this is .. how is this different from any other OpenStack dependency if it was an "add-on". Silly example, `confluent-kafka` is a dependency of oslo.messaging if you're using Kafka as a backend. There's probably many other examples of other libraries that exist as OpenStack dependencies that might not even be single organization driven, but single "individual" driven...
I can't speak on the rest, but we've been asked to license the code as Apache 2.0 – which it has been .. just like any other OpenStack dependency. Magnum is really good at being a standard API that implements many backends, and the user should choose what backend they want. In the same way that Cinder is same way allowing multiple backends, and letting the user pick what they want.
Once again though, I really appreciate your thoughts on this and getting the conversation going, Dmitriy.
Thanks, Mohammed
From: Dmitriy Rabotyagov <noonedeadpunk@gmail.com> Sent: February 16, 2024 3:24 PM Cc: OpenStack Discuss <openstack-discuss@lists.openstack.org> Subject: Re: [magnum] Dropping default Cluster API driver
Hey,
I'm totally not to decide here, but just want to repeat my personal subjective opinion on the topic.
From what I do recall from the last PTG, which I was part of, more opinions were inclined towards having some default driver. Otherwise, service is not functional on it's own and must rely heavily on individual organisations to keep support for their drivers without any way of influencing them. In turn, organisations are able to dictate how project should be developed, what changes they are able or not able to do.
I'd say, this suggestion is similar to drop native driver from Octavia or Cinder and just assume that individual organisations will keep support of their drivers. With that, these service doing just fine with having some default drivers, and some third-party. Also adding third party CI to the service is not huge issue, to ensure that your driver integrates nicely.
With that said, OpenStack-Ansible right now is merging support and CI testing of Vexxhost driver. I also personally highly likely will be using it in future magnum deployments.
But I truly believe, that service without any driver is doomed to failure sooner then later. If we look at literally anything - automation tool, programming language, service - they all have some core libraries, and can be used, in a way, "out of the box". And here suggestion is to make service and all it's users to put faith in an organisation providing support for the driver, which may be quite tough sell for some highly regulated environments.
In case Magnum is going the road of not having any "out-of-the-box" implementation, i actually wonder if it should stay under OpenStack namespace rather then X, for instance, since it's not self-contained and heavily depends on third party, which might be licensed in a completely different way, as well as change their licensing with time which also put users at tough spot.
But dunno, as I said, this is my very subjective view, and I really can be wrong in this. Also not trying to push any party to any conclusion. So treat it as - one operator voice out of many.
On Fri, Feb 16, 2024, 21:02 Mohammed Naser <mnaser@vexxhost.com <mailto:mnaser@vexxhost.com>> 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