Open Stack

Sean Dague wrote:
> The only thing we've really decided is non Optional for OpenStack is
> keystone up until this point.

Thanks for starting that discussion!

Beyond Keystone, I tend to include the message queue and the database as
well and call that set "Base services". Things that other projects can
assume will be present in any "OpenStack" deployment and can therefore
depend on. Things that we can clearly document in OpenStack general
"design" documents as available for any service to use the features of.

We discussed adding a DLM into this "base services set" in the past, but
without a formal decision it feels like that effort died out. You want
to start a discussion about adding Barbican to the base services set.

> So, I'm not even sure how we start this
> next conversation, which is why I'm starting it on the tc list to figure
> out next steps.
> 
> Over the past many cycles, Nova / Cinder have been bringing in
> encryption facilities. Volumes encryption (which needs coordination
> between the 2) is the first bit of this. Non volume disks at rest is
> definitely another thing that is desired by folks investing in Barbican.
> This is one of the best ways to secure tenants against each other, so
> that when you boot up you can't just run 'strings /dev/sda' and pull out
> content about people that were on the machine before you.
> 
> However, in the current state of the world, Barbican remains optional.
> It came in too late to be in defcore by default, and it has a low
> deployment rate.
> 
> That optionality is slowing down these security features. And making
> everything have to go through awkward layers of building fake key
> managers that ship as default with projects -
> https://github.com/openstack/nova/blob/6a5e36f52ce29a1cc1825ab751c5c5008efe1cbf/nova/keymgr/conf_key_mgr.py#L49.
> Plus, building a secure key manager is hard. Doing it multiple times
> poorly, even for testing, really takes a hit on the security front.
> 
> It feels like we should consider making Barbican non optional, as these
> kinds of security features feel like good things to be available out of
> the box with sane defaults. But, given the current structure I'm not
> sure what conversation we need to have to do that. Is this just a TC
> agenda item? Is this a giant ML thread in which 5 other projects want to
> become non optional (and thus the whole effort dies out)? What are the
> defcore implications? Does the Nova/Cinder team have the ability to make
> it non optional and everyone else just has to accept that?
> 
> So, this is more about what is the next way to have this conversation,
> as I think this kind of state transition is one we haven't had in a
> while. And I'd like to get this percolating far enough in advance of
> Barcelona, that we provide space for the conversation there if we need it.

There are two aspects in that conversation.

First, the question of the desirability to extend the "base services"
set. You make a compelling argument for adding Barbican (and a
compelling argument was made in the past for having a DLM). The benefit
is that you get easier access to a technology (key manager, DLM) that
helps you solve problems (encryption, complex scalable locks). The
downside is the added complexity you force on every OpenStack deployment
by making an extra component necessary. My take is that we need to do
it, otherwise we'll continue to use suboptimal technology (emulating
locks using the database, fake key managers) and make ourselves
irrelevant a long time before we make ourselves non-installable. But we
need to do it conservatively and only when the benefits far outweighs
the costs.

Second, the question of how to have that discussion in our community. I
encouraged the recently-announced Architecture WG to take the topic of
growing the base services set and lead the public discussion
(cost/benefit as described above) about them. In the end a decision
needs to be clearly made (otherwise we'll be left in not-yes not-no
limbo forever like in the DLM case) and therefore I can see a role for
the TC to define the base services et and bless the suggested additions
to it. But I'd rather have the public community discussion in an open
structure (the Architecture WG) rather than a closed group (the elected
TC members).

In order to avoid (most?) rabbit holes, the discussion should be
specifically about adding Barbican (or DLM), not "what could we add ?".
Defcore certainly needs to be involved but frankly I would find it weird
if the process of adding an OpenStack project (Barbican) to the base
service set was made more complex than the process of adding a
non-OpenStack dependency (a DLM) to the base service set. It feels like
an important cross-community discussion, which we could have in a Design
Summit cross-project workshop in Barcelona (although that's not the
ideal venue due to the pure developer branding around the event). I
expect this type of cross-community discussions to be facilitated by the
future neutral "Forum" we'll have starting at the Sydney Summit.

-- 
Thierry Carrez (ttx)