Open Stack

Can we get this on the Agenda for todays meeting,  take an informal 
poll, and formalize it?  If So,  I'll write it up and post on the wiki.




On 04/30/2012 05:29 PM, Dolph Mathews wrote:
> On Apr 30, 2012, at 3:20 PM, "Daniel P. Berrange"<berrange at redhat.com>  wrote:
>
>> On Mon, Apr 30, 2012 at 01:58:24PM -0500, Dolph Mathews wrote:
>>> I very much like the idea that we should have a well documented
>>> recommendation on this topic.
>>>
>>> My only criticism is that the API/service names should be used in place of
>>> project names, e.g. https://hostname/identity, https://hostname/compute,
>>> etc.
>> Why do you think that is better ? I've been switching back&  forth on
>> this topic unable to figure out which is a better long term bet. Trying
>> to think of downsides, I come up with the thought of what happens if we
>> wwant to support multiple different "compute" or "identity" APIs on the
>> same host. From a namespacing POV it seems better to use the names based
>> off the openstack component name, rather than generic "logical function"
>> which has higher potential for clashing.  This lead me to prefer what
>> Adam proposes below.
>>
> Keystone and Horizon are the two best reasons why -- they're the most likely to be re-implemented by third parties, which means they'll naturally want to brand their endpoints accordingly (thus defeating the goal of the recommendation), e.g. http://hostname/specialsauth
>
> Sticking with /identity means people know where to go, and at least vaguely what to expect when they get there.
>
> Finally, OpenStack consumers shouldn't have to understand our project names prior to understanding our API.
>
> Regarding "multiple different 'compute' or 'identity' API's on the same host" ... Isn't that the same problem that multiple choice responses and versioned endpoints already solve?
>
>>> On Mon, Apr 30, 2012 at 11:34 AM, Adam Young<ayoung at redhat.com>  wrote:
>>>
>>>> A production configuration of Openstack should be able to run in HTTPD
>>>> using SSL.  I'd like to propose the following URL scheme for the web Apps
>>>> so that the various pieces can be installed on a single machine without
>>>> conflict.
>>>>
>>>> All pieces will be served on port 443 using the https protocol.
>> I think this is tangential to the main point of the proposal. Even if
>> every service was on its own plain HTTP port, I would still suggest
>> that this namespace proposal be followed by them to give consistency.
>>
>>>> I've written these up to use the project names.  Enough documentation and
>>>> information around the projects has circulated such that replacing, say,
>>>> Keystone with identity would cause more confusion than it would remove.
>>>>
>>>>
>>>> #Web UI
>>>> #If and only if this is installed,  we should put in a forward from / to
>>>> /dashboard for browser clients.
>>>> https://hostname/dashboard
>>>>
>>>>
>>>> #identity
>>>> https://hostname/keystone/main
>>>> https://hostname/keystone/admin
>>>>
>>>> #image
>>>> https://hostname/glance/api
>>>> https://hostname/glance/registry
>>>>
>>>> #compute.  Not sure if all of these are required
>>>> https://hostname/nova/api
>>>> https://hostname/nova/crt
>>>> https://hostname/nova/object
>>>> https://hostname/nova/cpu
>>>> https://hostname/nova/network
>>>> https://hostname/nova/volume
>>>> https://hostname/nova/schedule
>>>> https://hostname/nova/novnc
>>>> https://hostname/nova/vncx
>>>> https://hostname/nova/cauth
>>>>
>>>> #network
>>>> https://hostname/quantum/api<https://hostname/quantum/service>
>>>> #if we had an API for the agent it would be
>>>> https://hostname/quantum/agent<https://hostname/quantum/service>
>>>>
>>>>
>>>> There was an attempt to make Swift also fit into this scheme.  However,
>>>> Swift URLs fall into a scheme of their own,  and won't likely be colocated
>>>> with the admin pieces outside of development.  Here they are for
>>>> completeness.
>>>>
>>>> #storage
>>>> https://hostname/swift/account
>>>> https://hostname/swift/object
>>>> https://hostname/swift/container
>> In general I think this proposal is sound. Having clearly distinct
>> namespaces for each component's API(s) is general good practice,
>> to allow arbitrary co-location of services on the same host/port.
>>
>> Regards,
>> Daniel
>> -- 
>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|