<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Ubuntu">Hi folks<br>
<br>
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.<br>
<br>
An early cut of topics of interest is below.<br>
<br>
<b>Operational concerns<br>
<br>
</b>* LDAP integration for Juju controllers now we have multi-user
controllers<br>
* Support for read-only config<br>
* Support for things like passwords being disclosed to a subset of
user/operators<br>
* LXD container migration<br>
* Shared uncommitted state - enable people to collaborate around
changes they want to make in a model<br>
<br>
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.<br>
<br></font></div></blockquote><div><br></div><div>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.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font face="Ubuntu">
<b>Core Model<br>
<br>
</b> * modelling individual services (i.e. each database exported
by the db application)<br>
* rich status (properties of those services and the application
itself)<br>
* config schemas and validation<br>
* relation config<br>
<br>
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.<br>
<br></font></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font face="Ubuntu">
<b>Storage</b><br>
<br>
* shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts)<br>
* object storage abstraction (probably just mapping to
S3-compatible APIS)<br>
<br>
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.<br>
<br></font></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font face="Ubuntu">
<br>
<b>Clouds and providers<br>
</b><br>
* System Z and LinuxONE<br>
* Oracle Cloud<br>
<br>
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.<br>
<br>
<br>
<b>Usability<br>
<br>
</b> * expanding the set of known clouds and regions<br>
* improving the handling of credentials across clouds</font></div></blockquote><div><br></div><div><br></div><div>Autoscaling, either tighter integration with cloud native features or juju provided abstraction.</div><div> </div></div></div></div>