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:
https://github.com/cloudkeep/barbican/wiki/Blueprint:-KDS-Service
Please let us know if we can be of further help.
Thanks,
John
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
________________________________________
From: Thierry Carrez [thie...@openstack.org]
Sent: Monday, November 25, 2013 4:17 AM
To: openstack-dev@lists.openstack.org
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
challenge.
--
Thierry Carrez (ttx)
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
