openstack team mailing list archive

[Dan Sneddon <dan@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx - @dxs on Twitter