Planning for Juju 2.2 (16.10 timeframe)

[Kapil Thangavelu]

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.
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"?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160316/c52b1e87/attachment.html>