So, since we're not sure about that region field, I'll wait for the
discussion to settle before making any additions to the API.
In the meantime, Bharath, the convention you've described (or another one
like us:86d0482c-7208-4f2f-8606-935c080cad41) should just work.
HTH
- Jean-Sebastien
On Wed, Oct 21, 2015 at 12:41 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:
I could argue that region is actually a pretty generic term, as it's used
in a wide range of domains from geography (parts of the world or parts of a
country) to networking and datacenters (a region as a group of IP
addresses) and even memory management in garbage collectors for example :)
... but I was also wondering about a potential confusion where our users
could just assume that region always has to be a part of the world.
So we could either make clear that region is used in its generic sense and
not necessarily a geographical region in an Abacus doc on that topic, or
attempt to find another term like cluster for example, or zone or something
else... I've created Github issue #110 [1] to help folks submit their ideas
on this.
[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/110
- Jean-Sebastien
On Wed, Oct 21, 2015 at 10:32 AM, Dieu Cao <dcao(a)pivotal.io> wrote:
I'm curious if region is perhaps too specific?
Perhaps some other generic word would be better so that it's not
prescriptive.
-Dieu
On Wed, Oct 21, 2015 at 10:10 AM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:
Hi all,
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 sometime today.
- Jean-Sebastien
On Tue, Oct 20, 2015 at 10:11 PM, Jean-Sebastien Delfino <
jsdelfino(a)gmail.com> wrote:
Hi Bharath,
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 [1] but combining the region with it would
make it unique. IIUC I think that's what you're suggesting.
What do others think?
[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Pointer-to-the-CF-code-that-generates-org-and-service-instance-guids-tp2192.html
- Jean-Sebastien
On Tue, Oct 20, 2015 at 11:42 AM, Bharath Sekar <bsekar14(a)gmail.com>
wrote:
Hi,
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
GET /v1/orgs/:org_id/account
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:
GET /v1/orgs/86d0482c-7208-4f2f-8606-935c080cad41_us/account
Thoughts?
