<div dir="ltr">I can add a bunch of detail, actually:<div><br></div><div>The install was: 1.18.4-trusty-amd64</div><div><br></div><div>The persons machine:</div><div><div><br class="">$ juju --version<br></div><div>1.20.11-trusty-amd64</div></div><div><br></div><div><div>upgrade was: juju upgrade-juju --upload-tools --version=1.20.11</div><div><br></div><div>The resulting files:</div><div>drwxr-xr-x 2 root root 4096 Jul 29 17:52 1.18.4-trusty-amd64</div><div>drwxr-xr-x 2 root root 4096 Nov 13 18:14 1.19.4-trusty-amd64</div><div>lrwxrwxrwx 1 root root   19 Nov 13 18:10 machine-0 -> 1.19.4-trusty-amd64</div><div>lrwxrwxrwx 1 root root   19 Nov 13 18:14 unit-ksplice-9 -> 1.19.4-trusty-amd64</div><div>then at log:</div><div>2014-11-13 18:32:11 ERROR juju.worker.instanceupdater updater.go:267 cannot set addresses on "0": cannot set addresses of machine 0: cannot set</div><div>             addresses for machine 0: state changing too quickly; try again soon</div><div><br></div><div><br></div><div>2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:776 upgrade to 1.19.4-trusty-amd64 already completed.</div><div>2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:757 upgrade to 1.19.4-trusty-amd64 completed.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 7:41 PM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 14/11/14 06:28, Curtis Hovey-Canonical wrote:<br>
> We have another cases where an env using --upload-tools tried to<br>
> upgrade from 1.18.4 to 1.20.x and got 1.19.x. I want to remove all the<br>
> devel agents from the released streams.<br>
><br>
> We have already created separate streams for devel and proposed agents<br>
> to ensure environments cannot upgrade to them without explicitly set<br>
> the environment to use them.<br>
><br>
> I want to ensure we don't have old devel agents in our released<br>
> streams. This will prevent anyone from getting these version from our<br>
> official locations. This may also prevent environments that are idling<br>
> on obsolete version from deploying more units.<br>
><br>
> Are there other issues that will happen if I remove the devel agents?<br>
> Is this a bad and dangerous idea?<br>
><br>
<br>
</span>I think this is a good idea and can only see benefits.<br>
So +1 from me.<br>
<br>
Having said that, if they used upload-tools then the public metadata is not used<br>
anyway. Juju will generate metadata for the jujud it finds in the user's path<br>
(or compiles from source if no jujud is found). The metadata is written to their<br>
environ storage (for Juju < 1.21). Do we have any more information about their<br>
setup? It would be interesting to understand what happened.<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></div>