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

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.

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.

not fixing in the 2.8 series

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.

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.

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

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.

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.