lp:~arosales/juju-core/update-azure-boilerplate

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1740. By Antonio Rosales on 2013-09-02

Comment out image-stream to force default 'released' simple stream, per lp bug 1219123.

1739. By Antonio Rosales on 2013-08-31

Set image-stream default value to released as bootstraping complains this field is blank.

1738. By Antonio Rosales on 2013-08-30

Update Azure boilerplate public tools, remove force image reference, set default simple streams to precise released, and remove non-applicable comments.

1737. By Roger Peppe on 2013-08-30

[r=rogpeppe] environs/bootstrap: enable and fix tests

As jameinel suggests, it would be nice if go test
at least printed a question mark when there
are no tests to run.

https://codereview.appspot.com/13428043/

1736. By Roger Peppe on 2013-08-30

[r=rogpeppe] state: avoid panic in watchers

If the state is closed underneath a watcher, the
underlying watcher.Watcher will die with no error.
That should not itself trigger a panic.

I have not added test coverage for every single
entry point that creates a given kind of watcher.
I feel that adds unnecessarily to the test burden, and
with this particular kind of test, inspecting the
test coverage shows clearly which watchers are
tested in this way.

https://codereview.appspot.com/13386044/

1735. By William Reade on 2013-08-30

[r=fwereade],[bug=1218362] state: reinstate accidentally-dropped tests

Aside from removal of the tests for the Joined field (which is no longer sent,
because it's redundant (preexisting change)), this was a mechanical rename
job from the original. It's reassuring to observe that behaviour had not
otherwise changed detectably in the interim.

https://codereview.appspot.com/13401045/

1734. By Tim Penhey on 2013-08-30

[r=thumper] Move the Dir function from agent/tools to agent.

Part of the agent refactoring, and this is the only bit
that touched parts outside of the agent package.

https://codereview.appspot.com/13256045/

1733. By Tim Penhey on 2013-08-30

[r=thumper] Get the address correctly from the container.

This is kind of messy, but it does work.
This uses an extra environment variable from the upstart
script to identify the type of container. MAAS then uses
this when trying to work out the hostname of the machine.

We do need a nicer way to get this done. We also want to
move the environment variables from the upstart script
into the agent config, but this will be a follow up branch.

https://codereview.appspot.com/13261044/

1732. By Andrew Wilkins on 2013-08-30

[r=axwalk] Update add-machine for manual provisioning

juju add-machine is updated to use a new package,
environs/manual, to manually provision tools and
a machine agent to an existing machine.

When a manually provisioned machine is destroyed
via juju destroy-machine, the machine agent will
detect its termination and remove its upstart
configuration file. There is currently no cleanup
of the data or log directories; this will be done
in a follow-up pending discussion.

When the machine goes to Dead, a provisioner will
remove the machine from state just like any other
machine.

TODO: destroy-environment will currently leak
manually provisioned machines. A follow-up will
address this by requiring users to individually
destroy-machine before destroy-environment will
proceed. Alternatively (or perhaps additionally),
destroy-environment may take a flag to automatically
do this.

https://codereview.appspot.com/12831043/

1731. By John A Meinel on 2013-08-29

[r=jameinel],[bug=1218256] upgrader: add Upgrader.DesiredVersion

The initial implementation of the API version of the Upgrader had a
single API endpoint Tools() that it used to find both the desired agent
version to run, and the URL to download tools matching that version.
This was simple, but caused bug #1218256. Specifically, it means that
the API Server needs to have provider (eg ec2) credentials in order to
answer the Tools request. (So it can search the storage and see what the
URL for downloading the tools is.)

As such after bootstrap (before the first connect), the Upgrader would
keep bouncing as it got an error trying to determine what agent version
it should run as.

This adds one more api: Upgrader.DesiredVersion(). This only returns the
agent version string. Which can be served directly from the DB after
bootstrap, without having to look at the provider at all.

And even beyond the first bootstrap, the current implementation of
WatchAPIVersion is very naive and will trigger a probe on any change to
EnvironConfig. At present that means it also triggers a listing of all
Storage buckets to find the tools that will match for that agent. With
the new implementation, it only provokes a DesiredVersion() call which
is relatively small and doesn't talk to a 3rd party data source.

This isn't strictly backwards compatible. If we upgrade a machine-1
agent before upgrading the machine-0 agent, machine-1 will keep bouncing
until machine-0 has finished upgrading and has the new API available.
That was already true of upgrading from 1.12 to 1.13.x, so we haven't
made the upgrade-to-1.14 story any worse. (Agents will still notice they
have to upgrade, and start trying to upgrade, they will just keep
bouncing after the upgrade until machine-0 finishes its upgrade.)

We *could* do something where if DesiredVersion can't be called, we fall
back to Tools and if that fails we fall back to direct DB access. But I
don't think it is worth spending the time on that code path right now.

https://codereview.appspot.com/13380043/