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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
