juju deploy ./bundle.yaml on an existing model causes all units to run config-changed even with no changes

[Xav Paice]

Juju 2.8.10 on Bionic.

Ran the following:

juju export-bundle --filename bundle.yaml

Remove an application and it's machines

juju deploy ./bundle.yaml --verbose --dry-run --map-machines existing

The bundle deploy marked a few changes that weren't expected,
Changes to deploy bundle:
- set application options for aodh
  setting options:
    action-managed-upgrade: false
- set application options for ceilometer
  setting options:
    action-managed-upgrade: false
- set application options for ceph-mon
  setting options:
    monitor-count: 3
- set application options for ceph-osd
  setting options:
    aa-profile-mode: "disable"
- set application options for ceph-radosgw
  setting options:
    restrict-ceph-pools: false
- set application options for cinder
  setting options:
    action-managed-upgrade: false
- set application options for cinder-ceph
  setting options:
    restrict-ceph-pools: false
- set application options for designate
  setting options:
    action-managed-upgrade: false
(etc, etc)

None of these options were changed.

When running without --dry-run this caused config-changed hooks to run where they shouldn't have. Though we're aware these should be idempotent and not do restarts unless needed, that's a separate issue to raise against each charm.

[Ian Booth (wallyworld)]

Unless config has actually changed, we should not be running config-changed hooks.
Note though that config-changed is also run when:
 trust changes
 machine addresses change

So maybe the machines to which the units are assigned are somehow triggering an address change to be recorded and this a config change event.

Needs investigation.

[John A Meinel (jameinel)]

I wonder if this is a case where when you export the bundle we explicitly list all config values for the applications, even if they aren't different from the default, and then pushing that back into the model forces them to the exact value (vs just inheriting default), which is a change to the map that holds config, even though it isn't a functional change to the config for the charm.

[John A Meinel (jameinel)]

not fixing in the 2.8 series

[Xav Paice (xavpaice)]

This was a 2.8.10 model, so the default settings weren't exported. I simply exported, edited a few settings, then ran deploy - only the changes should have caused hook execution.

As far as I'm aware there were no address changes or trust changes - though that would want confirming.

I think this should be reasonably easy to reproduce since it's not new behavior and we won't need that particular model.

[Ian Booth (wallyworld)]

I have found that if the bundle contains values for a charm option where the value in the bundle is the same as the charm default, then the diff which is done includes such config values in the change set, because only non-default values are included when doing the diff of what's in the juju model vs what's in the new bundle yaml.

So the ceph-osd charm has this

aa-profile-mode | string
Default: disable

If the bundle has this:
  ceph-osd:
     charm: ceph-osd
      options:
        aa-profile-mode: disable

Then the export and redeploy workflow will think the aa-profile-name has changed since it is filtered out of what's been deployed before the client side diff is done.

I also noticed testing on 2.9 that juju thinks the charm itself needs to be re-uploaded.

[Ian Booth (wallyworld)]

We'll be able to get this into 2.8.11 - it was just a small client side fix

https://github.com/juju/juju/pull/13056

[Heitor (heitorpbittencourt)]

Can we reopen this bug?

I was able to redeploy a bundle in December, but now, without changing the controller, I can´t redeploy a bundle anymore.

[Ian Booth (wallyworld)]

Can you clarify what the problem you are seeing is? Are you saying trying to redeploy a bundle results in an error? That seems like a different issue to what this bug describes, which is that a bundle can be redeployed but it ran the config-changed hooks. Feel free to open a new bug with details of any new issue, including juju version of the client, controller, and model.