Back in the Day, Barbican was just one Service of Cloud Keep. While I would say that KDS belongs in the Cloud Keep, it is not the same as, and should not be deployed with Barbican. Is it possible to keep them as separate services? I think that is the right way to go. Barbican is for the end users of Cloud, but KDS is not. Does this make sense?

On 11/25/2013 11:24 AM, John Wood wrote:
Hello folks,

FWIW, I've created a wiki page here aimed at easing the code transition to 
barbican for the KDS patch:

Please let us know if we can be of further help.

OpenStack-dev mailing list

From: Thierry Carrez []
Sent: Monday, November 25, 2013 4:17 AM
Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution 
Server, Trusted Messaging

Adam Young wrote:
Keep KDS configuration separate from the Keystone configuration: the
fact that they both point to the same host and port is temporary.  In
fact, we should probably spin up a separate wsgi service/port inside
Keystone for just the KDS.  This is not hard to do, and will support
splitting it off into its own service.

KDS should not show up in the Service catalog.  It is not an end user
visible service and should not look like one to the rest of the world.

Once we have it up and running, we can move it to its own service or
hand off to Barbican when appropriate.
Right, I think a decent trade-off between availability and avoiding code
duplication would be to have a minimal KDS available as an option in
Keystone, with Barbican/something-else being developed in parallel as
the complex/featureful/configurable option. If Barbican/something-else
reaches feature parity, covers the "basic and simple" use case and is
integrated, we could deprecate the in-Keystone minimal-KDS option.

I know this plan looks a bit like the nova-network chronicles, but I
think the domain is more simple so feature parity is not as much of a

Thierry Carrez (ttx)

OpenStack-dev mailing list

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to