Open Stack

On 09/03/2013 09:27 PM, Bryan D. Payne wrote:
> 
>         > How can someone use your code without a key manager?____
> 
>         Some key management mechanism is required although it could be
>         simplistic. For example, we’ve tested our code internally with
>         an implementation of the key manager interface that returns a
>         single, constant key.
> 
>     That works for testing but doesn't address: "the current dearth of
>     key management within OpenStack does not preclude the use of our
>     existing work within a production environment" 
> 
> 
> My understanding here is that users are free to use any key management
> mechanism that they see fit.  This can be a simple "return a static key"
> option.  Or it could be using something more feature rich like Barbican.
>  Or it could be something completely home grown that is suited to a
> particular OpenStack deployment.
> 
> I don't understand why we are getting hung up on having a key manager as
> part of OpenStack in order to accept this work.  Clearly there are other
> pieces of OpenStack that have external dependencies (message queues, to
> name one).

External dependencies are fine, obviously.  The difference is whether we
actually have code to interface with those external dependencies.  We
have code to talk to databases and message queues.  There's no code
right now to interface with anything for key management.

The request here is for something that allows this to be used without
having to modify or add code to Nova.

> 
> I, for one, am looking forward to using this feature and would be very
> disappointed to see it pushed back for yet another release.
> 

It's not like I'm happy about it, but it needs more code.

> 
>     Is a feature complete if no one can use it?  
> 
>     I am happy with a less then secure but fully functional key manager.
>      But with no key manager that can be used in a real deployment, what
>     is the value of including this code?
> 
> 
> Of course people can use it.  They just need to integrate with some
> solution of the deployment's choosing that provides key management
> capabilities.  And, of course, if you choose to not use the volume
> encryption then you don't need to worry about it at all.

As noted above, the integration effort takes code.  We need that code so
that the feature can be used.

> I've watched this feature go through many, many iterations throughout
> both the Grizzly and Havana release cycles.  The authors have been
> working hard to address everyone's concerns.  In fact, they have
> navigated quite a gauntlet to get this far.  And what they have now is
> an excellent, working solution.  Let's accept this nice security
> enhancement and move forward.

I agree that they have worked hard.  It's much appreciated.

We have held other features to this same standard.  See the discussion
about live snapshots / cloning fairly recently for one such example.  We
require that there be code in the tree that makes the feature usable.
That's where we are with this.

If a simple "return a static key" is deemed useful, I suspect that could
be put together in time.  From talking to Joel on IRC, it seemed that it
wasn't worth it.

This is one of those cases where we have to make a tough call, but after
reviewing the concerns raised, the answer is that without some
additional code to make it usable without modifications or additions,
the feature is deferred to Icehouse.

-- 
Russell Bryant