<div dir="ltr"><div class="gmail_quote"><div>Just changed subject so we don't derail the 2.2 discussion.</div><div dir="ltr"><br></div><div dir="ltr">On Tue, Mar 29, 2016 at 6:27 PM Jacek Nykis <<a href="mailto:jacek.nykis@canonical.com">jacek.nykis@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19/03/16 03:20, Andrew Wilkins wrote:<br>
> It seems like the issues you've noted below are all documentation issues,<br>
> rather than limitations in the implementation. Please correct me if I'm<br>
> wrong.<br>
><br>
><br>
>> If we come up with sensible defaults for different providers we could<br>
>> make end users' experience even better by making --storage-type optional<br>
>><br>
><br>
> Storage type is already optional. If you omit it, you'll get the provider<br>
> default. e.g. for AWS, that's EBS magnetic disks.<br>
<br>
Good to hear, it's a simple documentation fix then.<br>
<br>
>> * it would be good to have ability to use single storage stanza in<br>
>> metadata.yaml that supports all types of storage. They way it is done<br>
>> now [0] means I can't test block storage hooks in my local dev<br>
>> environment. It also forces end users to look for storage labels that<br>
>> are supported<br>
>><br>
>> [0] <a href="http://paste.ubuntu.com./15414289/" rel="noreferrer" target="_blank">http://paste.ubuntu.com./15414289/</a><br>
><br>
><br>
> Not quite sure what you mean here. If you have a "filesystem" type, you can<br>
> use any storage provider that supports natively creating filesystems (e.g.<br>
> "tmpfs") or block devices (e.g. "ebs"). If you specify the latter, Juju<br>
> will manage the filesystem on the block device.<br>
<br>
OK this makes sense. Documentation is really confusing on this subject.<br>
I assumed that "location" was a pre existing local path for juju to use.<br></blockquote><div><br></div><div>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:</div><div>    <a href="https://jujucharms.com/docs/devel/charms-storage">https://jujucharms.com/docs/devel/charms-storage</a><br></div><div>and here:</div><div>    <a href="https://jujucharms.com/docs/devel/developer-storage">https://jujucharms.com/docs/devel/developer-storage</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If juju will manage filesystem what's the point in having "location"<br>
option? Paths can be easily autogenerated and that would remove need to<br>
hardcode paths in metadata.yaml<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> * the way things are now hooks are responsible for creating filesystem<br>
>> on block devices. I feel that as a charmer I shouldn't need to know that<br>
>> much about storage internals. I would like to ask juju and get<br>
>> preconfigured path back. Whether it's formatted and mounted block<br>
>> device, GlusterFS or local filesystem it should not matter<br>
><br>
><br>
> That is exactly what it does, so again, I think this is an issue of<br>
> documentation clarity. If you're using the "filesystem" type, Juju will<br>
> create the filesystem; if you use "block", it won't.<br>
<br>
I am glad to hear it's just docs. I'll be happy to review them when<br>
fixed just let me know when it's done<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Andrew</div></div></div>