Planning for Juju 2.2 (16.10 timeframe)

[Tom Barber]

Couple of new things cropped up today that would be very useful.

a) actions within gui, currently its a bit weird to drag stuff around in
the gui then drop to shell to run actions. Doesn't make much sense to a
user.
b) actions within bundles. For example, I'd like a few "standard" bundles,
but also a demo bundle seeded with sample data, to do this I'd need to run
some actions behind the scenes to get the stuff in place which I can't do
c) upload files with actions. Currently for some things I need to pass in
some files then trigger an action on the unit upon that file. It would be
good to say path=/tmp/myfile.xyz and have the action upload that to a place
you define.

Tom

--------------

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 16 March 2016 at 16:03, roger peppe <roger.peppe at canonical.com> wrote:

> On 16 March 2016 at 15:04, Kapil Thangavelu <kapilt at gmail.com> wrote:
> > Relations have associated config schemas that can be set by the user
> > creating the relation. I.e. I could run one autoscaling service and
> > associate with relation config for autoscale options to the relation
> with a
> > given consumer service.
>
> Great, I hoped that's what you meant.
> I'm also +1 on this feature - it would enable all kinds of useful
> flexibility.
>
> One recent example I've come across that could use this feature
> is that we've got a service that can hand out credentials to services
> that are related to it. At the moment the only way to state that
> certain services should be handed certain classes of credential
> is to have a config value that holds a map of service name to
> credential info, which doesn't seem great - it's awkward, easy
> to get wrong, and when a service goes away, its associated info
> hangs around.
>
> Having the credential info associated with the relation itself would be
> perfect.
>
> >
> > On Wed, Mar 16, 2016 at 9:17 AM roger peppe <roger.peppe at canonical.com>
> > wrote:
> >>
> >> On 16 March 2016 at 12:31, Kapil Thangavelu <kapilt at gmail.com> wrote:
> >> >
> >> >
> >> > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <mark at ubuntu.com>
> >> > wrote:
> >> >>
> >> >> Hi folks
> >> >>
> >> >> We're starting to think about the next development cycle, and
> gathering
> >> >> priorities and requests from users of Juju. I'm writing to outline
> some
> >> >> current topics and also to invite requests or thoughts on relative
> >> >> priorities - feel free to reply on-list or to me privately.
> >> >>
> >> >> An early cut of topics of interest is below.
> >> >>
> >> >> Operational concerns
> >> >>
> >> >> * LDAP integration for Juju controllers now we have multi-user
> >> >> controllers
> >> >> * Support for read-only config
> >> >> * Support for things like passwords being disclosed to a subset of
> >> >> user/operators
> >> >> * LXD  container migration
> >> >> * Shared uncommitted state - enable people to collaborate around
> >> >> changes
> >> >> they want to make in a model
> >> >>
> >> >> There has also been quite a lot of interest in log control - debug
> >> >> settings for logging, verbosity control, and log redirection as a
> >> >> systemic
> >> >> property. This might be a good area for someone new to the project to
> >> >> lead
> >> >> design and implementation. Another similar area is the idea of
> >> >> modelling
> >> >> machine properties - things like apt / yum repositories, cache
> settings
> >> >> etc,
> >> >> and having the machine agent setup the machine / vm / container
> >> >> according to
> >> >> those properties.
> >> >>
> >> >
> >> > ldap++. as brought up in the user list better support for aws best
> >> > practice
> >> > credential management, ie. bootstrapping with transient credentials
> (sts
> >> > role assume, needs AWS_SECURITY_TOKEN support), and instance role for
> >> > state
> >> > servers.
> >> >
> >> >
> >> >>
> >> >> Core Model
> >> >>
> >> >>  * modelling individual services (i.e. each database exported by the
> db
> >> >> application)
> >> >>  * rich status (properties of those services and the application
> >> >> itself)
> >> >>  * config schemas and validation
> >> >>  * relation config
> >> >>
> >> >> There is also interest in being able to invoke actions across a
> >> >> relation
> >> >> when the relation interface declares them. This would allow, for
> >> >> example, a
> >> >> benchmark operator charm to trigger benchmarks through a relation
> >> >> rather
> >> >> than having the operator do it manually.
> >> >>
> >> >
> >> > in priority order, relation config
> >>
> >> What do you understand by the term "relation config"?
>
> --
> 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/20160318/67894c03/attachment.html>