Planning for Juju 2.2 (16.10 timeframe)

[Mark Shuttleworth]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160308/259a8eaa/attachment.html>