Planning for Juju 2.2 (16.10 timeframe)

[roger peppe]

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"?