additional catering towards the application developer

[Adam Stokes]

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.sebrechts at 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 <adam.stokes at canonical.com>:
>
>> 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-development-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: postgresql://user:pass@
>> <unit-public-address>:5432/testdb
>>     message: Hello world!
>>   outcome: success
>> status: completed
>>
>> 2. Adding support in the charm hook (config-changed)
>>
>> $ juju deploy postgresql
>> $ juju set postgresql "createdb=user:pass:dbname"
>>
>> .. config-changed
>>
>> status-set "active", "db created:
>> postgresql://user:pass@unit-public-address:5432/dbname"
>>
>> $ juju status postgresql
>>
>> Look for the status message in the output.
>>
>> As you can tell between docker and juju we're still looking at 3 commands
>> for
>> just standing a database up, creating the db, and getting its connection
>> details.
>>
>> It would be really nice if I could just do:
>>
>> $ juju deploy postgresql
>> $ juju postgresql create-db --username=user --password=pass
>> --database=mydb
>>
>> # Default to json output for our application to consume and make use of
>> {"error": "", "result": "postgresql://user:pass@unit-public-address
>> :5432/mydb"}
>>
>> Even an action would still be ok if the action would print the results to
>> stdout
>> $ juju action do postgresql/0 create-db username=user password=pass
>> database=mydb
>> {"error": "", "result": "postgresql://user:pass@unit-public-address
>> :5432/mydb"}
>>
>> For me, personally, I don't want to use docker or vagrant or any other
>> tool as
>> I feel Juju is fully capable of catering to the application developer.
>>
>> Thoughts?
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151209/99c6bb07/attachment.html>