Curlable Kubernaut API

[rhs]

Kubernaut curl API:

Claim a cluster:
 GET <URL>/claims/<client-supplied-globally-scoped-claim-name>?expires=<deadline> -> kubeconfig file

Renew a claim:
 GET <URL>/claims/<client-supplied-globally-scoped-claim-name>?expires=<new-later-deadline> -> kubeconfig file

Release a cluster
 GET <URL>/claims/<client-supplied-globally-scoped-claim-name>?expires=<time-in-past> -> kubeconfig file

List claims:
 GET <URL>/claims/ -> json body with list of globally-scoped-claim-names

Rationale:

After having integrated kubernaut into a bunch of dev loops, I think
the above curl-based API would probably be simpler/easier to work
with and would avoid a bunch of the work associated with having a
fat client.

FWIW, the list part isn't actually directly needed by the
integrations, but it is useful for debugging/correcting resource
leaks.

[plombardi89]

There is one? How do you think the CLI works?

[plombardi89]

Delete

curl -X DELETE -H "Authorization: Bearer <Token>" https://next.kubernaut.io/claims/:name

List

curl -H "Authorization: Bearer <Token>" https://next.kubernaut.io/claims

Get

curl -H "Authorization: Bearer <Token>" https://next.kubernaut.io/claims/:name

Create

curl -X POST -H "Authorization: Bearer <Token>" -H "Content-Type: application/json" -d '{"name": "MyCoolClaim", "group": "main"}' https://next.kubernaut.io/claims

[plombardi89]

The only reason the API isn't a first class citizen is because everyone wanted a CLI as the UX originally and handling tokens is messy.

[rhs]

Sorry for not being clearer, I'm not actually asking for documentation for the existing REST API. I was aware of that and for my purposes the existing kubernaut client is good enough documentation for how that works.

If you look at the description of the API I posted, it's different from the existing REST API in two ways:

1. It's designed to be usable from curl without extra programming, e.g. the existing create claim will return a json blob that needs to be unpacked (not something really doable in shell commands), as opposed to just directly returning the kubeconfig, e.g.

  curl -X GET -H "Authorization: Bearer <TOKEN>" https://next.kubernaut.io/claims/mine?expires=tomorrow > cluster.yaml

2. It incorporates stuff for expiration in a way that preserves this property.

[plombardi89]

While not "pretty" this is a simple work around for (1) curl ... | python -c 'import sys, json; print json.load(sys.stdin)["claim"]["kubeconfig"]'

Regarding <2>... customizable expirations is on the backlog to implemented. I have a hard time seeing how renew would work with GCE preemptible VM's on the backend though since they are automatically reaped after 24 hours without exception.

[rhs]

While not "pretty" this is a simple work around for (1) curl ... | python -c 'import sys, json; print json.load(sys.stdin)["claim"]["kubeconfig"]'

That workaround isn't a super great option for me. Keep in mind I'm trying to write build files that work anywhere, and if I could count on a sane/working python environment everywhere, then I could just use the kubernaut cli.

To be clear I don't really care about "pretty", all I care about is how much work I need to do to leverage kubernaut for my use cases, and how brittle that work is in different environments. It really could be way easier and more portable if the server API were tweaked a little.

Regarding #2... customizable expirations is on the backlog to implemented. I have a hard time seeing how renew would work with GCE preemptible VM's on the backend though since they are automatically reaped after 24 hours without exception.

It would just have a 24hr limit? I mean no claim is guaranteed to last anyways, right?