Storage documentation (Was "Re: Planning for Juju 2.2 (16.10 timeframe)")

[Andrew Wilkins]

Just changed subject so we don't derail the 2.2 discussion.

On Tue, Mar 29, 2016 at 6:27 PM Jacek Nykis <jacek.nykis at canonical.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160329/8fd2f0a2/attachment.html>