[openstack-dev] Managing endpoints for multiple regions for a service

Vishvananda Ishaya vishvananda at gmail.com
Tue Dec 11 18:12:55 UTC 2012


On Dec 11, 2012, at 5:42 AM, "Karajgi, Rohit" <Rohit.Karajgi at nttdata.com> wrote:

> Hi,
>  
> Referring to bug https://bugs.launchpad.net/nova/+bug/1087735, I’d like to get some thoughts on how the current implementation can be improved
> for filtering endpoints by region.
>  
> For example, during Cinder volume attachment as described in the bug, if we specify ‘attr’ and ‘filter_value’ correctly for a specific region,
> (Eg: attr=’region’, filter_value=’RegionTwo’) in the call to service_catalog.url_for()  , cinder correctly parses this value and returns a matching endpoint for this region.
> https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L63
>  
> However, it is unclear how these parameters should be passed from nova volume API.
> As a possible solution, should the context object also contain a “region_name” parameter added to it, and then extract this parameter into the cinderclient?
> Does it make sense to add another flag/configuration parameter to nova.conf for accepting region?
> How can we ensure that a region name is consistently utilized and validated across APIs as well as python clients?

I would think that attaching volumes across regions would not be allowed, so I would assume that we would actually want nova to pass its own region. If there is some way for nova to check what its own region is in the endpoint list, then it could just pass that one along. Unfortunately the only way I can think of doing that is by attempting to parse osapi_compute_link_prefix from config and matching it against the catalog. Probably not the best option. Since this is the case, It appears that a config parameter specifying the region of the install might be best.

Vish

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121211/b8bd7190/attachment.html>


More information about the OpenStack-dev mailing list