eod status 8-jan-2013

[Kapil Thangavelu]

On Wed, Jan 9, 2013 at 2:38 PM, William Reade
<william.reade at canonical.com>wrote:

> 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.



Insert ^Possible||Theoretical, prevented in practice to date because
juju-info rel names are only used for subordinate charm requires on their
container relation.



> > 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?
>
>
I was channeling clint when i raised my objections and possible work
arounds here ;-)

or was it linus on breaking userspace... https://lkml.org/lkml/2012/12/23/75

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.)
>

sounds good.


> 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.)


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.



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.
>

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.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130109/5f817259/attachment.html>