Merge lp:~jimbaker/juju-jitsu/watch-subcommand into lp:juju-jitsu
Status: | Merged |
---|---|
Merge reported by: | Mark Mims |
Merged at revision: | not available |
Proposed branch: | lp:~jimbaker/juju-jitsu/watch-subcommand |
Merge into: | lp:juju-jitsu |
Diff against target: |
702 lines (+678/-0) 5 files modified
sub-commands/aiki/cli.py (+108/-0) sub-commands/aiki/twistutils.py (+20/-0) sub-commands/aiki/watcher.py (+277/-0) sub-commands/topodump (+31/-0) sub-commands/watch (+242/-0) |
To merge this branch: | bzr merge lp:~jimbaker/juju-jitsu/watch-subcommand |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Mark Mims (community) | Approve | ||
Review via email: mp+109438@code.launchpad.net |
Description of the change
Adds a new jitsu subcommand, watch. It directly uses the Juju API where possible, otherwise ZK, to wait for a set of conditions about a Juju environment to become true. It does not timeout, instead use the core timeout command if that is desired.
The help gives the full flavor of what can be done:
usage: watch [-h] [-e ENVIRONMENT]
[--any] [--number]
Watch Juju environment for condition(s) to become true, waiting as necessary.
Each condition is specified as follows:
INSTANCE Either service, relation, or service unit. For a
-n NUM, --num-units NUM
-r RELATION, --relation RELATION
--setting SETTING Relation setting exists
--state STATE State of unit or for at least all NUM units of service
--x-state STATE Cannot be in this state
[NAME=SETTING [NAME=SETTING ... ]]
optional arguments:
-h, --help show this help message and exit
-e ENVIRONMENT, --environment ENVIRONMENT
--loglevel CRITICAL|
--verbose, -v Enable verbose logging
--any Any of the conditions may be true
--number Number output by the corresponding condition
Examples of watches with single conditions:
$ relation_id=`jitsu watch "wordpress mysql"` # waits until relation available and prints id; must be quoted
$ relation_id=`jitsu watch "wordpress:db mysql:app"` # like above, but with fully specified descriptors
$ jitsu watch mysql # service is deployed
$ jitsu watch mysql/0 --state=started # unit is started
$ timeout 60s jitsu watch mysql/0 --state=started # watch up to 60s for mysql/0 to be running, using core timeout command
$ jitsu watch -r db:0 mysql/0 foo=bar # watch for foo to be set to bar on mysql/0 on relation id of db:0
$ jitsu watch mysql/0 -r "wordpress mysql" foo=bar # watch for wordpress<->mysql, then watch for this setting
$ jitsu watch mysql/0 -r db:0 foo= # watch for foo to be unset
$ jitsu watch mysql/0 -r db:0 --setting=foo # watch for foo to be set to *some* value
Multiple conditions can be combined:
$ jitsu watch mysql/0 -r "wordpress mysql" foo= mysql/1 -r "wordpress mysql" foo=bar # all conditions must apply
$ jitsu --any watch ... # any of the conditions may apply
looks great... does exactly what I need for testing