Hi Mark, As I have been promised during MWC show to write the ideas here, let me describe when and how it seems to me YANG(RFC6020) can be useful in Juju world.
The juju bundle is nice way to model the application topologies, relations - give ability to generate to relational part of configuration for the applications (f.e. what mysql table structure will be needed to make workspace working, etc). The juju itself give us ability to install/change/uninstall the applications via charm hooks to run the deterministic finite automaton algorithm for It and all works nice and good. But if try to look further… What if we will have the data model for the configuring services, it will allow us to have ability to abstract the configuration, with this model and base on it make needed mapping to the actual config for different services. Using that we will have an ability to make/model not only bundles or set of applications, but also topology of the set of running units(instances), that will allow to make more complex bundles possible… just an idea … may be you have some thoughts toward this direction ? _________________________ Regards, Evgeny Zobnitsev Factor group Moscow, Russia phone: +74952803380 ext. 2209 mobile: +79161417041 e-mail: [email protected] <mailto:[email protected]> > On 09 Mar 2016, at 02: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
