lp://qastaging/~gz/juju-core/1.16+c2255

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

2006. By Martin Packman on 2014-02-13

Cherrypick fix for bug 1241674 to 1.16 branch

2005. By Curtis Hovey on 2014-02-12

[r=sinzui] Increment stable to 1.16.7

2004. By Ian Booth on 2014-02-11

[r=wallyworld] Update gwacl dependency to rev 231

2003. By Martin Packman on 2014-02-05

[r=gz] provider/common: Improve testingHTTPServer docs

r=gz

2002. By Martin Packman on 2014-01-31

[r=gz],[bug=1268913] Obey ssl-hostname-verification for provider-state

When reading the provider-state file from cloud storage on
bootstrap, skip validating the https cert if the config
ssl-hostname-verification is set to false.

https://codereview.appspot.com/56560043/

R=axwalk

2001. By John A Meinel on 2013-12-19

[r=jameinel],[bug=1261628] cmd/juju: alias remove-service and remove-machine

Part of bug #1261628, this lets us document 'remove-*' as the
preferred syntax for operations, since they aren't quite as "scary" as
'destroy-*'.

This is targetting 1.16 so that we can start documenting their use (in
a stable release). In trunk we could then actually rename the command
and have the old name as the alias. (So the command is
'remove-machine' with an alias of 'destroy-machine' for compatibility
purposes.)

https://codereview.appspot.com/40650048/

2000. By Curtis Hovey on 2013-12-12

[r=jameinel] Increment juju-core stable to 1.16.6

I don't think we will do a 1.16.6, but just in case.

https://codereview.appspot.com/41030044/

1999. By William Reade on 2013-12-10

[r=fwereade],[bug=1259473] state: don't remove force-destroyed machines

fixes lp:1259473

https://codereview.appspot.com/37610044/

1998. By John A Meinel on 2013-12-09

[r=jameinel],[bug=1257481] provider/openstack/provider: safer matching

bug #1257481 is because of how we are matching machines, if you have 2
environments with similar names (one is a prefix of the other) then
you can have 'juju destroy-environment short-name' actually kill all
the instances of 'short-name-but-longer'.

However, we do put a little bit more data into how we name machines,
so we can make it harder to trigger that by accident.

The actual change is small and directly tested against HP and
Canonistack. I don't add a test because the actual test we would need
is to create 2 environments, and assert that AllInstances doesn't see
the instances in a similarly named environment.

I tried 2 regexes 'juju-ENV-machine-\d+' didn't work when testing
against canonistack, so I went with 'juju-ENV-machine-\d*'. That
should be pretty restrictive. Even if you name one environment 'ENV'
and another environment 'ENV-machine' the \d will prevent them from
matching (because the actual machines will be
juju-ENV-machine-machine-0).

I think this is as safe as we can be with a name-based approach, even
though we've discussed moving into a 'record the nodes only in state
and only delete ones recorded there', this is a pretty easy workaround
to make things nicer for real people.

https://codereview.appspot.com/39030043/

1997. By John A Meinel on 2013-12-08

[r=jameinel],[bug=1256179] provider/maas/config.go: handle agent-name

Relating to bug #1256179. If you bootstrap with juju<1.16.2 you would
not have a maas-agent-name in your config. When reading that from the
Database, we don't Validate or Coerce the config content (assuming it
had only been written correctly in the past).
However, we have a check in >=1.16.2 that maas-agent-name shouldn't be
changed. (It would certainly break your environment.) Except we Coerce
new configs to treat 'nil' as "". So we have to change the Validate
check to accept that an old value of 'nil' matches a new value of ""
(and nothing else).
I'm pretty sure I covered the permutations in the new tests, but
feedback is welcome.

I do think this is 1.16 worthy, because 1.16.2 and MaaS breaks upgrade
because of this field. I also intend this to migrate up to trunk.

https://codereview.appspot.com/36490043/