Implement diskmanager worker
worker/diskmanager: add tests
api/diskmanager: add tests
apiserver/diskmanager: add tests
Fix worker/diskmanager interface; fix vet warning

Make version.OSType a Stringer so it can be used as
argument to %s in printf functions.
cmd/jujud: remove diskmanager worker

Will add this back in in a follow-up.
storage: add package docs, fix comments
tests pass
Address review comments
update to new utils hash
LP-1391914 :: idPrefixWatcher; subtle bug with initial call to Changes()

Failing test to demonstrate bug
Rename test to be more descriptive
Merge pull request #1124 from wallyworld/swift-empty-containername

Abort Remove() if swift container name is empty

Fixes: https://bugs.launchpad.net/bugs/1312217

There have been a couple of goes at this fix. This version does not require any lp.net/goose changes.

From the original PR:

Hi,

I have discovered that through a series of unfortunate events involving a failed destroy-environment run (which I believe was due to a slow Swift API response), and a subsequent "working" (ish) destroy-environment run it is possible for Juju to erroneously send a DELETE HTTP request to the swift account API, which in older versions of swift (and keystone) will result in the account DB for that user in swift being marked as deleted (and the only fix for this is to either a) wait for a cron'd script to clean it up, or b) get someone to manually delete the sqlite3 db for that account hash).

Although I've been unable to find the condition in the environment (e.g. writing/loading the jenv, doing the Remove*(...) calls etc.), but I'm 99.9% recurring that this is the cause for the issue I've had with my Swift account getting into a hard-to-recover state

I've added a simple check to provider/openstack/storage.Remove(...) to ensure the containerName isn't empty (which on a call to delete the container itself, the last step in a destroy env cleanup, will result in a DELETE call to the base URL instead, which swift+keystone will gladly oblige in some OpenStack setups).

I couldn't figure out how to test this correctly, due to the way the Storage instance is created/used in the openstack tests, so any pointers on this would be appreciated.

I feel it's more important to catch this nasty edgecase here above finding it's cause in the env handling purely because it is so destructive in the openstack provider compared to others (e.g. you can't remove the base in S3 so easily).
Merge pull request #1117 from johnweldon/LP-1391914

LP-1391914 :: idPrefixWatcher; subtle bug with initial call to Changes()

Failing test to demonstrate bug + Fix
worker/diskmanager: address review comments
Merge pull request #1125 from wallyworld/swift-empty-containername-master

Merge pull request #1124 from wallyworld/swift-empty-containername

Abort Remove() if swift container name is empty

Fixes: https://bugs.launchpad.net/bugs/1312217

There have been a couple of goes at this fix. This version does not require any lp.net/goose changes.

From the original PR:

Hi,

I have discovered that through a series of unfortunate events involving a failed destroy-environment run (which I believe was due to a slow Swift API response), and a subsequent "working" (ish) destroy-environment run it is possible for Juju to erroneously send a DELETE HTTP request to the swift account API, which in older versions of swift (and keystone) will result in the account DB for that user in swift being marked as deleted (and the only fix for this is to either a) wait for a cron'd script to clean it up, or b) get someone to manually delete the sqlite3 db for that account hash).

Although I've been unable to find the condition in the environment (e.g. writing/loading the jenv, doing the Remove*(...) calls etc.), but I'm 99.9% recurring that this is the cause for the issue I've had with my Swift account getting into a hard-to-recover state

I've added a simple check to provider/openstack/storage.Remove(...) to ensure the containerName isn't empty (which on a call to delete the container itself, the last step in a destroy env cleanup, will result in a DELETE call to the base URL instead, which swift+keystone will gladly oblige in some OpenStack setups).

I couldn't figure out how to test this correctly, due to the way the Storage instance is created/used in the openstack tests, so any pointers on this would be appreciated.

I feel it's more important to catch this nasty edgecase here above finding it's cause in the env handling purely because it is so destructive in the openstack provider compared to others (e.g. you can't remove the base in S3 so easily).
responding to review changes
Set/fix best known facade version for DiskManager
Merge pull request #1120 from davecheney/213-set-strings-refactor

all: update dependencies.tsv and callers to set.Strings change

Update all uses of set.Strings, for #86/#87 from juju/utils

TODOs will be addressed in a followup PR

There are no uses of `set.Tags` in the codebase.
Merge pull request #1111 from axw/worker-diskmanager

Introduce diskmanager worker

This pull request introduces a new worker that
periodically lists block devices on the machine,
and reports them to the API server. The purpose
of this is so that attached disks can be allocated
to units for their use (e.g. to expand a Ceph
installation.)

Diskmanager is not yet being used, as the state
collection has not been implemented in this pull
request; this will be done in a follow-up. When
that is done, the diskmanager will be run on all
machine agents. The worker is currently a no-op
worker on Windows.