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
signature.asc
Description: OpenPGP digital signature
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
