[Openstack] Routing ReST API Calls by URL
Adam Young
ayoung at redhat.com
Mon Jul 16 14:10:54 UTC 2012
On 07/13/2012 05:39 PM, Nathanael Burton wrote:
>
> 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
>
Dan,
Here's my proposed scheme.
http://wiki.openstack.org/URLs
I have submitted a patch for running Keystone in Apache:
https://review.openstack.org/#/c/9735/
This assumes that you put admin on https://hostname/admin
and so on.
For Nova, there is a pretty good write up here:
http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/
Which pretty much takes the same approach.
Glance needs some work to fit into that scheme, too, as I recall.
The Client pieces need to be flexible enough to call with the suburls.
For example, look at this patch:
https://review.openstack.org/#/c/7156/
> On Jul 13, 2012 5:31 PM, "Dan Sneddon" <dan at cloudscaling.com
> <mailto: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 <mailto:dan at cloudscaling.com> - @dxs on Twitter
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack at lists.launchpad.net
> <mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> 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/20120716/243b41b9/attachment.html>
More information about the Openstack
mailing list