60 lines
1.6 KiB
Plaintext
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"
|
|
} |