Planning for Juju 2.2 (16.10 timeframe)

Fri Apr 1 16:24:25 UTC 2016

* Resource Management :
  ** GPU:
>From a very operational perspective, as GPUs become more widely available
across clouds, having a way to constrain/schedule them would be
interesting.

  ** Mapping to constraints
When colocating services, one could want to drive Juju to make clever
decisions to make sure resources are available to them. That is to say
expand the --to command to map specific machine constraints (such as --to
"cpu-cores>4"), similarly to cgroup constraints for containers.

* Monitoring / Logging / Support Tools:
Stuart made a good point on the relation for "support services" like
logging / monitoring...
I think the monitoring tools should be clever enough they recon where they
run and adapt, and users shall be free to use whichever. However the
subordinate relation is really cumbersome.

Quick win, a flag such as "juju deploy --to all <foo>" would make sense.

Alternatively, IT tools really are really attributes / meta-services of a
user's models. When one selects to run Logstash, one make that decision
globally, for all existing and future nodes and services. Therefore,
* juju enable logstash <--model foo> <--cloud bar> --all : this deploys
logstash agents to all nodes from one or more models / cloud instances....
Furthermore, as the model expands, new units would then automagically get
the support service enabled (deploy + relate)
* juju add-relation logstash < other service or json config>: this other
command inherited from the classic relates to either another charm
(elasticsearch) or provide "fake relation data" to connect to an external
service (proxy charm also possible) that is non juju driven (SaaS)

* UX
  ** Tags
One feature I really really love on Google Cloud Platform is the ability to
tag pretty much any and everything to my own vocabulary. I would love the
ability to tag charms to functional layers of my choice (middleware, front
end, back end...), to then be able to filter them efficiently.
  ** Filters
If I run a vast model, with many units of many types, I would love the
ability to filter the status by the tags I have, and not only by names.

Best,
Sam

--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> / Juju
<https://jujucharms.com>
samuel.cozannet at canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]
<https://es.linkedin.com/in/scozannet>

On Wed, Mar 9, 2016 at 12:51 AM, Mark Shuttleworth <mark at 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.
>
>
>
> *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
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160401/3bd28401/attachment.html>