Can we removed all devel agents from released streams.

[Horacio Duran]

I can add a bunch of detail, actually:

The install was: 1.18.4-trusty-amd64

The persons machine:

$ juju --version
1.20.11-trusty-amd64

upgrade was: juju upgrade-juju --upload-tools --version=1.20.11

The resulting files:
drwxr-xr-x 2 root root 4096 Jul 29 17:52 1.18.4-trusty-amd64
drwxr-xr-x 2 root root 4096 Nov 13 18:14 1.19.4-trusty-amd64
lrwxrwxrwx 1 root root   19 Nov 13 18:10 machine-0 -> 1.19.4-trusty-amd64
lrwxrwxrwx 1 root root   19 Nov 13 18:14 unit-ksplice-9 ->
1.19.4-trusty-amd64
then at log:
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
             addresses for machine 0: state changing too quickly; try again
soon


2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:776 upgrade to
1.19.4-trusty-amd64 already completed.
2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:757 upgrade to
1.19.4-trusty-amd64 completed.


On Thu, Nov 13, 2014 at 7:41 PM, Ian Booth <ian.booth at canonical.com> wrote:

>
>
> On 14/11/14 06:28, Curtis Hovey-Canonical wrote:
> > We have another cases where an env using --upload-tools tried to
> > upgrade from 1.18.4 to 1.20.x and got 1.19.x. I want to remove all the
> > devel agents from the released streams.
> >
> > We have already created separate streams for devel and proposed agents
> > to ensure environments cannot upgrade to them without explicitly set
> > the environment to use them.
> >
> > I want to ensure we don't have old devel agents in our released
> > streams. This will prevent anyone from getting these version from our
> > official locations. This may also prevent environments that are idling
> > on obsolete version from deploying more units.
> >
> > Are there other issues that will happen if I remove the devel agents?
> > Is this a bad and dangerous idea?
> >
>
> I think this is a good idea and can only see benefits.
> So +1 from me.
>
> Having said that, if they used upload-tools then the public metadata is
> not used
> anyway. Juju will generate metadata for the jujud it finds in the user's
> path
> (or compiles from source if no jujud is found). The metadata is written to
> their
> environ storage (for Juju < 1.21). Do we have any more information about
> their
> setup? It would be interesting to understand what happened.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141113/4bcda0f8/attachment.html>