On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <m...@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, config schemas/validation, rich status. relation config is a huge boon to services that are multi-tenant to other services, as is the workaround is to create either copies per tenant or intermediaries. > *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. > > it maybe out of band, but with storage comes backups/snapshots. also of interest, is encryption on block and object storage using cloud native mechanisms where available. > > > *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 > Autoscaling, either tighter integration with cloud native features or juju provided abstraction.
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev