os_region_name should be required to prevent RegionAmbiguity when new endpoint added
Bug #1361377 reported by
Mat Lowery
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack DBaaS (Trove) |
Fix Released
|
Medium
|
Victoria Martinez de la Cruz |
Bug Description
Today, you can leave os_region_name unspecified and, given a single endpoint per service type (i.e. no service is in multiple regions), you'll get that endpoint when looking it up. However, add an additional endpoint for a given type (in another region) and you'll suddenly get RegionAmbiguity errors. To prevent this, always require os_region_name.
Changed in trove: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → next |
Changed in trove: | |
assignee: | nobody → Victoria Martínez de la Cruz (vkmc) |
Changed in trove: | |
milestone: | next → ongoing |
Changed in trove: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
As I originally captured this bug, it's really dictating a solution to a problem. Let's start with the problem itself first: Adding a new Nova endpoint (or any endpoint needed by Trove services) means that you'll get a RegionAmbiguity error (in a otherwise perfectly functioning Trove deployment) because, by default, os_region_name isn't set. So without the region, you get more than one endpoint for Nova and Trove raises the exception.
Some possible solutions:
1. If you make os_region_name required, but leave it as None, then Trove won't "work out of the box".
2. If you make os_region_name required and set the os_region_name out of the box, what do you set it to? DevStack's region (I think it's called RegionOne)?
3. Stop raising RegionAmbiguity errors and just take any endpoint. I'm not sure this is very wise given you could get endpoints that are not ideal in terms of performance.
4. Trove determines what region it's in and looks up other services based on the region that matches its own. I can't think of how this is possible.
Given all this typing, I guess I still like #2.