Planning for Juju 2.2 (16.10 timeframe)

[Andrew Wilkins]

On Sat, Mar 19, 2016 at 12:53 AM Jacek Nykis <jacek.nykis at canonical.com>
wrote:

> On 08/03/16 23:51, Mark Shuttleworth wrote:
> > *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.
>
> Hi Mark,
>
> I took juju storage for a spin a few weeks ago. It is a great idea and
> I'm sure it will simplify our models (no more need for
> block-storage-broker and storage charms). It will also improve security
> because block-storage-broker needs nova credentials to work
>
> I only played with storage briefly but I hope my feedback and ideas will
> be useful
>
> * IMO it would be incredibly useful to have storage lifecycle
> management. Deploying a new database using pre-existing block device you
> mentioned would certainly be nice. Another scenario could be users who
> deploy to local disk and decide to migrate to block storage later
> without redeploying and manual data migration
>
>

> One day we may even be able to connect storage with actions. I'm
> thinking "storage snapshot" action followed by juju deploy to create up
> to date database clone for testing/staging/dev
>
> * I found documentation confusing. It's difficult for me to say exactly
> what is wrong but I had to read it a few times before things became
> clear. I raised some specific points on github:
> https://github.com/juju/docs/issues/889
>
> * cli for storage is not as nice as other juju commands. For example we
> have the in the docs:
>
> juju deploy cs:~axwalk/postgresql --storage data=ebs-ssd,10G pg-ssd
>
> I suspect most charms will use single storage device so it may be
> possible to optimize for that use case. For example we could have:
>
> juju deploy cs:~axwalk/postgresql --storage-type=ebs-ssd --storage-size=10G
>

It seems like the issues you've noted below are all documentation issues,
rather than limitations in the implementation. Please correct me if I'm
wrong.


> If we come up with sensible defaults for different providers we could
> make end users' experience even better by making --storage-type optional
>

Storage type is already optional. If you omit it, you'll get the provider
default. e.g. for AWS, that's EBS magnetic disks.


> * it would be good to have ability to use single storage stanza in
> metadata.yaml that supports all types of storage. They way it is done
> now [0] means I can't test block storage hooks in my local dev
> environment. It also forces end users to look for storage labels that
> are supported
>
> [0] http://paste.ubuntu.com./15414289/


Not quite sure what you mean here. If you have a "filesystem" type, you can
use any storage provider that supports natively creating filesystems (e.g.
"tmpfs") or block devices (e.g. "ebs"). If you specify the latter, Juju
will manage the filesystem on the block device.

* the way things are now hooks are responsible for creating filesystem
> on block devices. I feel that as a charmer I shouldn't need to know that
> much about storage internals. I would like to ask juju and get
> preconfigured path back. Whether it's formatted and mounted block
> device, GlusterFS or local filesystem it should not matter


That is exactly what it does, so again, I think this is an issue of
documentation clarity. If you're using the "filesystem" type, Juju will
create the filesystem; if you use "block", it won't.

If you could provide more details on what you're doing (off list, I think
would be best), I can try and help. We can then feed back into the docs to
make it clearer.

Cheers,
Andrew

* finally I hit 2 small bugs:
>
> https://bugs.launchpad.net/juju-core/+bug/1539684
> https://bugs.launchpad.net/juju-core/+bug/1546492



>
>
> If anybody is interested in more details just ask, I'm happy to discuss
> or try things out just note that I will be off next week so will most
> likely reply on 29th
>
>
> Regards,
> Jacek
>
> --
> 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-dev/attachments/20160319/b4d8006f/attachment.html>