> I also don't like that the discussions suggested that because it would be hard > to get Barbican incubated/integrated it should not be used. That is just crazy > talk. TripleO merged with Tuskar because Tuskar is part of deployment.
We are completing our incubation request for Barbican right now. I am waiting to send it until tomorrow as I figured it woudn't get a lot of traction right before the break. As I've said before, I think the KDS should be part of Barbican, but if Keystone wants to merge it sooner, I won't complain. Barbican has a pretty full roadmap through the Icehouse release, so I doubt my team would get to this. We'd be happy to help anyone interested in implementing it and I would merge it, but that's up to the authors. The public / private service argument I don't really get. The KDS will be an internal server regardless of whether it is in Barbican or Keystone so I don't think that is a differentiator. > Seems to me that pulling Barbican into the identity _program_, but still as its > own project/repo/etc. would solve that problem. Not sure I agree here. Key management solves many problems, some of which are identity problems, but key management is not fundamentally an identity service. For example, SSL certificates for services, symmetric key generation for at rest encryption, etc. What do we think are the reasons for combining the two efforts? Jarret
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
