On Thu, Jun 19, 2014 at 5:14 AM, Andrew Wilkins < [email protected]> wrote: > > If that's the case, why do we not just require charms to implement an > address-changed hook to update the relation setting then? > That way we don't break existing proxy charms, but other charms won't be > fixed until they implement that hook. We'd have to keep the initial > private-address value for backwards compatibility at least initially. > > So how about this as an alternative proposal: > - Add relation-address-changed, but don't add automatic updating of > private-address (after initial setting). > - Continue to use "unit-get private-address". When we have networks, then > we can add "-r" and have it default to the current relation. > > Pros: > - Nothing to do on upgrade, no messy error-prone logic > - No network specific bits added until they're added > - No charms will be broken any more than they already are > Cons: > - Existing non-proxy charms will need to be changed to take advantage of > the fix >
Still not ideal, but model-wise it'd work for me. Also covers the odd weird case where an interface uses "host" instead of "private-address". Kapil? Charmers? I understand that the extra work is unattractive, but I really don't want to depend on racy scary magic, and I can't shake the feeling that automatic rewrites will always take us there. Cheers William
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
