If there's no objection and nobody comes up with a better idea, I'll start
to work on adding a GET /v1/regions/us/orgs/ path as discussed here
On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
Sorry for the delay, I didn't realize this was a question for the Abacus
project as it didn't have the [abacus] subject tag we've been using for
Abacus discussions recently. I guess from now on I'll just check all
threads just in case :)
This is a good question. With independent deployments of CF in multiple
datacenters or regions you may need to distinguish between organization
86d0482c-7208-4f2f-8606-935c080cad41 in region 'us' and the same
organization id in region 'eu' for example.
We could add another path to the API for the cases where you care about
the region with GET /v1/regions/us/orgs/86d0482c-7208-4f2f-8606-935c080cad41/...
if that helps.
I could also sympathize with another approach, where we'd say that the
organization id being a guid should truly be *globally unique*. It looks
like the the current CF guid generation algorithm doesn't *guarantee*
uniqueness across deployments  but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.
What do others think?
On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
account service implementations could need additional qualifiers to
uniquely identify an organization. For example, the implementation I'm
working on needs a region along with the guid of the org.
The API to get an account given org information looks like this
How do we want to support the additional qualifier in abacus? One
solution that I can think of is including the region in the guid. org_id
could be 'guid_region'. ex: