upgrade-juju --upload-tools, using 1.20.11, from 1.18.4 upgraded to 1.19.4 instead

[JuanJo Ciarlante]

Steps:
#1 Original state: stock trusty install with 1.18.4

#2 From ppa:juju/stable, installed 1.20.11-trusty-amd64

#3 ran:
juju upgrade-juju --upload-tools --version=1.20.11

#4 Result: 1.19.4 got deployed, machine-0.log showing
http://paste.ubuntu.com/9009795/

[Curtis Hovey (sinzui)]

--upload-tools is evil. we have separated streams to ensure users cannot get a devel agent, but the developer hack of --upload-tools is designed to make something exist.

We cannot fix 1.18, but we need to ensure that 120 or 1.21 will never select something that isn't in streams without the user specifically demanding it.

[Ian Booth (wallyworld)]

I'd like to understand why upload-tools is being used. No customer should have
to do that, especially now that we have devel, testing and proposed streams.

The bug occurred against 1.20.11 so may well have been fixed since then. Does it still occur?

[JuanJo Ciarlante (jjo)]

It would be needed for environments with tighter access
control: ie egress against streams.canonical.com
not allowed (IIRC was the case for us, by the time
streams.c.c. was hosted at AWS), and/or if you wanted to
avoid any auto-update happening behind scenes IIUC.

FYI didn't try using upgrade-juju --upload-tools again.

[Katherine Cox-Buday (cox-katherine-e)]

Because this is a developer-focused flag, we'll be removing this as a target for 1.24.

[Curtis Hovey (sinzui)]

This was also see using 1.24.0 client on 1.18.x env. I suspect since modern juju doesn't have a prohibition against odd versions, it is happy to select 1.19.x

I think we need to remove 1.19. and all other odd versions from "released" streams to ensure historic devel versions cannot be placed into production without a human requiring it using agent-streams: devel.