+1. I think there have been a few efforts around the issue of the small tent thing described below, such as the http://www.openstack.org/brand/interop/ effort.
But those profiles seemed centred around standardizing the minimal common denominator parts of what's widely deployed today rather then coming up with a new standard for the pieces that should be required for a next generation iteration of the system. Without the latter, we just keep the same old stuff in the small tent, and no new stuff gets added. Thanks, Kevin ________________________________________ From: Ed Leafe [[email protected]] Sent: Monday, July 18, 2016 9:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all) On Jul 18, 2016, at 12:39 PM, Fox, Kevin M <[email protected]> wrote: > I'm arguing the opposite. It should be a requirement to use the OpenStack > Secret Store. > > Instead, we're trying to make it optional and either reimplementing large > swaths of it in individual projects to make it optional, or skip security all > together. > > If it wasn't optional, then: > * Keystone could rely on it being there for password hashing > * Magnum can rely on it for security. > * lbaas can rely on it > * App developers can rely on it being there > * ... > > Same with Zaqar. It was a requirement then, > * Guest agents of heat, sahara, mangum, trove, etc could all rely on it being > there and wouldn't have to deal with workarounds > * Horizon could rely on it being there for dynamic ui > * App developers can rely on it being there. > > Yes, it seems like more work for an operator to have to install "one more > thing", but the savings it provides by not having to do that "one more thing" > in 7 different projects pays for it. There is a lot to be said for code simplification. When Glance split out of Nova, the knowledge that Glance would be required to be there meant the the code in Nova for interacting with it didn’t have to contain tons of ‘if <glance is installed>: <do this> else <do something else>”. Knowing that that code was unnecessary made writing the interaction much simpler (and less tedious to read). So if we added, say, Barbican as a requirement, all of the other projects that need to handle secrets (a lot of them!) could simply program to the Barbican interface, and be done with it. The discussion of whether project X should be required is a whole ‘nother topic. But I want to emphasize that often the utility of having a standard is grossly underestimated. In this discussion, the issue that seems to be arising is that the Big Tent doesn’t provide for a path for a project to be reconsidered as an OpenStack standard, in the way that Nova and Glance and Swift are. The Small Tent “incubation” process designed to identify which projects were mature enough to be considered “one of us”, when “us” was the group of core projects. This was unnecessarily harsh, and pushed away many worthy efforts. In an attempt to improve this, the definition of “one of us” was broadened so that lots of interesting projects could be part of the community. What I think is causing some confusion (and friction) is that OpenStack needs two “us”s: what projects are part of our ecosystem and build software in the same open way (the Big Tent concept), and which are a fundamental component of the overall OpenStack software, which all other projects can assume are available (the Small Tent concept). To that end, it seems necessary to define a migration path for a project to become required. Of course, most will never need to be required, but I think a case could be made that several projects (Barbican and Zaqar are the obvious ones here) have matured to the point where it makes sense to standardize on them. They are mature, and no other projects have come along to challenge their designs. At some point, it makes sense to stop pretending that there are options, and establish a standard instead. -- Ed Leafe __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
