cmr model migration breaks if both models start on the same controller

[Ian Booth]

Start with a single controller with two models and a cross model relation. Because both models are on the same controller, there is no external controller record in the consumer model database.

If either the consuming or offering model is migrated to a different controller, the consuming model now needs to poll an external controller - the offer now lives on a different controller to the consumer, but in either case (migrate offer model or migrate consuming model) there's no external controller record created and the relation breaks.

[Joseph Phillips (manadart)]

There should absolutely be an external controller record inserted as part of model migration.
This is independent of any CMR logic.

You can see where we follow redirects when watching remote relations here:
https://github.com/juju/juju/blob/e19bb41a58b5394562d84732c6af5e7b21dc1f06/worker/remoterelations/remoteapplicationworker.go#L159

[Ian Booth (wallyworld)]

Sorry, I had a brain fart here. I totally forgot about that api call. I was using the non redirect version.

EDIT: no I wasn't, was doing the right thing, see next comment

[Ian Booth (wallyworld)]

Reopening this. It looks like newRemoteRelationsFacadeWithRedirect() is broken, unless I'm missing something.

Consider this scenario. Single controller c1, two models, offer and consume.
Migrate the consume model to a new controller c2.

The remote application worker on c2 calls newRemoteRelationsFacadeWithRedirect().
This calls ControllerAPIInfoForModel().

This first looks at external controllers and there are none and as expected a not found error results and is skipped.

Then it looks for a completed migration record, ostensibly so that the target controller address can be used. But this is the consuming model moved to a new controller and there is no migration record. So it all fails.

The current implementation supports migrating the offering model off the controller, since in the case the consuming model stays behind and has access to the migration record.

So we need to look at ensuring the target controller for a consuming model migration has the necessary info shipped across so that the original controller is known to the consuming model after it comes up on the target controller.

[Ian Booth (wallyworld)]

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