On 2024-08-16 12:18:03 -0400 (-0400), Theodore Ts'o wrote: > This is a bit out of scope for the Debian Cloud list, but perhaps > those who are frustated that there is a huge variability in what > kernel drivers are needed for some random OpenStack installation > could take that back to the OpenStack developers, More than a few of us are long-time subscribers to this mailing list, participating in this very discussion. There is probably more overlap in our communities than is outwardly apparent (for example, I've been more than a decade now on the staff of the OpenInfra Foundation that represents OpenStack, but I'm also on the board of directors for SPI, and I've been around the Debian community since Y2K, twice as long as OpenStack has existed). While the seeds of OpenStack originated at NASA and RackSpace, the early expansion of its community was in part fueled by participation from people who were also already involved in Debian and Ubuntu. > and see if they can try to drive some standardized, or at least > default, set of virtualized devices. If the goal is to complete > with the hyperscaler cloud providers, the fact that you have no > idea what is needed for a VM image for "some random OpenStack > provider" is a bug, not a feature. It's not that this problem is unknown within the upstream OpenStack community, nor that the idea of interoperability standards is novel. In fact it's been an ongoing struggle dating back to interop discussions circa 2014. Having interoperability standards, portable/independent validation tools and certification-oriented trademark programs did not always result in convincing companies who installed the services to meet those standards. Dropping early misfeatures and removing support for certain kinds of configuration choices has helped a bit, as has taking a stronger stance against "extensible" APIs, but a surprising number of operators actually modify the software itself too (being written in Python is a double-edged sword since it seems to invite a bit of that). There are distributions of OpenStack which attempt to enforce tighter interoperability standards in order to facilitate federation between providers (e.g. Sovereign Cloud Stack), and that has been more successful recently, but those are comparatively new efforts and uptake for this sort of solution tends to be slow across the larger OpenStack install base with much longer histories. > And of course, there's nothing Debian can do, since if we add one > driver, then someone else will very likely pop up with some other > example of some other OpenStack setup that requires some other > driver. Lather. Rinse. Repeat. Yes, or Google Cloud, Hetzner, Dreamhost, vCloud, Proxmox, Apache CloudStack... -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature