Volume Management - NFS Charm

[William Reade]

On Sun, Nov 17, 2013 at 7:17 PM, David Britton
<david.britton at canonical.com>wrote:

> 2) A storage subordinate charm.
>
> E.g., swift-storage
>
> You would add this subordinate to the NFS service, and it would have the
> smarts to mount the block device at an agreed-upon location.
>
> The disadvantages involve waiting on the subordinate before the NFS charm
> is generally useful.  I'm not sure how the mechanics of this would work.
>

FWIW, this is not unique to the storage solution -- in the general case,
any given charm must be prepared to deal with a related service that's not
actually ready yet.

I think it's perfectly reasonable to write a principal with a
require-mount-storage config option, that when set causes all other hooks
to detect the lack of a fully-configured storage relation and defer their
work until one is present (you can hang arbitrary logic off the
storage-relation-changed hook, and either read in deferred actions
previously stored in the charm directory... or just figure them out at
storage-relation-changed-time, based on relation state once the storage is
ready).

Having to write this sort of logic is a little tedious, I agree, but I also
think it's necessary to use juju to its full potential -- to be really
useful, it's necessary that charms be capable of reacting to changes in
their environment and/or configuration rather than relying on being correct
initial setup. That said, a charm can still be useful without this
capability; but I'd expect the really successful charms to be those that
are most robust in the face of runtime change, and for most charms to
gradually evolve in this direction as they mature.

For storage, in particular, this goal is tricky to accomplish -- one can
imagine a particular service being out of action for an arbitrarily long
time while it works on transferring its data from one storage backend to
another -- but it's essentially the same problem as rebalancing peers when
units are added. We *don't* have a good built-in story here, and I'm keen
to discuss what juju should expose to make these scenarios easier to handle
-- because it's useful functionality independent of storage.


> I really don't like either of the things I'm proposing, and was wondering
> what others thought about these ideas.  Have you had any brainstorms about
> it?  Have you come up with something better to try out?
>

Right now, I'd go with a subordinate that sets everything up in the start
hook, so that at least it's guaranteed to be available when the principal
joins the relation; principals using that relation can (if suitably
configured -- just a bool) wait until storage is ready before they start to
work. You can't stop principals from participating in the system before
their storage is ready to use, but this is no different from any other
existing case in which a unit's mere presence in a relation does not
guarantee that the unit is actually in a state of perfect readiness.


> Please let me know.  This seems to be a big missing puzzle piece in
> practical juju usage right now, and I would love to hear others thoughts
> (since I may be missing something).
>

I'm always reluctant to add complexity to the metadata, but it may be
reasonable to consider the "required" relation field in this light. It's
not very expressive at the moment (consider a node-app charm that can use
either mongodb or postgres -- *one* of those is (probably) required, but
using *both* probably indicates some degree of confusion on the user's
part, and we can't express this). So that's not adequate as it stands, and
making it so

If we could come up with a clean way of expressing dependencies between
relations within a service, such that a charm only enters its provider
relations once its various requirer-requirements are satisfied, we could
make the initial-setup story very clean; but it wouldn't help much in the
more general case, in which someone might add a storage subordinate (or,
equivalently in the single-charm case, change storage config parameters) at
runtime. The obvious answer is to allow a unit that moves into an "unready"
state to signal its (hopefully temporary) departure to the rest of the
system, just as (when it came up unready) joining could be deferred until
readiness.

Does any of this help at all?

Cheers
William

PS FWIW, I'm never entirely happy to see base64-encoded data being jammed
through config -- ideally, config will be human-readable -- and I'd always
be happier to see the necessary configuration data spelled out in full --
but that's by the by.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131118/9392ae30/attachment.html>