`juju deploy bundle` downgrades a charm or switches the charm sources unconditionally

[Nobuto Murata]

Let's say I have a model deployed by a bundle. After some time, I wanted to apply a hot fix to a specific charm so I did:
juju upgrade-charm <app> --switch ~mynamespace/charm-with-hotfix

On the other day, I just run a bundle again for some changes such as setting one config for another charm or adding a relation from one app to the other. Then Juju executed upgrade-charm with the behavior of `upgrade-charm --switch` even though the user didn't specified it or wanted to do that. Then Juju wiped out the hotfix and applied the default charm which broke the environment by having the original issue again.

From an idempotency point of view, Juju may be doing the right thing. But switching the charm source is a dangerous operation as Juju itself states as follows:

[juju upgrade-charm -h]
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will succeed,
> regardless of potential havoc, so long as the following conditions hold:

So `juju deploy bundle` shouldn't casually add the dangerous `--switch` behavior out of the box, but warn users like the `--trust` flag.

[The actual output]

Let's say this "ubuntu-lite-test-do-not-use" has a hotfix.

$ juju status --format yaml ubuntu-lite | grep charm:
    charm: cs:~johnsca/ubuntu-lite-test-do-not-use-0

$ juju deploy ./bundle_ubuntu.yaml
Resolving charm: cs:~jameinel/ubuntu-lite-7
Executing changes:
- upload charm cs:~jameinel/ubuntu-lite-7 for series bionic
- upgrade ubuntu-lite to use charm cs:~jameinel/ubuntu-lite-7 for series bionic
Deploy of bundle completed.

Then, the charm source has been switched without a warning thus the hotfix is lost.

$ juju status --format yaml ubuntu-lite | grep charm:
    charm: cs:~jameinel/ubuntu-lite-7

[Nobuto Murata (nobuto)]

juju version: 2.8.6-focal-amd64

[Nobuto Murata (nobuto)]

It actually allows downgrades unconditionally which is different from my expectation.

$ juju deploy ./bundle_ubuntu.yaml

$ juju upgrade-charm ubuntu
Added charm "cs:ubuntu-16" to the model.

$ juju deploy ./bundle_ubuntu.yaml
Resolving charm: cs:ubuntu-15
Executing changes:
- upload charm cs:ubuntu-15 for series bionic
- upgrade ubuntu to use charm cs:ubuntu-15 for series bionic
Deploy of bundle completed.

^^^ doesn't warn or stop even though cs:ubuntu-15 is a downgrade.

[Nobuto Murata (nobuto)]

Subscribing ~field-high as it broke PS5 deployment with this "unexpected" behavior while it wasn't in production.

IMHO, downgrading a charm or switching a charm source should be blocked by default and should require a explicit flag to `juju deploy` similar to --trust (default: false).

[Pen Gale (pengale)]

I disagree with this being field high.

You asked Juju to apply a bundle that called out specific versions of a charm, and it did so. This is consistent with the way that it has behaved for a long while.

I agree that this existing behavior is dangerous. I think that we should probably do some introspection in cases like this, and warn the user before proceeding. But it would not be appropriate to treat a behavioral change like that as a bugfix, appropriate for a point release.

Removing field high for now, triaging as high, and adding to the 3.0.0 milestone. (If this turns out to be a large chunk of work, we can drop it into the roadmap as a blue item -- I think that this is an important sharp edge to remove, even if it delays other feature work.)

[John A Meinel (jameinel)]

If you deploy a bundle that explicitly targets something, then juju will switch to that thing. Whether that is a different revision of a charm, or a different channel.
You can run 'juju deploy --dry-run' to see what Juju will do if you want to check first. And I can see possibilities around "change this from normal and pin it in some fashion that you have to unpin it in the future", but for now we don't intend to change this behavior.