Merlin,
Adding a wrapper around juju action may have been the first juju
related code that I wrote.
function jujuaction {
time=$1
shift
echo juju action do $@
tmp=`juju action do "$@" |cut -f2 -d:`
printf "${tmp} "
while true; do
sleep $time
juju action status $tmp |grep -E "status: (pending|running)"
>/dev/null || break
printf "."
done
echo ""
juju action fetch $tmp
}
Looking at the help for juju I would ask/prefer that waiting for an
action or parsing a result would be done with new commands sent to juju
action.
usage: juju action [options] ...
purpose: execute, manage, monitor, and retrieve results of actions
options:
--description (= false)
-h, --help (= false)
show help on a command or other topic
"juju action" executes and manages actions on units; it queues up new
actions,
monitors the status of running actions, and retrieves the results of
completed
actions.
commands:
defined - show actions defined for a service
do - queue an action for execution
fetch - show results of an action by ID
help- show help on a command or other topic
status - show results of all actions filtered by optional ID prefix
wait - run an action and return all of the results
parse - run an action and return the results matching a result string or
dict
Example Usage:
juju action wait
juju action parse result=Œavg.latency'
Regards,
Matt Dirba
512.779.4696
>
>Message: 6
>Date: Wed, 9 Dec 2015 17:13:09 -0500
>From: Adam Stokes
>To: Merlijn Sebrechts
>Cc: juju
>Subject: Re: additional catering towards the application developer
>Message-ID:
>
>Content-Type: text/plain; charset="utf-8"
>
>Also there seems to be a couple of bugs relevant to this discussion:
>
>https://bugs.launchpad.net/juju-core/+bug/1445066
>https://bugs.launchpad.net/juju-core/+bug/1445078
>
>On Wed, Dec 9, 2015 at 5:09 PM, Adam Stokes
>wrote:
>
>> I agree, having the ability to run actions synchronously and wait for a
>> result would be a huge step in allowing charm authors to provide
>>actions
>> that can be used during the development of your application _before_ you
>> reach the stage of charming that app.
>>
>> Casey, made a suggestion of possibly making the actions more relevant to
>> the type of task it's running (background vs run-and-wait). For
>>example, to
>> launch an action in the background you could do `juju action launch
>>(begin,
>> start)` and to run an action immediately and wait for the result would
>>be
>> `juju action do` or even drop the word `action` and have it be `juju
>> launch` and `juju do`. Semantics aside though I think this would be an
>> excellent addition and first step for getting application developers
>> interested in bringing their application into the Juju ecosystem.
>>
>> On Wed, Dec 9, 2015 at 4:48 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> I've been thinking about the actions as well. 99% of the actions
>>>use-case
>>> is: Run the action, wait for it to finish and show the result. Most of
>>>the
>>> actions are things like 'restart', 'show-something',...
>>>
>>> I think waiting for the action to finish and show the result should be
>>> put in as a flag, with the possibility to become default in Juju2.
>>>
>>> - Juju 1: Add flag --wait
>>> - Juju 2: Make --wait default and add flag --no-wait
>>>
>>>
>>> What do you guys think? Is this what you had in mind, Adam?
>>>
>>> 2015-12-09 18:28 GMT+01:00 Adam Stokes :
>>>
I wanted to write this to get a discussion going around how we can
better
support application developers. This is something I've been thinking
about
for awhile and was further convinced to write this email after seeing
posts
like:
http://askubuntu.com/questions/635758/is-juju-a-suitable-tool-for-devel
opment-as-well-as-deployment
The scenario:
In its simplest form, I am writing a web application that needs a
database. I
would like to quickly startup a postgresql server and grab it's
connection
information.
How's its done with docker:
$ docker pull k0st/alpine-postgres
$ docker run --name myapp -e POSTGRES_USER=user -e
POSTGRES_PASSWORD=password -e POSTGRES_DB=testdb k0st/alpine-postgres
$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' myapp
172.16.0.5
From here you can build your connection string:
postgresql://user:password@172.16.0.5:5432/testdb
And now how we could possibly accomplish this with Juju today:
1. Using Juju actions:
$ juju deploy postgresql
$ juju action do postgresql/0 createdb username=user password=pass
database=testdb
Action queued with id 32432-432-432-432-432-432
$ juju action fetch 32432-432-432-432-432-432
.. Parse the results
message: "" # No error message.
results:
result-map:
connection_string:
