<div dir="ltr">A feature that I think would clean up the deployment of multi-charm bundles would be the ability to deploy directly to lxc containers without specifying or pre-adding a machine. <br><br>For example, in a juju on maas deployment, upon charm deploy, juju would query maas and request a new machine, but let maas choose the series. Once provisioned, juju would then create a lxc container with the required series for the charm being deployed. If maas reports that there are no machines available for allocation, then it will pick a current machine based on utilization and spawn the container there. <br><br>This would allow for greater and more seamless homogeneity of the deployed machines, and would help with the push for container-per-charm deployments that will be critical in enabling live migration of lxd containers.<br><div><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br style="color:rgb(136,136,136);font-size:12.8px"><div style="color:rgb(136,136,136);font-size:12.8px"><div dir="ltr"><div>William Forsyth</div><div><br></div><div>Infrastructure Administrator</div><div>Liferay, Inc.<br></div><div>Enterprise. Open Source. For life.</div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">From: Mark Shuttleworth <<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Date: Tue, Mar 8, 2016 at 6:52 PM<br>Subject: Planning for Juju 2.2 (16.10 timeframe)<br>To: juju <<a href="mailto:juju@lists.ubuntu.com" target="_blank">juju@lists.ubuntu.com</a>>, <a href="mailto:juju-dev@lists.ubuntu.com" target="_blank">juju-dev@lists.ubuntu.com</a> <<a href="mailto:juju-dev@lists.ubuntu.com" target="_blank">juju-dev@lists.ubuntu.com</a>><br></div><br><br>
<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<br>
<br>
Mark<br>
</font>
</div>
--<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>
</div></div>
</blockquote></div><br></div></div></div></div>