Modified PowerShell Charm resources dir.
Update dependencies and fix intermittent test failure.
Merge pull request #1110 from howbazaar/remove-logged-error

Update dependencies and fix intermittent test failure.

The enqueued and done time of actions are now rounded to the nearest second.
I don't think that we care about nanosecond precision for when we decided to do some action.
The logged error call sites were changed.  Some of the calls were just plain wrong and a simple logging statement was sufficient.
Merge pull request #1085 from aznashwan/PS-charms-modules

Modified PowerShell Charm resources dir

Now all supporting modules for the PowerShell Juju Charms will be located under $env:JUJU_CHARM_DIR\lib\Modules\
State: Add EnvUUID to Network docs

Add three upgrade steps. The first two prepend the envuuid to the _id of networks and requestedNetworks doc as well as add a env-uuid field. The third step only adds the env-uuid field to the networkInterfaces doc.

Update helper functions in state/upgrades_test.go to support optionally add only the env-uuid field, leaving the original _id value.
Merge branch 'master' of https://github.com/juju/juju into migrate-network
Merge pull request #1109 from waigani/migrate-network

State Upgrade Step: Add EnvUUID to Network docs

Add three upgrade steps. The first two prepend the envuuid to the _id of networks and requestedNetworks doc as well as add a env-uuid field. The third step only adds the env-uuid field to the networkInterfaces doc.

Update helper functions in state/upgrades_test.go to support optionally add only the env-uuid field, leaving the original _id value.
tests pass
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
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
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 branch 'master' of https://github.com/juju/juju into 212-state-multiwatcher-info-types
responding to review feedback