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.pe...@canonical.com> wrote:
> On 16 March 2016 at 12:31, Kapil Thangavelu <kap...@gmail.com> wrote: > > > > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <m...@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-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
