Add region kw argument to login.

[NullHypothesis]

As mentioned in this story, there are several ways to allow users to specify the region:

1. Modify tiledb.cloud.client.config.config.host directly, which is the status quo.
2. Add a region keyword argument to classes like DAG, Delayed, etc.
3. Specify the region as part of logging in (this PR implements a PoC).

The first option is confusing to customers, so we need a better approach. I've been playing with the second approach and find it confusing too: It's easy to forget to pass the region argument. Besides, if a user wants to run a task graph in region A, odds are that they want all their code to run in region A. The third approach strikes me as the safest and least confusing but it feels odd having to specify the region as part of the login function, like so:

tiledb.cloud.login(..., region=tiledb.cloud.AwsRegion.AP_SOUTHEAST_1)

Or perhaps we should instead expose a new function, like tiledb.cloud.set_region()? Any thoughts on this?

[Shelnutt2]

Should we make the region be <region>.<cloud_provider> so its future proofed?

[NullHypothesis]

Yes, good point. I turned the region into an enum, which also helps with validating the given region.

[thetorpedodog]

We don’t want to make this AWS-specific; since this is just going to replace the host parameter in the endpoint, would it make sense to have a set of constants that the user can pass in?

AWS_US_EAST_1 = "https://us-east-1.aws.api.tiledb.com"
# etc.

# Or namespace it with classes:
class AWS:
  US_EAST_1 = "https://us-east-1.aws.api.tiledb.com"

class OtherCloud:
  SOME_REGION: "https://some-region.other.api.tiledb.com"

[NullHypothesis]

My thinking with the enum was that we simply add another one as we support new cloud providers. That said, if y'all prefer constants, then that's fine with me.

Also, in de2950f, I revised the code to expose a separate function instead, tiledb.cloud.login_to_region(). This feels more natural to use.

[gsarantid]

I guess this should be if region not in AWS instead?

[NullHypothesis]

They're semantically identical but your suggestions is more readable, so I addressed this in 5af2601.

[vlasisPit]

Maybe we can expose a method to the clients to just print all the available regions?

[NullHypothesis]

My expectation was that users turn to the docs to see what regions are supported. That said, if you see value in such a function then I'm happy to add it.

[thetorpedodog]

I would call this AWSRegion or namespace it inside a Region class (so it shows up as Region.AWS.whatever)

[NullHypothesis]

Fixed in 445c41d.

[thetorpedodog]

Suggested change

	raise Exception("Cloud region is invalid")
	raise ValueError(f"region {region} is invalid")

[NullHypothesis]

Fixed in 25bccf9.

[thetorpedodog]

I’m still skeptical of this being its own function which takes enums rather than just a set of string constants that you can pass to host. Among other things, as we add new regions, existing installs would have a divide where existing regions can use the region type and the login_to_region function, but new regions would use login with host=.

In short, to me,

tiledb.cloud.login(host=tiledb.cloud.Region.AWS.US_EAST_1)

(or maybe make region into a module, tiledb.cloud.regions)

seems like a perfectly reasonable thing to write, and doesn’t require any new functions.

[NullHypothesis]

In short, to me,

tiledb.cloud.login(host=tiledb.cloud.Region.AWS.US_EAST_1)

(or maybe make region into a module, tiledb.cloud.regions)

seems like a perfectly reasonable thing to write, and doesn’t require any new functions.

See e5401a6.

[thetorpedodog]

one suggestion but looks good overall.

[thetorpedodog]

maybe put this directly into region/__init__.py?

[NullHypothesis]

Right, addressed in the squashed commit that I just force-pushed. Thanks for all your feedback!