Merge lp:~jameinel/juju-core/1.18-refuse-downgrade-1299802 into lp:juju-core/1.18
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | John A Meinel | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 2264 | ||||
Proposed branch: | lp:~jameinel/juju-core/1.18-refuse-downgrade-1299802 | ||||
Merge into: | lp:juju-core/1.18 | ||||
Diff against target: |
67 lines (+34/-1) 3 files modified
state/testing/agent.go (+2/-0) worker/upgrader/upgrader.go (+10/-0) worker/upgrader/upgrader_test.go (+22/-1) |
||||
To merge this branch: | bzr merge lp:~jameinel/juju-core/1.18-refuse-downgrade-1299802 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Juju Engineering | Pending | ||
Review via email: mp+214878@code.launchpad.net |
Commit message
worker/upgrader: Refuse to downgrade
We've always considered the possibility of rolling back an upgrade with
"juju upgrade-juju --version=$OLD", however we never actually
implemented downgrade logic. And the new upgrade steps aren't actually
reversible. Bug #1299802 happened because 1.18 changes some state on
disk vs 1.16. It also has a race condition during upgrade where a 1.16
Unit agent upgrades faster than its Machine agent. When the API server
is 1.18, it will tell the Unit agent that it should actually match its
Machine agent version, thereby causing it to try to downgrade back to
1.16. What that actually does is just roll back to the 1.16 tools which
are now incompatible with the 1.18 agent.conf file.
Since we don't actually support rollback of upgrades, this just changes
the upgrader to refuse to change version to something older than
version.Current.
Description of the change
worker/upgrader: Refuse to downgrade
We've always considered the possibility of rolling back an upgrade with
"juju upgrade-juju --version=$OLD", however we never actually
implemented downgrade logic. And the new upgrade steps aren't actually
reversible. Bug #1299802 happened because 1.18 changes some state on
disk vs 1.16. It also has a race condition during upgrade where a 1.16
Unit agent upgrades faster than its Machine agent. When the API server
is 1.18, it will tell the Unit agent that it should actually match its
Machine agent version, thereby causing it to try to downgrade back to
1.16. What that actually does is just roll back to the 1.16 tools which
are now incompatible with the 1.18 agent.conf file.
Since we don't actually support rollback of upgrades, this just changes
the upgrader to refuse to change version to something older than
version.Current.
Reviewers: mp+214878_ code.launchpad. net,
Message:
Please take a look.
Description:
worker/upgrader: Refuse to downgrade
We've always considered the possibility of rolling back an upgrade with
"juju upgrade-juju --version=$OLD", however we never actually
implemented downgrade logic. And the new upgrade steps aren't actually
reversible. Bug #1299802 happened because 1.18 changes some state on
disk vs 1.16. It also has a race condition during upgrade where a 1.16
Unit agent upgrades faster than its Machine agent. When the API server
is 1.18, it will tell the Unit agent that it should actually match its
Machine agent version, thereby causing it to try to downgrade back to
1.16. What that actually does is just roll back to the 1.16 tools which
are now incompatible with the 1.18 agent.conf file.
Since we don't actually support rollback of upgrades, this just changes
the upgrader to refuse to change version to something older than
version.Current.
https:/ /code.launchpad .net/~jameinel/ juju-core/ 1.18-refuse- downgrade- 1299802/ +merge/ 214878
(do not edit description out of merge proposal)
Please review this at https:/ /codereview. appspot. com/85710044/
Affected files (+36, -1 lines): agent.go upgrader/ upgrader. go upgrader/ upgrader_ test.go
A [revision details]
M state/testing/
M worker/
M worker/
Index: [revision details] 20140402091849- omo4q058vgwqp3o o
=== added file '[revision details]'
--- [revision details] 2012-01-01 00:00:00 +0000
+++ [revision details] 2012-01-01 00:00:00 +0000
@@ -0,0 +1,2 @@
+Old revision: tarmac-
+New revision: <email address hidden>
Index: state/testing/ agent.go testing/ agent.go' agent.go 2014-03-12 22:33:09 +0000 agent.go 2014-04-09 04:50:46 +0000
=== modified file 'state/
--- state/testing/
+++ state/testing/
@@ -10,6 +10,8 @@
// SetAgentVersion sets the current agent version in the state's nAgentVersion but it doesn't require nConfig( map[string] interface{ }{"agent- version" :
// environment configuration.
+// This is similar to state.SetEnviro
that
+// the environment have all agents at the same version already.
func SetAgentVersion(st *state.State, vers version.Number) error {
return st.UpdateEnviro
vers.String()}, nil, nil)
}
Index: worker/ upgrader/ upgrader. go upgrader/ upgrader. go' upgrader/ upgrader. go 2014-03-21 03:27:16 +0000 upgrader/ upgrader. go 2014-04-09 04:50:46 +0000 Compare( version. Current. Number) < 0 { Infof(" desired tool version: %s is older than current %s, Version. Number { Infof(" upgrade requested from %v to %v", currentTools. Version,
=== modified file 'worker/
--- worker/
+++ worker/
@@ -112,6 +112,16 @@
case <-dying:
return nil
}
+ if wantVersion.
+ // See also bug #1299802 where when upgrading from
+ // 1.16 to 1.18 there is a race condition that can
+ // cause the unit agent to upgrade, and then want to
+ // downgrade when its associate machine agent has not
+ // finished upgrading.
+ logger.
refusing to downgrade",
+ wantVersion, version.Current)
+ continue
+ }
if wantVersion != currentTools.
logger.
wantVersion)
// TODO(dimitern) 2013-10-03 bug #1234715
Index: worker/ upgrader/ upgrader_ test.go
=== modif...