<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 2:38 PM, William Reade <span dir="ltr"><<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, 2013-01-09 at 09:44 -0800, Clint Byrum wrote:<br>
> Excerpts from William Reade's message of 2013-01-08 15:50:16 -0800:<br>
> > Hey all<br>
> ><br>
> > Subordinates now work, for given values of work. Critically, and<br>
> > cripplingly, most of the subordinates in the charm store have explicit<br>
> > "juju-info" relations, which juju-core disallows. However, a principal<br>
> > unit of mysql, running against the current trunk, has been observed to<br>
> > correctly deploy, recall, and remove a subordinate unit of nrpe, in<br>
> > response to the addition and removal of a relation between the two<br>
> > services.<br>
><br>
> Why would juju-core disallow something that is such common practice?<br>
<br>
</div>Ambiguity in endpoint specifiers, mainly, with a side order of<br>
inappropriate hook execution, but that's easy to work around.</blockquote><div><br></div><div><br></div><div>Insert ^Possible||Theoretical, prevented in practice to date because juju-info rel names are only used for subordinate charm requires on their container relation.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> If it does, the documentation needs to be updated to reflect the coming<br>
> change, and deprecation notices added to juju.<br>
<br>
</div>This *might* happen once Kapil and I have discussed this with Gustavo on<br>
his return.<br>
<div class="im"> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Here's another thought.. don't do that. Allow them forever. Is there a<br>
> good reason to break working charms?<br>
<br></div></blockquote><div><br></div><div>I was channeling clint when i raised my objections and possible work arounds here ;-)</div><div><br></div><div>or was it linus on breaking userspace... <a href="https://lkml.org/lkml/2012/12/23/75">https://lkml.org/lkml/2012/12/23/75</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>We had thought there was; probably we were wrong. I have a proposal,<br>
that I think has only a very small probability of being annoying in<br>
practice, and can be sanely accommodated by juju-core:<br>
<br>
1) Change unit agents to only run juju-* hooks when the unit is on the<br>
requirer side of the relation in play. (This is hopefully not<br>
controversial.)<br></blockquote><div><br></div><div>sounds good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Change relation inference such that, when a potentially ambiguous<br>
relation is specified (eg "foo:juju-info bar:juju-info", where both foo<br>
and bar require explicit "juju-info" in addition to providing implicit<br>
"juju-info"), assume that the intended relation is "<requirer><br>
<provider>". (This fits neatly in some ways -- "req pro" is the<br>
canoncial endpoint ordering in a relation -- but may be surprising when<br>
users actually hit this case. But it's a bit of an edge case, and it<br>
doesn't make the relation inference rules notably harder to explain, so<br>
it should be OK.)</blockquote><div><br></div><div>hmm.. i really don't like introducing ordering requirements where previously none have existed, it also means we have to carry forward the rules and logic to other tools like the gui etc where position is non obvious to the user as it is on the cli. my original suggestion here was to not allow require juju-info as a relation name unless the charm is a subordinate which satisifies the existing charms and avoids the posited scenario as its then its more obviously broken (any info from the rel is already available from the primary) albeit at the cost of some doc word smithing.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thoughts? I think that this works around all my own complaints about use<br>
of the juju-* namespace; it remains to be seen whether niemeyer is also<br>
satisfied with this solution.<br></blockquote><div><br></div><div>indeed, per discussion on irc, william and i agreed to table till niemeyer could weigh in. that was my appeal to authority due to an impasse. if we're now reasonably agreed that breaking extant software is bad, and the workarounds are reasonable, i'm okay w/ moving forward.</div>
<div> </div><div>cheers,</div><div><br></div><div>Kapil</div></div>