lp:~rogpeppe/juju-core/azure

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

1482. By Roger Peppe on 2013-07-18

environs/azure: use my image

1481. By Jeroen T. Vermeulen on 2013-07-17

[r=jtv] Unify providers' user-data composition functions.

All the "physical" providers (EC2, OpenStack, MAAS, Azure) were generating
user data in essentially the same way. The MAAS one looked different but
actually just added an optional bit that was still completely generic. And so
this branch unifies the implementations.

Construction of the cloudinit.MachineConfig was lifted out of the function.
That may seem arbitrary, but it's part of a greater plan: in a later step of
the ongoing refactoring the construction can be lifted out of the providers'
internalStartInstance methods as well, doing away with the EC2 and OpenStack
providers' startInstanceParams structs. This actually shortens some of the
data flows and reduces cognitive load, which can only be good for maintenance.

After that step we can have a fresh look at sanitizing NewMachineConfig (which
arguably should take more parameters, or not exist at all, but is in an
intermediate state that facilitates the changes happening now). We may also
look into re-introducing some sort of dedicated Parameter Object for
internalStartInstance, but by then the cluster of methods Bootstrap /
StartInstance / internalStartInstance will look a bit different and we can
find the most maintainable solution for that new situation.

1480. By John A Meinel on 2013-07-17

[r=jameinel],[bug=1199915] cmd/jujud: Ensure valid agent.conf after upgrade

This fixes the agent.conf files for the machine and unit agents after upgrading from 1.10 to 1.11. I ran into a few differences, the basics are:

1) Machine Agent: machine 0 always starts the state worker, when
upgrading it has an APIInfo section, but it
  1a) Didn't have Machine.SetPassword in the DB set so we didn't have a
  way to connect via the api
  1b) Didn't have a password set in apiinfo, and 1.10 had already
  changed the password after connecting to the MongoDB
  1c) Had changed their password already

So to solve this one, we grab the Password from StateInfo.Password,
call Agent.SetPassword(), and set the value in APIInfo.Password.

2) Machine Agent: machine != 0. Were only connecting to the state after
connecting to the API. Because of (1a,b) they couldn't connect to
notice that they had work to do.

So on top of what we did for (1), I added a step of:

  2a) If we are unable to connect to the API, call ensureStateWorker().
  This gives us an opportunity to set our API password and save it in
  agent.conf.

3) Unit agents:

  3a) Didn't even have an APIInfo section.
  3b) Did have a Mongo password, and had reset their Mongo Password

So we copy the state info into the api info section, and change the
port. I only use the default port (17070). I think it would be possible
to query something in state for what the official API is
(state.State.Environ().APIInfo() comes to mind, but I'm not sure what
the correct value is.)

I felt that changing the port would solve all current 1.10 users, and
if we change things in the future, we can change the code. (I also just
discovered that we have Conf.APIPort which may or may not be set in all
the various permutations, I don't have the energy to track down 3
different versions now.)

4) Unit agents bootstrapped with 1.11.2 tools

  4a) Would have a valid APIInfo section
  4b) But would not have StateInfo.Password or APIInfo.Password set.
  This is because changing the Password now occurs when we connect to
  the API, not when we first connect to the Mongo DB.

I added checks for this, to make sure that 1.11.3 doesn't cause us to
call Unit.SetPassword("").

I did a few upgrades from 1.10 => this code, and 1.11.2 => this code,
and straight bootstrapping from this code. It all seems to be up and
running. I don't think I tried bootstrapping 1.10 with this code and
upgrading.

I hopefully captured all of these config edge cases in the test suite,
so we don't have to test all the permutations manually in the future.
We also need to think very carefully when we add stuff about how we
will get upgrade to notice. I'm starting to think we want to tweak how
upgrade works. So instead of just replacing the tools, it has a
"juju upgraded" or some other command that runs the first time you are
upgraded so we can put logic into that place and have it centralized.

https://codereview.appspot.com/11137044/

1479. By Martin Packman on 2013-07-17

[r=gz] Check correct info attr in cloudinit.apiHostAddrs

Fixes a copy/paste error in cloudinit.MachineConfig to agent.Conf
conversion helper function. No test as the only codepath that uses
this goes through verifyConfig which already asserts both StateInfo
and APIInfo are not nil, so not possible to write a failing test
using exposed functions.

1478. By Dimiter Naydenov on 2013-07-17

[r=dimitern] state/api: Deployer client-side facade.

Implemented all the necessary API calls for the
deployer worker. This is the last step needed
before the deployer can be refactored to use
only the API to talk to state.

Also fixed the StringsWatcher client implementation
(I initially got it wrong, but since nobody was using
it yet it got undetected).

Few other minor issues discovered and fixed in state,
adding tests as needed.

https://codereview.appspot.com/11342043/

R=fwereade, themue

1477. By Jeroen T. Vermeulen on 2013-07-17

[r=jtv] Convert MAAS provider to loggo.

We've been told this was desired, so we might as well do it. Why keep the
obsolete approach around to set a bad example?

1476. By Tim Penhey on 2013-07-17

[r=thumper] Enable the local provider.

This branch changes how the local storage is handled.
It really wasn't possible to have the client keep serving
the storage on dynamic ports and expect other running
services to work.

Also we need something always acting as the storage. After
discussion with William last night, we agreed that this
should be a worker in the machine agent.

https://codereview.appspot.com/11333043/

1475. By Gavin Panella on 2013-07-17

[r=jtv] Fix for gwacl update.

1474. By Tim Penhey on 2013-07-17

[r=thumper] Conditionally install lxc

There are two primary situations where we don't want
the machine agent to install lxc:
 1. when the machine agent is inside an lxc container
    as known by state
 2. when the machine has been provisioned by the local
    provider (because it is an lxc container)

When lxc is installed inside a container, it adds a
bridge network device with the same defaults as the
host. This kills any routing in or out of the container.

Upstart provides support for setting environment variables
as part of the config, and we use this to pass the provider
type through.

https://codereview.appspot.com/11330043/

1473. By Tim Penhey on 2013-07-17

[r=thumper] Have the lxc manager log dir be configurable.

Since the local provider wants to store the log files
in a different location, the ContainerManager needs to
be configured with the location.

The default log location is still the same, but is now
able to be configured.

Also factored out the function for getting the IPv4 address
for a named interface. The containers have "eth0" as their
network interface, so this is used to get the DNSName.

https://codereview.appspot.com/11327044/