juju shell

So there is the 'open-tunnel' command, which does help quite a bit as it reduces the latency, but its not obvious how to use it.

It might make sense to focus on a local resident program that caches information and updates in realtime from zookeeper, so only write operations carry the latency. This would speed up status to nearly instant, and cause some of the other things to be faster such as evaluating formula relationships during add-relation.

Would it make sense to ssh into the bootstrap node, and work from there

That would trade latency on each command, for latency on each keystroke. I think most users would perceive it as slightly better, but still annoying. The reason its annoying when you are waiting on the ensemble commands is you don't know what exactly you're waiting on, but with ssh, at least you know what you typed and that it should be printing those letters out as you type them.

James, Clint is right in that the open tunnel may solve part of the latency problem since the connection will stick around. Using it is quite straightforward: just run "ensemble open-tunnel" in one terminal, and then use ensemble as you're used to anywhere else. This pretty is pretty close to what a plain shell would do.

The real speed gain, though, is in a different strategy: if we can define a high-level protocol for our commands, and can then put the server side within the zookeeper machine itself, most commands might potentially work with a single roundtrip, and the expensive successive zookeeper interactions would happen all within the machine, with loopback connectivity.

Marking Triaged for now, it still makes sense to have a shell which is smart enough about juju to do lots of things faster and perhaps more efficiently than regular unix shells could.