Introduce environs/bootstrap.BootstrapParams

The user-facing Bootstrap method (i.e. as
used by cmd/juju) will take different parameters
than the provider-specific one (Environ.Bootstrap).
Thus, we introduce a new parameter struct that is
currently identical to environs.BootstrapParams,
but will be changing imminently.
Make environs/bootstrap responsible for tools location

environs/bootstrap now finds available tools, augmenting
or substituting for locally buildable/uploadable tools
as necessary (auto upload) or as specified (--upload-tools).
Environ.Bootstrap is now provided with a list of available
tools, and is not responsible for syncing tools itself.

--upload-series and --series will be obsoleted: we will
upload a single series, and then use that in the metadata
for each supported series.
Explode uploaded tools for each supported series in bootstrap
Fix tests
environs/cloudinit: Wrap tools download inside cloud init in a retry loop

Forward port of https://github.com/juju/juju/pull/598
environs/bootstrap: rework findAvailableTools
Revert changes to mount tools storage in containers

This conflicts with provider storage removal.
Machines will retrieve tools from the API
server in a follow up PR.
cmd/juju: update --(upload-)series message/help
environs/bootstrap: tweak comment
environs/bootstrap: more coverage in findAvailableTools
cmd/juju: fix test on i386 (don't assume amd64 tools)
provider/common: set default-series in mock config
Merge pull request #600 from axw/bootstrap-upload-tools-no-storage

Make environs/bootstrap responsible for tools location

environs/bootstrap now finds available tools, augmenting or substituting
for locally buildable/uploadable tools as necessary (auto upload) or as
specified (--upload-tools). Environ.Bootstrap is now provided with a list
of available tools, and is not responsible for syncing tools itself.

--upload-series and --series are obsoleted: we upload a single series,
and then clone that for each supported series. When we store the tools
catalogue in state, we will simply write an entry for each series that
points to the same tools tarball.
Merge pull request #602 from wallyworld/agent-version-on-startup

Set a machine's tools version when the agent starts

Fixes: https://bugs.launchpad.net/juju-core/+bug/1359800

The referenced bug shows an error initialising container support when a machine's agent starts up.

2014-08-20 22:06:07 ERROR juju.provisioner container_initialisation.go:154 cannot get tools from machine for lxc container
2014-08-20 22:06:07 ERROR juju.provisioner container_initialisation.go:95 starting container provisioner for lxc: initialising container infrastructure on host machine: agent tools for machine 5 not found
2014-08-20 22:06:07 ERROR juju.worker runner.go:218 exited "5-container-watcher": initialising container infrastructure on host machine: agent tools for machine 5 not found

The only way I can see that happening is if the container worker starts before the upgrade work sets the tools version. That can happen as both upgrade worker and container worker start up in parallel.

I moved the logic to set the tools version on a machine from the upgrade worker to the agent's APIWorker() method, thus ensuring the tools version is set early before it is needed.

I also found what looks to be bad logic in the container initialisation worker - the code to stop the worker was duplicated and one of the copies was called in the wrong place; it looked like the worker was terminated after the first container type was handled, meaning subsequent container types added to the machine may not have been started properly.
Merge pull request #607 from wallyworld/agent-version-on-startup-trunk

Merge pull request #602 from wallyworld/agent-version-on-startup

Set a machine's tools version when the agent starts

Fixes: https://bugs.launchpad.net/juju-core/+bug/1359800

The referenced bug shows an error initialising container support when a machine's agent starts up.

2014-08-20 22:06:07 ERROR juju.provisioner container_initialisation.go:154 cannot get tools from machine for lxc container
2014-08-20 22:06:07 ERROR juju.provisioner container_initialisation.go:95 starting container provisioner for lxc: initialising container infrastructure on host machine: agent tools for machine 5 not found
2014-08-20 22:06:07 ERROR juju.worker runner.go:218 exited "5-container-watcher": initialising container infrastructure on host machine: agent tools for machine 5 not found

The only way I can see that happening is if the container worker starts before the upgrade work sets the tools version. That can happen as both upgrade worker and container worker start up in parallel.

I moved the logic to set the tools version on a machine from the upgrade worker to the agent's APIWorker() method, thus ensuring the tools version is set early before it is needed.

I also found what looks to be bad logic in the container initialisation worker - the code to stop the worker was duplicated and one of the copies was called in the wrong place; it looked like the worker was terminated after the first container type was handled, meaning subsequent container types added to the machine may not have been started properly.