Dunedin core sprint results

[Tim Penhey]

Hi folks,

This week Tim, Ian, Andrew and Jesse were sprinting our little hearts
out in Dunedin, NZ.

Our primary focus was to look at improving closed network support, and
making some local provider improvements, with a side of knowledge
sharing and induction stuff.

I think it has been a very successful week. Jesse hasn't run away
screaming yet, and we have landed some good changes.

For the closed network support, we limited ourselves to just proxies.
Juju now has configuration for:
  http-proxy
  https-proxy
  ftp-proxy
and apt, it defaults to these values, but you can provide overrides in
the form of
  apt-http-proxy
  apt-https-proxy
  apt-ftp-proxy

The settings are passed through during cloud-init, and the uniter sets
them during the hook execution.  The apt proxies are written to
/etc/apt/apt.conf.d/something-file

Still to go on proxies:
 * machine agent watching to keep the files up to date
 * machine and unit agents need to set the environment variables for the
process itself
 * export the values at the start of the cloud init scripts


Machines, when they start, now report their known IP addresses, and
these are written to the machine document.  This means that the local
provider now has IP addresses on the machines in status, and you can
juju ssh <machine-id> and it works \o/

Also, status now no longer polls the environment at all, and just gets
information from mongo making it much faster on environments with many
machines.  Another side benefit of this is not hitting rate-limits on
the provider APIs just trying to do status.

The local provider no longer needs an explicit sudo to bootstrap or
destroy.  It will execute sudo internally and ask if it needs to.  Also,
the local provider now uses much more of the same bootstrapping process
to start up as the other providers, reducing local provider special cases.

Jesse has landed some refactoring code exercising our review/landing
process.

Also, new common structures were added to the client side api to in a
similar way to the apiserver common code.  Additionally, common tests
were added to test the common code, both for the client and server side
of the api.

Also we discussed Azure availability sets and have outlined thoughts
here:
https://docs.google.com/a/canonical.com/document/d/1PJiqBiAndIKvT6WYT1fG4rBX2b4sF90j3m7GTLNoZiE/edit

We also talked about improving the upgrade process for juju, and have
outlined thoughts here:
https://docs.google.com/a/canonical.com/document/d/1ix0AoAHHZUVEc0C88H6IeJ_gLewdoEPkvFyLAvrz8is/edit#

Ian got close to a lone goat [1] and a good time was had by all.

Tim

[1] https://twitter.com/howbazaar/statuses/426506900033642496