On Apr 30, 2012, at 3:20 PM, "Daniel P. Berrange"<berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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 :|
