Comment 4 for bug 1882573

There are two different approaches for handling this but both have caveats and I am not sure which one is the best way to move forward:

1) When diffing, perform a quick scan of the bundle that we parsed from disk and emit an error for relations that lack an endpoint. The argument for such an approach is that we should probably be strict for diffs in particular as a relation might be applicable to several endpoints and we shouldn't try to infer them. This approach would contradict our docs at https://juju.is/docs/bundle-reference:

# Each side of a relation (each line) has the format
# '<application>:<endpoint>', where 'application' must also be represented
# under the 'applications' element. Including the endpoint is not stricly
# necessary as it might be determined automatically. However, it is best
# practice to do so.

However, we could interpret the "might be determined automatically" as not applicable when diffing; in which case displaying an error would be OK.

2) Try to infer the endpoint from the controller's view of the model and fall back to displaying an error in case of ambiguities. In the attached bundle files, it seems that all the missing endpoints are "juju-info" (containerd, canonical-livepatch, kubernetes-worker etc). We could add extra logic into the bundlechanges package to handle the "juju-info" endpoint but I am not that keen on doing so because we are adding magic (though one could argue that auto-injecting the "juju-info" relation is already magical) to the package. We probably also have to duplicate any added functionality into pylibjuju.

@petevg @thumper: Any recommendation? In my view, the first solution is cleaner but would appreciate some info before proceeding further.