On Sun, Nov 17, 2013 at 7:17 PM, David Britton <[email protected]>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.
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
