Planning for Juju 2.2 (16.10 timeframe)

[Jacek Nykis]

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

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

* 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/

* 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

* 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160318/ba7d42bc/attachment.pgp>