eod status 8-jan-2013

[William Reade]

On Wed, 2013-01-09 at 09:44 -0800, Clint Byrum wrote:
> Excerpts from William Reade's message of 2013-01-08 15:50:16 -0800:
> > Hey all
> > 
> > Subordinates now work, for given values of work. Critically, and
> > cripplingly, most of the subordinates in the charm store have explicit
> > "juju-info" relations, which juju-core disallows. However, a principal
> > unit of mysql, running against the current trunk, has been observed to
> > correctly deploy, recall, and remove a subordinate unit of nrpe, in
> > response to the addition and removal of a relation between the two
> > services.
> 
> Why would juju-core disallow something that is such common practice?

Ambiguity in endpoint specifiers, mainly, with a side order of
inappropriate hook execution, but that's easy to work around.

> If it does, the documentation needs to be updated to reflect the coming
> change, and deprecation notices added to juju.

This *might* happen once Kapil and I have discussed this with Gustavo on
his return.

> Here's another thought.. don't do that. Allow them forever. Is there a
> good reason to break working charms?

We had thought there was; probably we were wrong. I have a proposal,
that I think has only a very small probability of being annoying in
practice, and can be sanely accommodated by juju-core:

1) Change unit agents to only run juju-* hooks when the unit is on the
requirer side of the relation in play. (This is hopefully not
controversial.)

2) Change relation inference such that, when a potentially ambiguous
relation is specified (eg "foo:juju-info bar:juju-info", where both foo
and bar require explicit "juju-info" in addition to providing implicit
"juju-info"), assume that the intended relation is "<requirer>
<provider>". (This fits neatly in some ways -- "req pro" is the
canoncial endpoint ordering in a relation -- but may be surprising when
users actually hit this case. But it's a bit of an edge case, and it
doesn't make the relation inference rules notably harder to explain, so
it should be OK.)

Thoughts? I think that this works around all my own complaints about use
of the juju-* namespace; it remains to be seen whether niemeyer is also
satisfied with this solution.

Cheers
William