On Wed, Jun 18, 2014 at 5:21 PM, William Reade <william.re...@canonical.com> wrote:
> On Wed, Jun 18, 2014 at 7:05 PM, Kapil Thangavelu < > kapil.thangav...@canonical.com> wrote: > >> >> addresses are just keys in a unit relation data bag. relation-get is the >> cli tool to retrieve either self or related units databag key/values (ie >> for self's address in the rel $ relation-get $JUJU_UNIT_NAME >> private-address). unit-get is used to retrieve the current iaas properties >> of a unit. >> > > Yes: unit-get retrieves iaas properties; and relation-get retrieves unit > properties; but self's private-address is *not* put in self's relation data > bag for the benefit of self; it's for the remote units that *react* to > changes in that data bag. > Its not a write only bag and we don't constrain reads. Charms can retrieve their own relation properties when evaluating a remote relation change. address is simply a key in that bag. The benefit to self/local unit, and to all charm authors was the one boilerplate property that every single one of them needed to provide/relation-set was effectively handled by the framework. Afaics it also makes it easier for us to do some of the sdn relation binding because we provide that value else we'd be rewriting all extant charms to support it. > Using `relation-get $JUJU_UNIT_NAME private-address` is Doing It Wrong: > the canonical way to get that data is `unit-get private-address`, and the > problem is not that we don't magically update the relation data bag: the > problem is that we don't provide a means to know when the relation's data > bag should be updated. > it sort of depends why your retrieving wrt to if its wrong, if a unit want's its own address then retrieving it directly from unit-get is clearly correct. if wants to reason about the address its advertising to related units, then retrieving from the relation is valid. Agreed re the issue being lack of updates. but adding -r to the unit-get seems to be more conflating of the relation data bags and iaas properties associated to a set of unit addresses. per the original network sketch i'd imagine in a multiple network and address world unit-get would grow facilities for retrieving list of networks and addresses. as for relation to network or route binding, it also seems its missing the notion of retrieving the named network on the rel.. ie either more framework relation properties.. or ideally this could get shuffled into relation-config or exposed more explicitly. > Honestly, it's kinda bad that we prepopulate private-address *anyway*. > It's helpful in the majority of cases, but it's straight-up wrong for proxy > charms. > its debatable, given that it would be simply boilerplate for the majority, its seems reasonable and its been easy for proxy charms to explicitly set what they want the actual value to be. Afaics the only real issue to-date has been juju isn't updating the property its populating. > I don't want to take on the churn caused by reversing that decision; but > equally I don't want to "fix" it with magical rewrites of the original > magic writes. > to me its a question of ownership.. if the framework owned the value by providing it, then the framework is responsible for updating the value till such time as the charm takes ownership by writing a new one. > my point regarding binding and addresses was more that we're forward >> thinking bug fixes by introducing a bunch of user facing stuff without >> having completely thought/designed or started implementation on the >> proposed solution that is the reason we're exposing additional things to >> users. instead i'd rather we just fix the bug, and actually implement the >> feature when we get around to implementing the feature. By the time we get >> around to implementing it (which for this cycle is against a single >> provider) we may have a different implementation and end-user exposed >> surface in mind. >> > > That's not impossible; but I don't think it's a good reason to pick an > approach at odds with our current best judgment of where we're heading. > but we're not heading there yet at best we're still doing plumbing afaics, and we're going to expose all this end user machinery which we'll have to support before we even started on the path and under the seeming aegis of providing a bug fix that could be addressed much more simply without exposing additional concepts and hooks to charm authors. ie. to me the analogy is the plumbing to the sink is stopped up, and instead of calling a plumber to clean the pipes, we're doing a renovation. yes we may want to do a renovation in the future, but that's no reason we shouldn't just fix the sink till we start it. > > moreover the user facing (charm author) aspects of the changes as >> currently in the spec are going to be confusing, ie. relation hooks are >> always called for remote units, except for this one case which is special. >> > > I don't agree that this one case is special; relation hooks are called in > response to changes in a local unit's view of a relation, and those changes > have hitherto *mostly* been about remote units. But I don't think it's > fundamental -- and I'm not even sure it's very natural, I've corrected > misconceptions about -joined referring to the local unit more than once. > addressed in other thread, and the misconceptions seem to support that understanding juju is hard and having a simple rule for what relation hooks apply to is a good thing. given the issues of lack of notifications and data ownership and that addresses are fundamentally a property of a unit that exists outside of a network scoped relation (or really any relation), why we're only informing units via a relation hook is strange. > > additionally i'd prefer we have a plan for maintaining backwards >> compatibilities with proxy charms that are already extant. >> > > OK, let's talk about that :). Would a charm feature flag work for you? > It's become pretty clear to me that we need them anyway; most charms could > switch it on without issues, and proxy charms would be free to update on > their own schedules. > i'm not sure feature flags should apply to correctness and bug fix issues. -k > > Cheers > William >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
