Planning for Juju 2.2 (16.10 timeframe)

[Mark Shuttleworth]

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

That, however, means you still have to know IF there's only one store.
Or you have to know what the default store is. Better to just be explicit.

>  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

What would sensible defaults look like for storage? The default we have
is quite sensible, you get the root filesystem :)


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

I'm not sure what the issue is with this one.

If we have filesystem storage it's always at the same place.

If we have a single mounted block store, it's always at the same place.

If we can attach multiple block devices, THEN you need to handle them as
they are attached.

Can you explain the problem more clearly? We do have an issue with the
LXD provider and block devices, which we think will be resolved thanks
to some good kernel work on a range of fronts, but that can't surely be
what's driving your concerns.


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

Well, yes, that's the idea, but these things are quite subtle.

In some cases you very explicitly want the raw block. So we have to
allow that. In other cases you just want a filesystem there, and IIRC
that's the default behaviour in the common case. Finally, we have to
deal with actual network filesystems (as opposed to block devices) and I
don't think we have implemented that yet.

Mark

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