Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ________________________________________
> From: Thierry Carrez [thierry at openstack.org]
> Sent: Monday, November 25, 2013 4:17 AM
> To: openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev