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 d...@cloudscaling.com
mailto: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 mailto:d...@cloudscaling.com - @dxs on Twitter
___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@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@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
