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
d...@cloudscaling.com - @dxs on Twitter
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to