On 11/22/2013 01:49 PM, Mark McLoughlin wrote:
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:
Russell Bryant wrote:
[...]
I'm not thrilled about the prospect of this going into a new project for
multiple reasons.
- Given the priority and how long this has been dragging out, having to
wait for a new project to make its way into OpenStack is not very appealing.
- A new project needs to be able to stand on its own legs. It needs to
have a reasonably sized development team to make it sustainable. Is
this big enough for that?
Having it in Barbican (and maybe have Barbican join under the identity
program) would mitigate the second issue. But the first issue stands,
and I share your concerns.
Yes, I agree. It's disappointing that this change of plans looks like
its going to push out the ability of an OpenStack deployment to be
secured.
If this becomes a Barbican API, then we might be able to get the code
working quickly ... but it will still be some time before Barbican is an
integrated project, and so securing OpenStack will only be possible if
you use this non-integrated project.
Mark.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I hear a concerted effort to get this bootstrapped in Keystone. We can
do this if it is the voice of the majority.
If we do:
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.
Are people OK with the current API implementation? I didn;t see a lot
of outside comment on the code review, and there were certainly some
aspects of it that were unclear.
https://review.openstack.org/#/c/40692/
Note that we have lost Simo as a resource for this, so if it is going to
move forward, we need other members of the community to step forward and
keep the process going.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
