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