Users not told when deploy actually completes

Reported by Jonathan Lange on 2012-06-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pyjuju
Wishlist
Unassigned

Bug Description

When deploying a service, the 'juju deploy' command completes very quickly. However, the service isn't actually deployed at that time. If you want to do something _locally_ once the service is deployed, you have to run 'juju status' over and over until you can see that it's deployed. This wastes time and attention.

This is particularly painful during charm development, as you do many, many deploys to test changes to a charm. Imagine having to poll to see if test run had completed?

It would be great if there were some way of getting Juju to notify the user that the deploy had been finished.

Jonathan Lange (jml) wrote :

Two ways I can think of:

 * a blocking version of (or option to) the 'deploy' command
 * have the deploy command send out some sort of event, perhaps even using Ubuntu's notification system

summary: - Users told when deploy actually completes
+ Users not told when deploy actually completes
Jonathan Lange (jml) on 2012-06-20
description: updated
William Reade (fwereade) wrote :

Depending on precisely what you're doing, you may find that `juju upgrade-charm` is a quicker way to iterate on a charm you;re developing.

Clint Byrum (clint-fewbar) wrote :

Note that juju-jitsu has a helpful command to simulate this:

$ jitsu watch john/0 -e local --state=started
2012-06-20 12:53:52,934 watch:INFO Waiting for unit john/0...
2012-06-20 12:53:52,946 watch:INFO Waiting for unit john/0 to be in ['started'] and not in []

I think this bug is really important though, and needs an answer at some point. The resolution I think would be:

* jitsu watch seems useful, lets put that in core
* we also need compound commands. If I could do

$ juju -c 'deploy foo; watch foo/0 --state=started'

Then I could simulate the desired effect.
* Finally I think all commands should have a defined "complete" state, and then a --wait flag. So

$ juju deploy foo --wait
... do something which interrogates foo
$ juju set foo tuning-parameter=x --wait
... verify tuning-parameter is set to x and had desired effect

Changed in juju:
status: New → Confirmed
importance: Undecided → Wishlist
Jonathan Lange (jml) wrote :

Hey Clint,

I very much agree with your "finally" (give commands a '--wait' option). Will try out jitsu watch for the moment.

jml

On 20 June 2012 17:53, William Reade <email address hidden> wrote:
> Depending on precisely what you're doing, you may find that `juju
> upgrade-charm` is a quicker way to iterate on a charm you;re developing.
>

When it's still at the point of 'install' not working, upgrade-charm
doesn't seem to be that useful.

$ juju upgrade-charm --repository=charms libdep-service
2012-06-21 11:38:58,249 INFO Setting
/home/jml/src/libdep-service/charms/precise/libdep-service to revision
7
2012-06-21 11:38:58,294 INFO Unit 'libdep-service/7' is not in a
running state (state: 'install_error'), won't upgrade
2012-06-21 11:38:58,294 INFO 'upgrade_charm' command finished successfully

So I'm iterating on 'destroy-service', 'deploy -u' and then watching
'debug-log'.

jml

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers