<div style><br class="Apple-interchange-newline">why not support both? ie. machine monitoring global version and local version setting. that avoids O(n) changes for upgrading an env, while supporting individual machine upgrades for testing.</div>
<div style><br></div><div style>cheers,</div><div style>Kapil</div><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 11:34 AM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@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 Fri, Jun 8, 2012 at 2:07 PM, roger peppe <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> wrote:<br>

</div><div class="im">> Client:<br>
>        - Push new version of tools.<br>
>        - Set new global version number in state.<br>
><br>
> Machine agent:<br>
>        - Wait for global version to change.<br>
<br>
</div>That's slightly different from what we discussed in London. There's a<br>
global setting which contains the recommended version, but the machine<br>
agent is not monitoring it. It is monitoring a flag on its own<br>
settings that tell the version it is supposed to be running. That's<br>
pretty much the same complexity in terms of implementation, but gives<br>
us the freedom to upgrade individual machines independently for<br>
testing purposes.<br>
<div class="im"><br>
> I think we should be able to do better than this. The problem is with<br>
> the "exit and let upstart start new version" step - that means that if<br>
> we happen to upload a broken version, then everything instantly breaks<br>
> and needs manually restoring.<br>
><br>
> Here are some desirable features for an upgrade facility:<br>
><br>
>        1. Uploading a broken tool shouldn't break anything.<br>
>        2. ... even for a short while.<br>
>        3. We shouldn't rely too heavily on upstart, given the possiblity<br>
>        of ports to systems without upstart.<br>
<br>
</div>That feels like pretty poor motivation. 1 and 2 are impossible to<br>
achieve, and 3 is also being misrepresented. It's not about supporting<br>
upstart.. it's about simply dying and coming back up again, which<br>
should be in place no matter what is responsible for starting the<br>
process.<br>
<br>
I'd like to bring back the two critical points that were written in<br>
the whiteboard in London when we met a week ago.<br>
<br>
These are our short term goals:<br>
<br>
1) Permit agents to restart, so that we don't drive development making<br>
silly assumptions about things that can't die<br>
<br>
2) Drive development faster, by permitting developers to iterate over<br>
a running environment<br>
<br>
This is easy to achieve with the scheme we debated, and as far as I<br>
can see the development of it is a fantastic step to any further<br>
improvements we end up needing down the road, even if that goes into<br>
the direction that you described.<br>
<br>
If that's the case, I suggest we move forward with simple steps<br>
towards that. If that's not the case, can we please focus on why<br>
that's not the case rather than proposing another solution from the<br>
ground up?<br>
<br>
<br>
gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br>