ayoung at redhat
May 1, 2012, 7:23 AM
Post #9 of 11
(113 views)
Permalink
|
|
Re: URL Scheme for deploying Openstack in HTTPD
[In reply to]
|
|
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> 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> 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 :|
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
|
