This repository has been archived on 2020-01-20. You can view files and clone it, but cannot push or open issues or pull requests.
node-spearhead/TODO.txt
2016-03-18 08:51:28 -07:00

60 lines
1.6 KiB
Plaintext

test suite:
- all the commands: test/integration/cli-*.test.js
- TritonApi testing: test/integration/api-*.test.js
- more test/unit/...
sub-user support (profiles, `triton account`, env, auth)
note in README that full UUIDs is much faster in the API
*type*: cloudapi changes to clarify: LX, docker, smartos, kvm instances
# maybe next
PUBAPI-1117 triton create -c|--count N
Rate limiting. Testing with non-op accounts. I suspect PUBAPI-1117 and other
usage will lead to rate limiting errors from cloudapi. `triton` should
(a) retry reasonably on those error codes and (b) proactively control rate
of cloudapi requests (tunable).
triton images
Drop 'state' in default columns. Add type to be able to see lx or not
for 'linux' ones. That might hit that stupid naming problem.
# another day
triton config get|set|list # see 'npm config'
triton --shell # or whatever, repl
$ triton shell
$profile> cd inst
$profile inst> ls
...
$profile inst> cd vm0
$profile inst/vm0> get
...
$profile inst/vm0> cd snapshot
$profile inst/vm0/snapshot> ls
...
extensible triton commands:
~/.triton/plugins.d/$plugin.json
Would be nice to not have to read/parse all these files for every run,
i.e. lazily. Is that a problem for `triton` showing commands list?
How do plugins in other node projects work? Is there an npm special thing
that would work?
Should plugins just be commands? Perhaps for starters, but don't hardcode
that.
$ cat build.json
{
"cmd": "build",
"desc": "Build a Triton image from a Tritonfile"
"require": "triton-plugin-build"
}