<br><br>On Tuesday, October 16, 2012, Gustavo Niemeyer  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 16, 2012 at 5:15 AM, William Reade<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'william.reade@canonical.com')">william.reade@canonical.com</a>> wrote:<br>
>> 9 charms failed because they hardcode the path to hook commands, mainly open-port. It is not clear if this is a bug in the charms, i.e., do we mandate to charm authors they should not assume a path for the hook commands, or in the Go implementation (we will have to provide compatibility symlinks)<br>

><br>
> At the moment, there is no guarantee that the right open-port binary for<br>
> one unit in a container is the same as the right binary for another<br>
<br>
Agreed, and there shouldn't be IMO. Charms shouldn't hardcode paths to<br>
the juju tools.</blockquote><div><br></div><div>Even in pyjuju those paths aren't stable depending on origin they may be usr/local</div><div> </div><div>I'd consider them charms bugs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
> unit; and I don't believe that we could have (easily) fixed the python<br>
> to both make that guarantee and implement tool upgrades. But, without<br>
> upgrades existing, I guess people have become used to the single<br>
> open-port binary being in a predictable location.<br>
><br>
> Relatedly: something I think Clint said the other day -- that<br>
> subordinates often don't play well when they're running hooks at the<br>
> same time (apt locking in particular, but I think that's just one<br>
> symptom of a fundamental issue) -- has been making me think.<br>
<br>
That's an interesting case, because apt locking can affect the unit<br>
even when it's not another hook that is running at the same time. This<br>
seems like a good problem to brainstorm on and solve irrespective of<br>
what we do about the hooks specifically, because it's a trivial<br>
operation that people will expect to just work, and it should.<br>
<br>
In less trivial cases, relations may also be used to create the<br>
sequencing between the units, when that's really necessary.<br>
<br>
> What's the immediate crack-test reaction to the idea that the "unit"<br>
> agent should actually be a "container" agent, which runs the Uniters for<br>
> every unit in that container? It would demand some implementation tweaks<br>
> to allow us to start/stop uniters independently, but it would make it<br>
> much easier to have (effectively) a global hook lock... and it kinda<br>
<br>
While there would certainly be some value in lock-stepping the<br>
independent uniters, I also see some significant value in the<br>
isolation of units. Stability, security, behavior.. quite a lot will<br>
be unified if we put the units together under the same uniter, and<br>
what today is "just two units in the same container" will become a lot<br>
more involved. We can definitely brainstorm further on the idea, but<br>
it's not a change that seems like a clear win to me, at least.<br>
<br>
>> Taking the previous paragraph into consideration, the number of working charms could be more than 70, which I view as a fantastic achievement.<br>
><br>
> Woot again!<br>
<br>
Indeed! Great work David.<br>
<br></blockquote>Awesome.<div></div><div><br></div><div>Kapil<span></span></div>