drop tools upload capability

[William Reade]

The uplod tools functionality, used by bootstrap and upgrade-juju, is evil and damaging partly because it's a developer hack that allows us to avoid the most common tools-location code paths, and partly because it also special-cases finding and magically distributing a local jujud binary with a faked-up version number; and this is really awful because people have discovered this and started using it.

We need to (1) drop --upload-tools across the board and (2) come up with sane mechanisms for distributing local copies of jujud tools; consider that we already have:

* the --source arg that already exists, but isn't used by upgrade-juju
* the tools[-metadata]-url in the environment config

...and the ability, with synchronous bootstrap, to put tools directly on the state server as we bootstrap.

[Kapil Thangavelu (hazmat)]

i came across this bug while, i was about to file a bug to enable --upload-tools usage. The lookup for tools is rather complex and error prone and hard to debug for private clouds. (i had had wallyword and mgz helping a partner for over 2hrs on irc the other day). upload-tools is both simple and effective, i'd rather have a safety valve then mandate complexity, ideally allowing it even in the absence of compilation tools.

[Ian Booth (wallyworld)]

Actually, it wasn't tools lookup that took the time when helping the partner. It was image id lookup that was causing issues, and also a ssh hostname verification bug. The image id lookup was problematic because the cloud instances were running on a network without the ability to provide http access to the swift containers. A solution for this is landing now. There's also a solution for the hostname verification issue in progress.

So regardless of the merits of --upload-tools, the recent customer support issue should not come into it.

[Kapil Thangavelu (hazmat)]

fair enough re image metadata issue.. to me the reality is tools lookup is fairly complex, not in our docs, hoses people regulary in private clouds... and something that developers rarely use. the flipside is --upload-tools is dirt simple.. use the binary i'm running right now. to me the reality is for production environments, doing a simple streams lookup (with no dry run..) is frought with mystery.. the simplicity of use the binary i'm running right now is a huge win for prod environments.

[Andreas Hasenack (ahasenack)]

Getting away with upload-tools without having a nice and simple story for tools is wrong. As kapil says, setting up tools in a private cloud is difficult, much more difficult than using --upload-tools.

[Curtis Hovey (sinzui)]

As we promise to maintain compatability with 1.18.x for the life of 1.x, I don't think this issue is still important. We will live with the feature until we choose to create 2.0-alpha1

[Cheryl Jennings (cherylj)]

In 2.0 discussions, it was decided that for 2.0, we will disallow upgrades to hosted models using --upload-tools. See bug #1567170