/juju

Introduce environ/provider versioning #7599

Merged
merged 2 commits into from Jul 7, 2017

Conversation

Reviewers

@babbageclunk babbageclunk

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@axw @jujubot @babbageclunk
@axw
Member

axw commented Jul 5, 2017 •
Edited 1 time

Description of change

Environs (i.e. the cloud representation of
a model) are now versioned, so that we can
upgrade them as necessary. Previously this
has been done as part of controller upgrades,
but this poses a problem when the environs
cannot be opened; thus we seek to decouple
the upgrading of a model's environ from the
upgrading of the controller.

EnvironProvider now has a Version method,
which returns the current/most up-to-date
environ version. Model docs now record the
version of the model's associated environ.
Environ upgrade operations specify an
environ/provider version, rather than
controller/agent version.

Once this lands, we will introduce a new
worker that will run under the model
dependency engine to upgrade the model's
environ, and which will gate access to the
model until that has happened.

Requires juju/description#16

(There is a drive-by fix in state/upgrade.go, to stop checking for env-uuid upgrades. That all happened before 2.0, so we don't need to carry that code anymore.)

QA steps

No functional changes. Bootstrap azure with 2.1.x, juju upgrade-juju to this branch.

Documentation changes

None.

Bug reference

Part of the fix for https://bugs.launchpad.net/juju/+bug/1700451

@axw axw referenced this pull request Jul 6, 2017

Merged

Separate model environ upgrades from controller upgrades #7602

@babbageclunk

babbageclunk approved these changes Jul 7, 2017
View changes

This looks good to me - just a couple of questions and things I didn't quite follow.

environs/interface.go
@@ -436,5 +437,12 @@ type UpgradeStep interface {
Description() string
// Run executes the upgrade business logic.
- Run() error
+ Run(UpgradeStepParams) error
@babbageclunk

babbageclunk Jul 7, 2017

Member

Why did the params move from UpgradeOperations to Run?

@axw

axw Jul 7, 2017

Member

I did that because I was going to use the steps to determine the current best version. Then I added EnvironProvider.Version() instead. I'll revert this change.

state/model.go
+ if attempt > 0 {
+ if attempt == 1 {
+ mCopy := *m
+ m = &mCopy
@babbageclunk

babbageclunk Jul 7, 2017

Member

Wouldn't it be much simpler to just copy the model outside buildTxn? It doesn't seem like SetEnvironVersion would be called often enough that the extra efficiency is worth the awkwardness here.

@axw

axw Jul 7, 2017

Member

fair enough, done

upgrades/environ.go
- return upgradeToVersion{op.TargetVersion, steps}
+ // NOTE(axw) all two of the current environ upgrade steps will happily
+ // run idempotently; there are no post-upgrade steps that will render
+ // them non-runabble. This is here as a backstop, to ensure the upgrades
@babbageclunk

babbageclunk Jul 7, 2017

Member

typo - runnable.
Also, I don't really understand this comment. Are you referring to the use of jujuversion.Current instead of op.TargetVersion? Why does that make it a backstop?

@axw

axw Jul 7, 2017

Member

it's not super important, because it's gone in the next PR :)

yes, I'm referring to the use of jujuversion.Current rather than op.TargetVersion. the point I was trying to make is that this will force the upgrade steps to continue to run, until we move the logic out of controller upgrades

@babbageclunk

babbageclunk Jul 7, 2017

Member

Cool, thanks - yes, I see what you mean about the target handling in the next PR.

upgrades/environ.go
return &upgradeStep{
step.Description(),
[]Target{DatabaseMaster},
func(Context) error {
- return step.Run()
+ return step.Run(environs.UpgradeStepParams{controllerUUID})
@babbageclunk

babbageclunk Jul 7, 2017

Member

Ah - is it more convenient to write the upgrade steps if you don't need to thread this information down to the steps yourself?

axw added some commits Jul 5, 2017

@axw
Introduce environ/provider versioning 
Environs (i.e. the cloud representation of
a model) are now versioned, so that we can
upgrade them as necessary. Previously this
has been done as part of controller upgrades,
but this poses a problem when the environs
cannot be opened; thuse we seek to decouple
the upgrading of a model's environ from the
upgrading of the controller.

EnvironProvider now has a Version method,
which returns the current/most up-to-date
environ version. Model docs now record the
version of the model's associated environ.
Environ upgrade operations specify an
environ/provider version, rather than
controller/agent version.

Once this lands, we will introduce a new
worker that will run under the model
dependency engine to upgrade the model's
environ, and which will gate access to the
model until that has happened.
This commit was signed with a verified signature.
@axw axw Andrew Wilkins
GPG key ID: 55314F7628952B05 Learn about signing commits
5fae823
@axw
dependencies.tsv: update juju/description
This commit was signed with a verified signature.
@axw axw Andrew Wilkins
GPG key ID: 55314F7628952B05 Learn about signing commits
3cad2f7
@axw
Member

axw commented Jul 7, 2017

$$merge$$
@jujubot
Contributor

jujubot commented Jul 7, 2017

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

@jujubot jujubot merged commit 73fa0e4 into juju:2.2 Jul 7, 2017
1 check passed

1 check passed

github-check-merge-juju Ran tests against PR. Use !!.*!! to request another build. IE, !!build!!, !!retry!!
Details

jujubot added a commit that referenced this pull request Jul 7, 2017

@jujubot
Merge pull request #7602 from axw/worker-modelupgrader 
Separate model environ upgrades from controller upgrades

## Description of change

In 2.2 we introduced upgrade steps that would attempt to open an
Environ for every model, and run upgrade operations on the Environ
as necessary (e.g. to move VMs to folders in vSphere). If the
Environ cannot be opened, then the entire controller upgrade fails.

We now introduce a "modelupgrader" worker, which is responsible
for running controller-side upgrade operations for a model's
Environ. Other model workers must wait for this worker to complete
before they can start. If an Environ cannot be opened, or the
Environ's upgrade operations fail, only that model will be
affected.

(Requires #7599)

## QA steps

1. juju bootstrap azure azure1 (with 2.1.x)
2. juju add-model foo
(confirm there's no "common" deployment via the portal)
3. juju bootstrap azure azure2 (with this branch)
4. juju switch azure1
5. juju migrate foo azure2
(confirm there's now a "common" deployment in the portal)

The above shows that model upgrade steps are run when a model is migrated to a newer controller.

Repeat, using "juju upgrade-juju" on the original controller to show that the same works with an upgrade.

Repeat with "juju upgrade-juju", but this time inject a failure (before running the upgrade-juju command):
```
mkdir /var/lib/juju/wrench
cat fail-all > /var/lib/juju/wrench/modelupgrader
```

And confirm that the controller is upgraded, and only the model workers are broken until the wrench file is removed.

## Documentation changes

None.

## Bug reference

Fixes https://bugs.launchpad.net/juju/+bug/1700451
47b2492
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment