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