An interesting idea (maybe)

[Tim Penhey]

Hi All,

I was chatting with Roger this morning and crystallized an idea.  I
think it may be groovy, but I'm curious to see what others thing.

I spent some of yesterday afternoon watching the juju charm workshop
video from https://juju.ubuntu.com/get-started/ and was struck by a few
things, and combined with a discussion I had with Jorge earlier, a few
things fell into place.

Background:

Chatting with Jorge, he mentioned a little frustration at going
  `juju expose service-name`
never told him the public ip address for that service, nor enough
standard output to say what was going on.

Watching the video was good as it helped my understanding of juju quite
a bit, especially around the async nature of juju around command execution.

This was helped further by my chat with Roger this morning in that in
general the juju commands are just modifying the definition of the
environment, and not doing anything.  That work is handled by the
machine agents when they feel like it :-)


Proposal:

What do people think of the idea of having a command that effectively
opens a connection to the bootstrap machine and listens to events, and
writes them to the terminal.  Kind of like a publish-subscribe system.

So lets say we had a bunch of juju commands like:

juju deploy wordpress
juju deploy mysql
juju add-relation mysql wordpress
juju expose wordpress

Say... something like `juju observe`

I'm imagining output something like:

$ juju observe
listening to events from machine/0
machine/1 started
machine/2 started
wordpress being deployed to machine/1
mysql being deployed to machine/2
mysql started on machine/2
wordpress started on machine/1
relation added wordpress:db <-> mysql:db
wordpress exposed on port 80 http://some-long-incomprehensible-aws.aws.com


This would mean the user wouldn't have to sit there and poll `juju
status` to see when things had actually happened.

Actually timestamps might be useful too...

There are other things that we could add like levels (for example are
subordinate charm deployments shown, etc).

But the question is: is this an idea worth following?

Tim