Open Stack

Excerpts from Ed Leafe's message of 2016-07-18 21:59:44 -0700:
> On Jul 18, 2016, at 12:39 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> 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.

This came up during the discussion of co-gating that was part of
the big tent implementation, IIRC we settled on the policy that
teams are encouraged to rely on the projects produced by other
community teams *when they are comfortable adding co-gating to
ensure continued compatibility*, but there was no rule that such
relationships must be put in place because we don't want projects
to depend on new, potentially unstable, services before they are
ready.

So, the nova and glance teams are currently comfortable co-gating,
and nova can therefore depend on glance being present. Projects
handling secrets would need to negotiate similar functional test
co-gating relationships with the barbican team. At that point it
would be safe to have barbican as a required dependency of those
other projects.

Doug


> 
> 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
>