Open Stack

Dan,

Adam Young was advocating for something like this.  I don't know if a
consensus was ever reached, but I thought it was a good idea.

https://lists.launchpad.net/openstack/msg10864.html

Nate
On Jul 13, 2012 5:31 PM, "Dan Sneddon" <dan at cloudscaling.com> wrote:

> I am attempting to find a workable solution for the following use case,
> and would like to get feedback from the community about it.
>
> There are some situations when it is required to put a proxy in front of
> multiple API endpoints and route by URL. This allows for more flexible
> routing/filtering in load balancers and firewalls, and makes it possible to
> differentiate between services in unified HTTP logs. In the current
> OpenStack model a typical API endpoint looks something like this:
>
> http(s)://<hostname>:<port>/<api version>/<account>/<container>/<object>
>
> In essence, separate services have similar URLs, and are separated by the
> port number. It is difficult to use a request-header-aware proxy to route
> to a particular endpoint, since there is no clear differentiation between
> service URLs if the hostname and port are the same.
>
> With standard HTTP, this can be handled by using several different
> hostnames pointing to the same IP. This is particularly a problem with SSL
> certificates, which need to match the hostname.
>
> If the URLs contained a service identifier at the beginning of the URL,
> this would allow a proxy to make decisions about where to route requests
> based on the beginning of the URL, for example the URL above would become:
>
> http(s)://<hostname>:<port>/<service>/<api
> version>/<account>/<container>/<object>
> e.g.
> https://api-host:443/compute/v2.0/...
> https://api-host:443/auth/v2.0/...
> etc.
>
> It seems that the API services are compatible with this through the use of
> the urlmap configuration by including both versions of the URL:
>
> [composite:osapi_compute]
> use = call:nova.api.openstack.urlmap:urlmap_factory
> /: oscomputeversions
> /v1.1: openstack_compute_api_v2
> /v2: openstack_compute_api_v2
> /compute/: oscomputeversions
> /compute/v1.1: openstack_compute_api_v2
> /compute/v2: openstack_compute_api_v2
>
> Is allowing both forms of this URL in all services likely to break
> anything down the line? Does this seem like a common enough use case that
> it should be considered as an addition to the default configuration? Also,
> as services change (such as nova-volume being replaced by cinder) is there
> a set of generic service descriptors defined that can be used to abstract
> from the particular name of the service? Some of these are obvious, like
> "network", but it would be nice to be consistent across versions and
> instances.
>
> Thank you for your feedback,
> --
> Dan Sneddon
> Senior Engineer, Cloudscaling
> dan at cloudscaling.com - @dxs on Twitter
> _______________________________________________
> 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/20120713/2f22850c/attachment.html>