Planning for Juju 2.2 (16.10 timeframe)

Thu Mar 31 05:50:06 UTC 2016

On Mar 29, 2016 3:47 AM, "William (Will) Forsyth" <
william.forsyth at liferay.com> wrote:

> 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.
>

I'm not sure of the details of bundles, but I believe today you can do
"juju deploy --to lxc:" (and soon it will be changing to --to lxd:) Leaving
off the machine number has Juju allocate a new machine.

>
> 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.
>
> 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.
>
>
Unfortunately capacity planning gets us much more into AI/application
specific territory. What is currently Idle may just be because production
hasn't been exposed to the world yet. So all your Nova Compute nodes look
completely idle, but they'll be heavily loaded with user VMs.  Or your
Production Database machine doesn't have load yet.
This is where Juju is *intentionally* workload agnostic and wants to make
it easy for 3rd party applications to bring their own intelligence into the
system. Things like the Openstack Autopilot that understands what the
actual charms and workloads running are, can leverage Juju to orchestrate
the deployment.
We have had some discussions about "stacks" or charm brains, or something
along those lines to allow the charms themselves to provide understanding
of the workload back into the system. This might be something to focus on
in the 2.2 timeline. At the very least first steps of this where when Juju
is trying to make a decision (such as placement), we could have registered
3rd parties that we will consult to see if they have  an answer for us.

John
=:->

>
> William Forsyth
>
> Infrastructure Administrator
> Liferay, Inc.
> Enterprise. Open Source. For life.
>
> From: Mark Shuttleworth <mark at ubuntu.com>
>
>> Date: Tue, Mar 8, 2016 at 6:52 PM
>> Subject: Planning for Juju 2.2 (16.10 timeframe)
>> To: juju <juju at lists.ubuntu.com>, juju-dev at lists.ubuntu.com <
>> juju-dev at lists.ubuntu.com>
>>
>>
>> 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
>>
>
>
> --
> 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/20160331/2b2cc498/attachment.html>