Just changed subject so we don't derail the 2.2 discussion. On Tue, Mar 29, 2016 at 6:27 PM Jacek Nykis <[email protected]> wrote:
> On 19/03/16 03:20, Andrew Wilkins wrote: > > 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. > > Good to hear, it's a simple documentation fix then. > > >> * 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. > > OK this makes sense. Documentation is really confusing on this subject. > I assumed that "location" was a pre existing local path for juju to use. > Assuming you're looking at the stable docs, take a look at devel and see if it helps at all. They were restructured and reworded because they were found to be a be confusing (first cut never really got translated from developerese into English). You'll find that here: https://jujucharms.com/docs/devel/charms-storage and here: https://jujucharms.com/docs/devel/developer-storage If juju will manage filesystem what's the point in having "location" > option? Paths can be easily autogenerated and that would remove need to > hardcode paths in metadata.yaml > It's only there in case your charmed application expects to find things in a specific location. Having a predefined location makes charming storage a bit easier in those cases. In general, though, you shouldn't need to specify a location. In fact, it's harmful if not done correctly, because then you're prone to collisions with other charms. > > * 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. > > I am glad to hear it's just docs. I'll be happy to review them when > fixed just let me know when it's done > Great, I'll try to keep that in mind. Take a look at the devel docs some time and see if you still find them confusing. Cheers, Andrew
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
