container provisioner may choose bad tools

[William Reade]

The container_initialisation code uses Provisioner.Tools() to discover the tools version being run by the current machine -- but this actually uses environ config's agent-version in the background. Provisioners should always choose tools matching the code that's running the provisioner, because we can't be sure that cloudinit for a different version will actually configure the new instance correctly.

We should use version.Current explicitly, and directly request all matching tools for that version with the series specified on the new machine. This matches the algorithm in the environ provisioner -- but we cannot use the current implementation, because the environ provisioner directly requests the tools from the environ, and the container provisioner doesn't have access to that (because we don't want to expose the environ creds to every agent).

*so*... we basically need to:

1) add a provisioner API that accepts a version.Number (which will be version.Current, as discovered on the provisioner) and a series (and perhaps an optional arch, in case one is set in the constraints?), and returns all possible versions.

2) drop the tools part of the container-artifacts initialisation entirely, and drop the Tools method -- and probably the HasTools interface too

3) drop the branching in container_task's possibleTools implementation, and just always call that API.

To do this *right*, we should also start storing a tools catalogue in state -- and always store all referenced tools directly in the environment -- so we don't need to keep on hitting simplestreams any time anyone asks.

I'm marking this low priority, because even though it *sucks*, the actual consequences are relatively minor -- it'll impact a single container that can be force-destroyed and recreated, and that will happen only rarely.

[Andrew Wilkins (axwalk)]

Will fix this as part of cataloguing/storing tools in state.

[Andrew Wilkins (axwalk)]

https://github.com/juju/juju/pull/636