Well you used to be able to request a downgrade, but it never actually
worked... :)
And with the new upgrade steps, we explicitly don't implement the 'back out
these changes' logic, which is why things were breaking some-of-the-time on
upgrade. I'm not sure what I broke, but it is possible I
So I did a 1.18.0 to 1.18.1 test here (which should be the r2264 failure
that you're seeing (I'm using r2266).
I did see it upgrade successfully, but it took a surprisingly long amount
of time for all the unit agents to come up. The relevant logs (from my
point of view) are:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-10 05:41 AM, John Meinel wrote:
Well you used to be able to request a downgrade, but it never
actually worked... :)o
Could you explain that further?
We've done thousands of downgrades and juju reported that it had
switched the agent to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-10 08:23 AM, John Meinel wrote:
Note that copying off the all-machines log seems to be broken, the
lines:
juju --show-log scp -e test-release-aws -- -o
'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' -i
Actually, I was trying to fix it, and it is more broken than we realized.
We no longer support multiple extra arguments to SCP. It always complains
if there is one that isn't exactly the last one. (-o foo says it isn't
accepted, -ofoo is allowed, but you can't supply 2 of them, etc).
It just needs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-04-10 02:19 PM, John Meinel wrote:
So Juju would certainly let you run an older binary, and it would,
indeed, switch to that binary.
Phew!
I would be ok with allowing downgrades within a PATCH level, but I
think it still holds true that
So Juju would certainly let you run an older binary, and it would, indeed,
switch to that binary.
What it has *never* done is back out any actual changes to your
environment. So any upgrade that changed any data on disk (the contents of
agent.conf, a cert, something like that) would remain in the
