On Mon, Mar 31, 2014 at 9:30 PM, Aaron Bentley
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14-03-30 03:23 AM, John Meinel wrote:
> > I thought at one point we were explicitly requiring that we
> > bootstrap exact versions of tools (so juju CLI 1.17.2 would only
> > bootstrap a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-17 06:34 AM, Andrew Wilkins wrote:
>> Bootstrap will continue to set agent-version to the most recent
>> matching major.minor, so the machine agent will immediately
>> upgrade to that when it comes online.
I don't understand this-- I don't kn
On Thu, Apr 17, 2014 at 8:27 PM, Aaron Bentley
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14-04-17 06:34 AM, Andrew Wilkins wrote:
> >> Bootstrap will continue to set agent-version to the most recent
> >> matching major.minor, so the machine agent will immediately
> >> upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-17 08:40 AM, Andrew Wilkins wrote:
>> Okay. It's possible to do what you want too (see below), but I
>> don't think it's sensible to make that the default behaviour.
I think that using a tested combination of client and agent is the
most sens
On Thu, Apr 17, 2014 at 1:03 AM, John Meinel wrote:
> So backup and restore in its original incarnation was just writing down in a
> set of scripts what we were performing at the time to make backup/restore
> work at a given site. They were a bit hackish to start with.
...
> The question is whethe
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-17 11:48 AM, John Meinel wrote:
> FWIW that isn't what you get if you do "apt-get install foo"
That is fine *if* you do apt-get install foo.
But the user isn't doing apt-get install juju-core. They're just
doing juju bootstrap. They should
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).
I honestly think it is good policy to give updated versions when we get a
chance to do so. We aren't trying to cross Minor vers
-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
http://launchpad.ne
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* n
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 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 the others should take over.
>
> ...
>
> There is one major caveat: upgrading an exis
On Fri, Apr 18, 2014 at 9:12 AM, Richard Harding 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 the others should
The CLI now goes exclusively through the API, so you should be able to
drive it from the GUI as well.
We'll probably need more focused APIs for getting the status of state
machines (right now I think we just put it into "Status" itself, and we'll
want to have a way to get just that information out
16 matches
Mail list logo
