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 <adam.sto...@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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju