My vote is for service/API names. This convention is what the documentation uses whenever possible. <br><a href="http://wiki.openstack.org/Documentation/Conventions">http://wiki.openstack.org/Documentation/Conventions</a><br>
<br>Thanks,<br>Anne<br><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 2:30 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
On 04/30/2012 02:58 PM, Dolph Mathews wrote:
<blockquote type="cite">
<div>I very much like the idea that we should have a well
documented recommendation on this topic.</div>
<div><br>
</div>
<div>My only criticism is that the API/service names should be
used in place of project names, e.g. <a href="https://hostname/identity" target="_blank">https://hostname/identity</a>,
<a href="https://hostname/compute" target="_blank">https://hostname/compute</a>,
etc.</div>
</blockquote>
<br></div>
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.<br>
<br>
I'll treat it as one vote for each thus far. THe Vote for the
project name came from <a href="mailto:berendt@b1-systems.de" target="_blank">berendt@b1-systems.de</a><div><div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<div><br>
</div>
<div>-Dolph</div>
<div><br>
<div>On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <span><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote>
<div>
<div lang="x-unicode">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. <br>
<br>
All pieces will be served on port 443 using the https
protocol. <br>
<br>
<br>
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.<br>
<br>
<br>
#Web UI<br>
#If and only if this is installed, we should put in a
forward from / to /dashboard for browser clients.<br>
<a href="https://hostname/dashboard" target="_blank">https://hostname/dashboard</a>
<br>
<br>
<br>
#identity<br>
<a href="https://hostname/keystone/main" target="_blank">https://hostname/keystone/main</a>
<br>
<a href="https://hostname/keystone/admin" target="_blank">https://hostname/keystone/admin</a>
<br>
<br>
#image<br>
<a href="https://hostname/glance/api" target="_blank">https://hostname/glance/api</a>
<br>
<a href="https://hostname/glance/registry" target="_blank">https://hostname/glance/registry</a>
<br>
<br>
#compute. Not sure if all of these are required<br>
<a href="https://hostname/nova/api" target="_blank">https://hostname/nova/api</a>
<br>
<a href="https://hostname/nova/crt" target="_blank">https://hostname/nova/crt</a>
<br>
<a href="https://hostname/nova/object" target="_blank">https://hostname/nova/object</a>
<br>
<a href="https://hostname/nova/cpu" target="_blank">https://hostname/nova/cpu</a>
<br>
<a href="https://hostname/nova/network" target="_blank">https://hostname/nova/network</a>
<br>
<a href="https://hostname/nova/volume" target="_blank">https://hostname/nova/volume</a>
<br>
<a href="https://hostname/nova/schedule" target="_blank">https://hostname/nova/schedule</a>
<br>
<a href="https://hostname/nova/novnc" target="_blank">https://hostname/nova/novnc</a>
<br>
<a href="https://hostname/nova/vncx" target="_blank">https://hostname/nova/vncx</a>
<br>
<a href="https://hostname/nova/cauth" target="_blank">https://hostname/nova/cauth</a>
<br>
<br>
#network<br>
<a href="https://hostname/quantum/service" target="_blank">https://hostname/quantum/api</a><br>
#if we had an API for the agent it would be<br>
<a href="https://hostname/quantum/service" target="_blank">https://hostname/quantum/agent</a><br>
<br>
<br>
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.<br>
<br>
#storage<br>
<a href="https://hostname/swift/account" target="_blank">https://hostname/swift/account</a>
<br>
<a href="https://hostname/swift/object" target="_blank">https://hostname/swift/object</a>
<br>
<a href="https://hostname/swift/container" target="_blank">https://hostname/swift/container</a>
<br>
<br>
<br>
The pattern here should be clear enough to extend to
integrating projects not listed above.<br>
<br>
<br>
</div>
</div>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br>