Hacking upload tools

Bootstrapping with --upload-tools is incredibly useful for developers, because it means you get to push up a locally-built jujud with all your new features and debugging additions, etc.

However, --upload-tools also changes the behavior of the server considerably, such as no longer talking to streams to get new tools for new machines, changing how upgrades are accepted, etc. This is good when you're in production, but can be problematic when what you want to debug is how the code works without --upload-tools.

Note that hacking the effects of upload-tools may have unexpected effects. It means your controller will be using a different jujud than other machines (which will use the binaries they download from streams).

In order to disable the effects of using --upload-tools, you need to do three things:

1. Ensure the juju version is set to something that exists in the public streams. Compare the version constant on line ~22 of github.com/juju/juju/version/version.go to the published tools versions available at https://streams.canonical.com/juju/tools/agent/. If you are working off master, the version in this file is often a patch level above what is available in streams, so for example, if master is 2.0-beta4, you'd want to set this to 2.0-beta3, but again, check that it is available in streams.

2. Disable the auto-increment of the version.Build number on the tools we upload, which indicates a development build. Comment out the binary.Build++ line in github.com/juju/juju/environs/bootstrap/tools.go at line ~144.

3. Disable storage of uploaded tools so that new machines will pull tools from streams. In github.com/juju/juju/cmd/jujud/bootstrap.go, add a return nil before the loop that calls toolstorage.Add at line ~423.