[Openstack] URL Scheme for deploying Openstack in HTTPD

Anne Gentle anne at openstack.org
Mon Apr 30 21:29:00 UTC 2012


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 <ayoung at 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  berendt at b1-systems.de
>
>
>
>
>  -Dolph
>
> On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayoung at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120430/212e1801/attachment.html>


More information about the Openstack mailing list