openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

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.

> 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 :|