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?

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

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?

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?

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

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?

Sounds good. Thanks Sebastien. I'll watch the thread [1] for updates

[1] https://github.com/cloudfoundry-incubator/cf-abacus/issues/110

I just wanted to follow up on this.

Github 110 is now closed as we've finished removing explicit references to
regions in the Abacus API in favor of a more generic namespace/scoping
mechanism. With these changes, organization ids, resource instance ids, etc
can include a namespace/scope allowing you to ensure they're really
universally unique across your multiple CF deployments (if you're
paranoid...)

For example the following ids will be happily accepted:
a3d7fe4d-3cb1-4cc3-a831-ffe98e20cf27
us-south:a3d7fe4d-3cb1-4cc3-a831-ffe98e20cf27
my-deployment:foo:bar:xyz23:a3d7fe4d-3cb1-4cc3-a831-ffe98e20cf27
...

We're keeping the existing region field as optional for now in the usage
schemas to avoid breaking the folks that use it, but it's not needed
anymore, and I'd like to remove it as well at some point.

HTH

- Jean-Sebastien