W dniu czw., 29.02.2024 o 07:53 Dmitriy Rabotyagov <noonedeadpunk@gmail.com> napisał(a):>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?Making driver configurable was always implied. There was never a question if to allow external drivers or not, as well as leave to users to define which one to use (alike to cinder).The question was more or less only about - if have in-tree driver or do have only external ones.Magnum team did quite good job to ensure our of tree drivers are supported at a good level despite all this discussion.> That said I think OpenStack projects should do their best to> ensure they avoid writing API frontends that aren't much more> than that. History has shown us that empty APIs without drivers> are not testable and are bad for users.While I didn't know the history, I do fully agree with that, and basically why I was supporting idea to have *some* in-tree driver, despite how good or bad it is.There is a driver, the Heat based driver - it’s not deprecated yet, and Magnum community understand the significance of an in-tree reference driver - it just doesn’t need to be one of the two CAPI drivers (maybe a simplified version of current driver that would allow users to stand up CAPI management cluster).That is going to be discussed again at the PTG surely.However yesterday on the Magnum meeting [1] it was decided to place StackHPC driver to a separate repo, meaning not having any in-tree driver and making Magnum a useful API reference project more or less.Patches to create a repo and add it to the governance were already created. [2]So probably no reason for any further discussions on this topic...The decision was made, to go forward out of this situation - instead of continuing endless discussion between two parties that would probably never lead to a consensus.This way we can have CI in Magnum repo for at least one CAPI driver.It doesn’t mean Magnum will never have an in-tree CAPI driver - but I feel it’s not going to happen soon.On Wed, Feb 28, 2024, 23:16 Clark Boylan <cboylan@sapwetik.org> wrote:On Wed, Feb 28, 2024, at 1:42 PM, Michael Knox wrote:
> 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 too have been lurking and haven't chimed in as I am not a magnum dev or user. That said there is some "fun" openstack history that is worth calling out in the context of these questions. Once upon a time Glance implemented v2 of its API. This new API version implemented a task system that was expected to be used for image upload/import. Rather than direct byte transfer you submitted a task request, the task did the work in the background, and eventually it completed and your image was available for use. The intentions behind this were good; the glance team was trying to solve problems that existed with the old upload process.
There was a major flaw though: there was no implementation of a tasks backend (at least upstream or open source from third parties) for image uploads via tasks and the API was too high level to provide a consistent user experience from one cloud to another. This wiki doc is about as good as the docs got: https://wiki.openstack.org/wiki/Glance-tasks-api. There was a schema to do things within glance, but implementation and consistency between clouds was left to the operator.
Why was this bad? OpenStack couldn't test a major piece of functionality because implementing it was left to others. No OpenStack users knew how to use this system until Monty figured it out somehow and wrote shade. I think it is important for every OpenStack project to have at least one valid working upstream driver. This provides the ability to more easily run tests and understand how the service APIs are intended to function. The lines get blurry when you look at what goes in OpenStack and what doesn't, and it sounds like all of the options being discussed here are open source and can be used for upstream testing and so on.
That said I think OpenStack projects should do their best to ensure they avoid writing API frontends that aren't much more than that. History has shown us that empty APIs without drivers are not testable and are bad for users.
>
> 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
>