<p dir="ltr">Also, for stuff like monitoring, being able to position a charm service on a different service provider to bolster resiliency. </p>
<p dir="ltr">Tom</p>
<div class="gmail_quote">On 8 Mar 2016 23:59, "Tom Barber" <<a href="mailto:tom@analytical-labs.com">tom@analytical-labs.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark <div><br></div><div>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. </div><div><br></div><div>Cheers</div><div><br></div><div>Tom</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">--------------<div><br></div><div><div style="font-size:small"><font color="#999999">Director Meteorite.bi - Saiku Analytics Founder</font></div><div style="font-size:small"><font color="#999999">Tel: <a href="tel:%2B44%280%295603641316" value="+445603641316" target="_blank">+44(0)5603641316</a> </font></div><div style="font-size:small"><font color="#999999"><br></font></div><div style="font-size:small"><font color="#999999">(Thanks to the Saiku community we reached our <a href="http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/" target="_blank">Kickstart</a> goal, but you can always help by <a href="http://www.meteorite.bi/products/saiku/sponsorship" target="_blank">sponsoring the project</a>)</font></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 8 March 2016 at 23:51, 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>
<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>
<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>
<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<span><font color="#888888"><br>
<br>
Mark<br>
</font></span></font>
</div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div>
</blockquote></div>