<div dir="ltr">juju returns after the command successfully runs because by design its async , you would not want the console to block when your doing something like 'juju deploy -n 50 hadoop' ... waiting for 50 nodes to finish before i could do something else is not good.<div>
<br></div><div style>'juju status' will tell you the status of each service, node, and machines.</div><div style><br></div><div style>... as far as progress and debugging, I think what your looking for is 'juju debug-log'  </div>
<div style><br></div><div style>... as far as ssh I think what your looking for is 'juju ssh service/node' e.g. 'juju ssh mysql/0'</div><div style><br></div><div style>IIRC this should all be covered in the Documentation pretty well, is there areas you can see to make it clearer/improvements ?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 26, 2013 at 7:48 PM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
We discussed thus issue in the recent weekly juju meeting and agreed to move the<br>
conversation to the list.<br>
<br>
TL;DR; - what feedback should (long running, background) juju commands provide<br>
<br>
The topic of conversation resolves around how/if we should provide visible<br>
feedback to the user about the progress of juju commands. The issue arose when<br>
we were discussing the behaviour of the bootstrap command in particular. The<br>
bootstrap process takes a while (minutes) to complete yet "juju bootstrap"<br>
returns after the bootstrap process is instantiated. The current expectation as<br>
I understand it is that users would then run "juju deploy xxx" (which will block<br>
until the bootstrap process is complete), or they can run "juju status" as a<br>
means to poll the bootstrap node to see if it is ready.<br>
<br>
I understand that an implementation goal of juju is to make things "just work"<br>
so that the user doesn't have to think too much and that running any command can<br>
be expected to complete successfully. While I agree with this principal, many<br>
users (myself included) want and expect more insight into the progress of any<br>
long running commands in order to be reassured that things are progressing as<br>
expected, and to be able to understand any errors which will occur despite best<br>
efforts.<br>
<br>
I am a novice juju user (even though I've obviously worked on the code, being a<br>
*user* of the product brings a very different perspective). Having used and<br>
developed many other products' UI previously, I have certain personal<br>
expectations and previous feedback from users as to how things "should" work.<br>
What follows are my personal thoughts, IMHO and all that.<br>
<br>
The issue I'm raising was highlighted to me when I was testing juju using HP<br>
Cloud and had bootstrapped a new environment. The bootstrap command returned<br>
without error but the bootstrap node was subsequently unusable (and hence so was<br>
the deployment) due to an as yet undetermined internal error starting the node<br>
properly. Running with debug I got info about uploading tools and finally a<br>
"started instance" message, but nothing further about the success or otherwise<br>
of the node startup. At this point, the process becomes a black hole and I'm<br>
forced to run "juju status" over and over to poll the node or try my luck<br>
running "juju deploy" and see what happens.<br>
<br>
What I would ideally have loved to have seen was some sort of progress<br>
indication as to how the bootstrap is progressing. Whether the bootstrap command<br>
should block or not until done can also be discussed, but I'd love to see at the<br>
least a series of "." (or even messages) printed to the console as the various<br>
bootstrap steps complete, and an error message when/if something in the startup<br>
process fails. I do feel that even though many (most?) users of juju may not<br>
care so much about the detailed internal mechanisations, they will be technical<br>
users of sorts and want a little more than just a Joe Average blackbox, totally<br>
opaque system. Or at least an option to get some sort of feedback on the<br>
progress of "background" commands that need to complete in order for the system<br>
to be usable.<br>
<br>
In my own bootstrap case, I have a theory as to what failed, but it's as yet<br>
only a theory and ssh'ing into the machine to inspect the logs didn't show too<br>
much about the root cause (to me). There were entries saying that logging in to<br>
the juju database failed, but why? Why was the correct password not used? What<br>
prevented it from being determined? etc It would be nice if we could do a better<br>
job here, in that given the node is broken, tell the user what the ultimate root<br>
cause is and what config or other tweaks are needed to fix it. And do so in such<br>
a way that it can be reported to the console from which the bootstrap command<br>
was invoked instead of forcing the user to ssh in and poke around the logs. Or<br>
have them be surprised when deploy doesn't work because bootstrap appeared to work.<br>
<br>
As a side note (remember, novice user here), I had to go to the HP Cloud web<br>
console to figure out the magic command options to ssh in to the node. It would<br>
be nice if when the node was started, it could be printed out the exact ssh<br>
command if need be. Or is there a "juju ssh" command which knows how to do the<br>
right thing for each provider/environment? If not, should there be?<br>
<br>
Ok, if you've got this far, congratulations, go get a life  Jokes aside, any<br>
and all opinions welcome.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- <br>Brandon Holtsclaw<br>Web <a href="http://brandonholtsclaw.com" target="_blank">http://brandonholtsclaw.com</a><br>Voice/SMS Tel:816-974-6106<br>

</div>