Curlable Kubernaut API

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]

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]

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?