Planning for Juju 2.2 (16.10 timeframe)

[Tom Barber]

Also, for stuff like monitoring,  being able to position a charm service on
a different service provider to bolster resiliency.

Tom
On 8 Mar 2016 23:59, "Tom Barber" <tom at analytical-labs.com> wrote:

> Hi Mark
>
> From my perspective relationship joins that can span models would be
> great. I know I brought it up before, but being able to create, for example
> a central monitoring model, or central Gitlab model that charms in my
> various other models could tap into without them being merged into a "super
> model" or maybe be in different regions on different controllers, would be
> great.
>
> Cheers
>
> Tom
>
> --------------
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 8 March 2016 at 23:51, 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.
>>
>>
>>
>> *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.
>>
>> *Storage*
>>
>>  * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts)
>>  * object storage abstraction (probably just mapping to S3-compatible
>> APIS)
>>
>> I'm interested in feedback on the operations aspects of storage. For
>> example, whether it would be helpful to provide lifecycle management for
>> storage being re-assigned (e.g. launch a new database application but reuse
>> block devices previously bound to an old database  instance). Also, I think
>> the intersection of storage modelling and MAAS hasn't really been explored,
>> and since we see a lot of interest in the use of charms to deploy
>> software-defined storage solutions, this probably will need thinking and
>> work.
>>
>>
>>
>> *Clouds and providers *
>>  * System Z and LinuxONE
>>  * Oracle Cloud
>>
>> There is also a general desire to revisit and refactor the provider
>> interface. Now we have seen many cloud providers get done, we are in a
>> better position to design the best provider interface. This would be a
>> welcome area of contribution for someone new to the project who wants to
>> make it easier for folks creating new cloud providers. We also see constant
>> requests for a Linode provider that would be a good target for a refactored
>> interface.
>>
>>
>>
>>
>> *Usability * * expanding the set of known clouds and regions
>>  * improving the handling of credentials across clouds
>>
>> Mark
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160309/8e25b42a/attachment.html>