For what it's worth I agree, in my experience internal project names do not translate well to public API URIs. I have found that over spans of time as components may be replaced, rewritten or sourced to other vendors, focusing on naming over function simply causes issues.
Thanks, ~Matt Trefethen On Apr 30, 2012, at 6:40 PM, Anne Gentle <a...@openstack.org> wrote: My vote is for service/API names. This convention is what the documentation uses whenever possible. http://wiki.openstack.org/Documentation/Conventions Thanks, Anne On Mon, Apr 30, 2012 at 2:30 PM, Adam Young <ayo...@redhat.com> wrote: > On 04/30/2012 02:58 PM, 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. > > > I think we can propose both, and let people weigh in. I'm of equal mind, > to be honest, and could see and argument for Keystone versus Identity. > > I'll treat it as one vote for each thus far. THe Vote for the project > name came from bere...@b1-systems.de > > > > > -Dolph > > On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayo...@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'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 > > > The pattern here should be clear enough to extend to integrating projects > not listed above. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
