…r versions;

If the VolumeAttachmentPlan is already in Dying, treat DetachVolume as a
no-op.
Because if you *don't* have a plan, and VolumeAttachment is already
Dying, DetachVolume was already a no-op. VolumeAttachmentPlan exists to
get a sync from the machine agent that it needs to run a local command,
and then progress the system by calling RemoveVolumeAttachmentPlan.
If we have already progressed the Plan to Dying, there is nothing else
to do.

This doesn't handle the 'juju destroy-machine --force' case, where the
remote machine will never call RemoveVolumeAttachmentPlan on its own,
but it does prevent us from getting 'state changing too quickly'.

… avoid leaks.

…hanging-1860542

juju#11139

### Checklist

 - [x] Checked if it requires a [pylibjuju](https://github.com/juju/python-libjuju) change? (no)
 - [x] Added [integration tests](https://github.com/juju/juju/tree/develop/tests) for the PR? (no, but has a direct unit test)
 - [x] Added or updated [doc.go](https://discourse.jujucharms.com/t/readme-in-packages/451) related to packages changed? (no)
 - [x] Do comments answer the question of why design decisions were made?

----

## Description of change
If the VolumeAttachmentPlan is already in Dying, treat DetachVolume as a no-op.

If you *don't* have a plan, and VolumeAttachment is already Dying, DetachVolume was already a no-op. VolumeAttachmentPlan exists to get a sync from the machine agent that it needs to run a local command, and then progress the system by calling RemoveVolumeAttachmentPlan.
If we have already progressed the Plan to Dying, there is nothing else
to do.

This doesn't handle the 'juju destroy-machine --force' case, where the
remote machine will never call RemoveVolumeAttachmentPlan on its own,
but it does prevent us from getting 'state changing too quickly'.

## QA steps

The newly added test would fail with "state changing too quickly", with the patch, it now properly is treated as a no-op.

## Documentation changes

None.

## Bug reference

https://bugs.launchpad.net/juju/+bug/1860542

juju#11141

During analysis of the goroutine leak on prodstack, we identified that there was a leak of provisioner tasks. Analysing the code, we found that the creation of the availability zone map for the task was done after the task loop was started, but if an error occurred, the task was never killed.

This fix also looks like it will address the error case where a new machine was started but it was not able to log in due to a second active task having reset its password.

## QA steps

Run the tests.

## Documentation changes

Internal change only, nothing to document.

The old_model we have only contains the model name, not the
user-qualified one. Update the template to include the username (which
is always admin for this test.

We haven't been able to reproduce this error locally in a reliable
way unfortunately.

juju#11144

## Description of change

The old_model we have only contains the model name, not the user-qualified one. To ensure it matches the error that comes back with the user name, include the username in the template (it's always "admin" in the test).

Example of the error: https://jenkins.juju.canonical.com/job/nw-destroy-model-lxd/2210/console

We haven't been able to reproduce this error locally in a reliable way unfortunately, which is why there's a bit of churn in this test.

## QA steps

Run the destroy-model test, it passes.

## Documentation changes

None

## Bug reference

None

…t need this permission anymore;

juju#11137

## Please provide the following details to expedite Pull Request review:

### Checklist

 - [x] Checked if it requires a [pylibjuju](https://github.com/juju/python-libjuju) change?
 - [x] Added [integration tests](https://github.com/juju/juju/tree/develop/tests) for the PR?
 - [x] Added or updated [doc.go](https://discourse.jujucharms.com/t/readme-in-packages/451) related to packages changed?
 - [x] Do comments answer the question of why design decisions were made?

----

## Description of change

Changed to use `Reconfigure` API for disk resizing;

## QA steps

```console
# bootstrap to vSphere
# then add-machine
juju add-machine --constraints root-disk=25G

# ssh into the machine to check disk size
df -h
```

## Documentation changes

No(Internal change);

## Bug reference

No

stoppage when an error is returned by populateAvailabilityZoneMachines.

Always add a test for in-theatre bugs previously uncovered.

juju#11146

### Checklist

 - [x] Checked if it requires a [pylibjuju](https://github.com/juju/python-libjuju) change?
 - [x] Added [integration tests](https://github.com/juju/juju/tree/develop/tests) for the PR?
 - [x] Added or updated [doc.go](https://discourse.jujucharms.com/t/readme-in-packages/451) related to packages changed?
 - [x] Do comments answer the question of why design decisions were made?

----

## Description of change

This patch simply adds a unit test to verify the change made in juju#11141.

It should be a golden rule that where we fix a bug from the field for functionality without test coverage, that coverage gap is closed.

## QA steps

Unit tests fail sans juju#11141, but pass with it applied.

## Documentation changes

None.

## Bug reference

N/A

Instead of writing each service definition and it's exec-start script
into a service folder in /lib/systemd/system and using dbus (systemd) to
link them into /etc/systemd/system, we write them directly to
/etc/systemd/system.

This change was required to support Focal Fossa (20.04) which has these
two directories on different partitions, causing systemd to fail.

The linking step remains for now, though it effectively does nothing -
the service definitions are in the default search path, so reloading the
systemd daemon should be sufficient to have them loaded.

juju#11147

### Checklist

 - [x] Checked if it requires a [pylibjuju](https://github.com/juju/python-libjuju) change?
 - [x] Added [integration tests](https://github.com/juju/juju/tree/develop/tests) for the PR?
 - [x] Added or updated [doc.go](https://discourse.jujucharms.com/t/readme-in-packages/451) related to packages changed?
 - [x] Do comments answer the question of why design decisions were made?

----

## Description of change

This patch changes the location of systemd unit files and start-up scripts.

Instead of writing each service definition and it's exec-start script into a service folder in `/lib/systemd/system` and using dbus (systemd) to link them into `/etc/systemd/system`, we write them directly to `/etc/systemd/system`. This means the exec-start script is co-located with its service definition and prefixed with the service name.

This change was required to support Focal Fossa (20.04) which has these two directories on different partitions, causing systemd to fail.

The linking step remains for now, though it effectively does nothing - the service definitions are in the default search path, so reloading the systemd daemon should be sufficient to have them loaded.

Subsequent patches will take care of any required upgrade paths, including upgrading the OS series.

## QA steps

- Bootstrap to Focal: `juju bootstrap lxd systemd-test-focal --bootstrap-series focal --debug --no-gui --force --config image-stream=daily`.
- SSH to the controller machine and observe the shutdown, database and machine services and scripts in `etc/systemd/system`.
- `juju add-machine --series focal`
- `juju deploy cs:ubuntu-13 -n 2 --to 0,0 --series focal --force`
- `juju ssh 0` and observe the service units/scripts are present in `/etc/systemd/system`.
- `juju remove-unit ubuntu/1` and observe that the service and script for the unit disappear.

## Documentation changes

None.

## Bug reference

https://bugs.launchpad.net/juju/+bug/1860432

WriteSystemdAgents.

upgrade steps and series upgrade.

path for the juju-db service instead of the old /lib/systemd... path.

…n-test

juju#11150

## Description of change

Fixes controller integration test to look in the standard Systemd search path for the juju-db service instead of the old /lib/systemd... path.

## QA steps

- `cd tests`
- `./main.sh controller`

## Documentation changes

None.

## Bug reference

N/A

juju#11149

### Checklist

 - [x] Checked if it requires a [pylibjuju](https://github.com/juju/python-libjuju) change?
 - [x] Added [integration tests](https://github.com/juju/juju/tree/develop/tests) for the PR?
 - [x] Added or updated [doc.go](https://discourse.jujucharms.com/t/readme-in-packages/451) related to packages changed?
 - [x] Do comments answer the question of why design decisions were made?

----

## Description of change

This patch is a follow-up to juju#11147 and precedes forthcoming work on accompanying upgrade steps.

It is refactoring only; removing an unused argument and adding various modularisations.

Accompanying mocks are regenerated.

## QA steps

No functional changes. Unit tests pass.

## Documentation changes

None.

## Bug reference

N/A