Planning for Juju 2.2 (16.10 timeframe)

[roger peppe]

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