Planning for Juju 2.2 (16.10 timeframe)

Jacek Nykis jacek.nykis at canonical.com
Fri Apr 1 15:13:10 UTC 2016


On 01/04/16 14:34, Mark Shuttleworth wrote:
> 
>> * 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.

I think it's possible to handle all scenarios nicely.

For charms with just one store only require "--storage-size" and DTRT

For charms with multiple stores require "--store" parameter on top of
that. If not given error with "This charm supports more than one store,
please specify"

For charms without storage support when users provide one of storage
options error with "Storage not supported"

And for charms that do support storage but users don't ask for it print
something like "This charm supports storage, you can try it with --size
10G option"

>>  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 :)

I was thinking about defaults for block device backed storage. We could
allow users to skip "ebs-ssd" and pick the most sensible store type for
every supported cloud. And for clouds which support just one block
storage type use that automatically without need to specify anything.

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

It's my bad, I misunderstood how things worked, you can ignore this
point. Andrew Wilkins helpfully explained things to me earlier in this
thread (thanks Andrew)

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

Sorry this was also me misunderstanding things, Andrew already clarified
them for me (thanks again)

Jacek



More information about the Juju mailing list