Open Stack

> 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.
>
> +1 on spinning up a new service/wsgi


> 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.
>
> I believe that KDS should be discoverable, but I agree that it is not an
end user service, so I am unsure of the best approach wrt the catalog.

The other concern is the library interfacing with KDS (I would assume this
goes into keystoneclient? At least for the time being).


> 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.
>
> I think the API is if not ready to go, very close (maybe a single cleanup
revision).  If we are going to do this lets get the spec done ASAP and get
the code in right away so we can get traction on it.  Icehouse milestones
will be coming through fast.  I think it is imminently possible to have
this in the repo and running fairly quickly with concerted effort.

The code might need minor tweaking to conform to the spec if it changes.
But as I recall almost 100% of the back and forth at this point was does it
belong in keystone.


> https://review.openstack.org/#/c/40692/
>
>

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131124/edb11ffc/attachment.html>