juju command progress ui

Wed Feb 27 16:23:09 UTC 2013

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.

'juju status' will tell you the status of each service, node, and machines.

... as far as progress and debugging, I think what your looking for is
'juju debug-log'

... as far as ssh I think what your looking for is 'juju ssh service/node'
e.g. 'juju ssh mysql/0'

IIRC this should all be covered in the Documentation pretty well, is there
areas you can see to make it clearer/improvements ?

On Tue, Feb 26, 2013 at 7:48 PM, Ian Booth <ian.booth at canonical.com> wrote:

>
>
> We discussed thus issue in the recent weekly juju meeting and agreed to
> move the
> conversation to the list.
>
> TL;DR; - what feedback should (long running, background) juju commands
> provide
>
> The topic of conversation resolves around how/if we should provide visible
> feedback to the user about the progress of juju commands. The issue arose
> when
> we were discussing the behaviour of the bootstrap command in particular.
> The
> bootstrap process takes a while (minutes) to complete yet "juju bootstrap"
> returns after the bootstrap process is instantiated. The current
> expectation as
> I understand it is that users would then run "juju deploy xxx" (which will
> block
> until the bootstrap process is complete), or they can run "juju status" as
> a
> means to poll the bootstrap node to see if it is ready.
>
> I understand that an implementation goal of juju is to make things "just
> work"
> so that the user doesn't have to think too much and that running any
> command can
> be expected to complete successfully. While I agree with this principal,
> many
> users (myself included) want and expect more insight into the progress of
> any
> long running commands in order to be reassured that things are progressing
> as
> expected, and to be able to understand any errors which will occur despite
> best
> efforts.
>
> I am a novice juju user (even though I've obviously worked on the code,
> being a
> *user* of the product brings a very different perspective). Having used and
> developed many other products' UI previously, I have certain personal
> expectations and previous feedback from users as to how things "should"
> work.
> What follows are my personal thoughts, IMHO and all that.
>
> The issue I'm raising was highlighted to me when I was testing juju using
> HP
> Cloud and had bootstrapped a new environment. The bootstrap command
> returned
> without error but the bootstrap node was subsequently unusable (and hence
> so was
> the deployment) due to an as yet undetermined internal error starting the
> node
> properly. Running with debug I got info about uploading tools and finally a
> "started instance" message, but nothing further about the success or
> otherwise
> of the node startup. At this point, the process becomes a black hole and
> I'm
> forced to run "juju status" over and over to poll the node or try my luck
> running "juju deploy" and see what happens.
>
> What I would ideally have loved to have seen was some sort of progress
> indication as to how the bootstrap is progressing. Whether the bootstrap
> command
> should block or not until done can also be discussed, but I'd love to see
> at the
> least a series of "." (or even messages) printed to the console as the
> various
> bootstrap steps complete, and an error message when/if something in the
> startup
> process fails. I do feel that even though many (most?) users of juju may
> not
> care so much about the detailed internal mechanisations, they will be
> technical
> users of sorts and want a little more than just a Joe Average blackbox,
> totally
> opaque system. Or at least an option to get some sort of feedback on the
> progress of "background" commands that need to complete in order for the
> system
> to be usable.
>
> In my own bootstrap case, I have a theory as to what failed, but it's as
> yet
> only a theory and ssh'ing into the machine to inspect the logs didn't show
> too
> much about the root cause (to me). There were entries saying that logging
> in to
> the juju database failed, but why? Why was the correct password not used?
> What
> prevented it from being determined? etc It would be nice if we could do a
> better
> job here, in that given the node is broken, tell the user what the
> ultimate root
> cause is and what config or other tweaks are needed to fix it. And do so
> in such
> a way that it can be reported to the console from which the bootstrap
> command
> was invoked instead of forcing the user to ssh in and poke around the
> logs. Or
> have them be surprised when deploy doesn't work because bootstrap appeared
> to work.
>
> As a side note (remember, novice user here), I had to go to the HP Cloud
> web
> console to figure out the magic command options to ssh in to the node. It
> would
> be nice if when the node was started, it could be printed out the exact ssh
> command if need be. Or is there a "juju ssh" command which knows how to do
> the
> right thing for each provider/environment? If not, should there be?
>
> Ok, if you've got this far, congratulations, go get a life  Jokes aside,
> any
> and all opinions welcome.
>
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
-- 
Brandon Holtsclaw
Web http://brandonholtsclaw.com
Voice/SMS Tel:816-974-6106
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130227/f9d4f802/attachment.html>