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" <[email protected]> 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 <[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
