Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

URL Scheme for deploying Openstack in HTTPD

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


ayoung at redhat

Apr 30, 2012, 9:34 AM

Post #1 of 11 (1123 views)
Permalink
URL Scheme for deploying Openstack in HTTPD

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
#if we had an API for the agent it would be
https://hostname/quantum/agent


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.


dolph.mathews at gmail

Apr 30, 2012, 11:58 AM

Post #2 of 11 (1102 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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.

-Dolph

On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayoung [at] redhat> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


ayoung at redhat

Apr 30, 2012, 12:30 PM

Post #3 of 11 (1103 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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


>
> -Dolph
>
> On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayoung [at] redhat
> <mailto:ayoung [at] redhat>> 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
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>


berrange at redhat

Apr 30, 2012, 1:20 PM

Post #4 of 11 (1101 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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 [at] redhat> 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 :|

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


dtroyer at gmail

Apr 30, 2012, 1:50 PM

Post #5 of 11 (1102 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

On Mon, Apr 30, 2012 at 2:30 PM, Adam Young <ayoung [at] redhat> wrote:
> 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.

api.openstack.org lists an Identity API and a Compute API, etc. This
proposal is just mapping those API endpoints to specific URLs on a
single server, right? I think this is a strong case for using the
service names.

dt

--

Dean Troyer
dtroyer [at] gmail

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


anne at openstack

Apr 30, 2012, 2:29 PM

Post #6 of 11 (1096 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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> 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
>
>
>
>
> -Dolph
>
> On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayoung [at] redhat> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


dolph.mathews at gmail

Apr 30, 2012, 2:29 PM

Post #7 of 11 (1100 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


mjtrefethen at gmail

Apr 30, 2012, 4:46 PM

Post #8 of 11 (1095 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

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 <anne [at] openstack> 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 <ayoung [at] redhat> 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
>
>
>
>
> -Dolph
>
> On Mon, Apr 30, 2012 at 11:34 AM, Adam Young <ayoung [at] redhat> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


ayoung at redhat

May 1, 2012, 7:23 AM

Post #9 of 11 (1099 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

Can we get this on the Agenda for todays meeting, take an informal
poll, and formalize it? If So, I'll write it up and post on the wiki.




On 04/30/2012 05:29 PM, Dolph Mathews wrote:
> On Apr 30, 2012, at 3:20 PM, "Daniel P. Berrange"<berrange [at] redhat> 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 [at] redhat> 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 :|


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


ayoung at redhat

May 1, 2012, 2:10 PM

Post #10 of 11 (1096 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

Posted to

http://wiki.openstack.org/URLs


Since the vast majority of people seem to want the functionality in the
URL as opposed to the project name, I have converted to using that
scheme. Hence

https://hostname/identity/main.


Thanks

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


thierry at openstack

May 2, 2012, 4:42 AM

Post #11 of 11 (1089 views)
Permalink
Re: URL Scheme for deploying Openstack in HTTPD [In reply to]

Adam Young wrote:
> Can we get this on the Agenda for todays meeting, take an informal
> poll, and formalize it? If So, I'll write it up and post on the wiki.

Sorry, I missed the thread. Next time you can just add the topic
directly on the wiki @ http://wiki.openstack.org/Meetings/ProjectMeeting
and be present at the meeting to lead the topic discussion.

Cheers,

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.