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. <div class="gmail_quote"><div dir="ltr">On Wed, Mar 16, 2016 at 9:17 AM roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16 March 2016 at 12:31, Kapil Thangavelu <<a href="mailto:kapilt@gmail.com" target="_blank">kapilt@gmail.com</a>> wrote: > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>> 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"? </blockquote></div>