Every Datum location is now in the API

[scotwells]

Datum serves from sixteen locations. Until now, the API listed three. datumctl get locations now returns the whole footprint, scoped to your own project, with the detail you need to decide where to run something.

Every location, in your project

$ datumctl get locations
NAME           CLASS           CITY   READY   REASON
ae-north-1     datum-managed   DXB    True    Ready
au-east-1      datum-managed   SYD    True    Ready
br-east-1      datum-managed   GRU    True    Ready
ca-east-1      datum-managed   TOR    True    Ready
cl-central-1   datum-managed   SCL    True    Ready
de-central-1   datum-managed   FRA    True    Ready
gb-south-1     datum-managed   LHR    True    Ready
in-west-1      datum-managed   BOM    True    Ready
jp-east-1      datum-managed   TYO    True    Ready
nl-west-1      datum-managed   AMS    True    Ready
sg-central-1   datum-managed   SIN    True    Ready
us-central-1   datum-managed   DFW    True    Ready
us-east-1      datum-managed   IAD    True    Ready
us-east-2      datum-managed   LGA    True    Ready
us-west-1      datum-managed   SJC    True    Ready
za-central-1   datum-managed   JNB    True    Ready

A location you can see is a location offered to you. If it is listed in your project, you can deploy into it.

Locations describe where they are

Each location carries its own geography, so you can answer a placement or residency question without looking anything up elsewhere.

$ datumctl get location jp-east-1 -o yaml

spec:
  topology:
    topology.datum.net/city: Tokyo
    topology.datum.net/city-code: TYO
    topology.datum.net/region: jp-east-1
    topology.datum.net/province: Tokyo
    topology.datum.net/province-code: JP-13
    topology.datum.net/country: Japan
    topology.datum.net/country-code: JP
    topology.datum.net/timezone: Asia/Tokyo
  coordinates:
    latitude: "35.6762"
    longitude: "139.6503"

country-code is an ISO 3166-1 alpha-2 code, so a data residency question is answerable without parsing a display name. timezone is an IANA zone, for maintenance windows and for showing local time.

And which services run in each one

Where a place exists and where a service runs are two different questions. A location being available to you does not mean every service is offered there.

$ datumctl get serviceavailabilities
NAME                                   SERVICE                    LOCATION       AVAILABLE
compute--us-east-1                     compute                    us-east-1      True
compute--us-central-1                  compute                    us-central-1   True
compute--us-west-1                     compute                    us-west-1      True
networking-datumapis-com--jp-east-1    networking-datumapis-com   jp-east-1      True
networking-datumapis-com--de-central-1 networking-datumapis-com   de-central-1   True
...

A record exists where that service works for you. Network services run in all sixteen locations. Compute runs in us-east-1, us-central-1 and us-west-1. Where a service is not listed against a location, it is not offered there yet.

Why this changed

Locations used to be defined inside the network services operator, and each surface that needed them — the console, the CLI, the docs — answered the question its own way. They drifted, and the API ended up describing a smaller platform than the one actually running. Locations now come from one service that owns them, and every surface reads the same answer.