On Fri, Jun 20, 2014 at 6:44 AM, William Reade <william.re...@canonical.com> wrote:
> On Thu, Jun 19, 2014 at 5:14 AM, Andrew Wilkins < > andrew.wilk...@canonical.com> 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. > One additional possibility is that we could introduce this behaviour for 1.20 (if it lands in time), and then in 1.22 we could enable unconditional automatic updating of private-address as in the original proposal. This would give proxy charms time to update, while also fixing the other charms. This can easily be done on top of this proposal.
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
