FWIW that isn't what you get if you do apt-get install foo you always get
the latest version of foo that has been patched, not the original one
that came with Precise.
I don't have a problem with juju bootstrap growing a --version target
(same as apt-get install foo=1.2.3). But I think our policy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-17 12:03 PM, John Meinel wrote:
If you bootstrap, you are installing juju onto the remotel machine.
The reason we created a *patched* version is to give you
improvements (bug fixes, security fixes, etc).
Sure, but if the user doesn't
lp:juju-core/trunk r2644 introduced a regression.
upgrade-juju fails on all providers
https://bugs.launchpad.net/juju-core/+bug/1309108
Unit agents are not upgrading. I attacked logs from all the failed tests.
--
Curtis Hovey
Canonical Cloud Development and Operations
I've just landed some changes on juju tip that enable highly available
juju environments. In a HA environment, there are several state servers -
if one dies, one of the others should take over.
To make a HA environment, run the ensure-availability command. For
example to make a HA environment
NOW
I moved a lot of bugs from 1.19.1 to 1.20.0 to make it easier to see
out immediate priorities. If we fix a bug in a future milestone I will
retarget it to the current goal. The intent is to make is clear what
must be fixed verses issues that may be fixed.
Their are about 20 issues I *think*
Excellent writeup. I agree with your conclusions -- we must reduce the
number of open issues, not reclassify them. My vote has always been to
close an issue that we cannot realistically fix in the next cycle, but
I understand this has always been unpopular.
On Fri, Apr 18, 2014 at 5:47 AM, Curtis
On Fri, Apr 18, 2014 at 9:12 AM, Richard Harding rick.hard...@canonical.com
wrote:
On Thu, 17 Apr 2014, roger peppe wrote:
I've just landed some changes on juju tip that enable highly available
juju environments. In a HA environment, there are several state servers -
if one dies, one of
