lp:juju-core/1.16
- Get this branch:
- bzr branch lp:juju-core/1.16
Branch merges
Related source package recipes
Branch information
Recent revisions
- 2007. By Curtis Hovey
-
[r=sinzui] Run unit-tests on trusty
Backport the lsb_release check to 1.16 the ensure the right deps are installed
to run unit-tests on trusty. - 2006. By John A Meinel
-
[r=fwereade] provider/
ec2/instancetyp es.go: correct m3 pricing There seem to be a couple of newer m3 types that are smaller (medium and
large), and the pricing for the various regions was a bit off. I know we want
to end up with all this data in simplestreams instead, but in the short term,
we might as well keep using updated values. - 2005. By Curtis Hovey
-
[r=sinzui] Increment stable to 1.16.7
- 2003. By Martin Packman
-
[r=gz] provider/common: Improve testingHTTPServer docs
r=gz
- 2002. By Martin Packman
-
[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
-
[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.) - 2000. By Curtis Hovey
-
[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.
- 1999. By William Reade
-
[r=fwereade],[bug=1259473] state: don't remove force-destroyed machines
fixes lp:1259473
- 1998. By John A Meinel
-
[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.
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp:~go-bot/juju-core/trunk
