juju offer doesn't support -m to act on non-current model

juju offer doesn't use -m because the model to use is part of the offer URL. This allows the offer command to work correctly across different controllers. The offer command is a so called "controller" command and not a "model" command. Many juju commands like "add-model" etc also operate as controller commands, where -m is not required.

eg
juju offer mymodel.myapp:db
juju offer myctrl:mymodel.myapp:db

Without the controller/model part of the URL, juju offer does default to the current model as would be expected.

The same logic then also applies to show/find/remove offer.
ie you show an offer based on its URL. The URL may leave out the controller and model parts, in which case it defaults to the current controller / model.

Hopefully this clarifies the usage.

That makes sense that it isn’t a model operation, but to the user it certainly is a model operation. I would expect that the user experience would be the same and these would support -m. Conceptually, we want to expose something from one model to another. The implementation detail of that information being stored on the controller shouldn’t impact the user experience of how to set it.

If offers are viewed in the controller context, then an end-user might expect `juju offers` to show all offers on the controller. Instead you have to either switch model context or use -m to specify the model.

Knowing how to make offers without switching model contexts is very useful, thank you.

To clarify a little more the semantics....

The key point is that offers are referenced/consumed via a URL, similar to a webpage. They are hosted in a model for sure, but that's irrelevant to the act of consuming.

juju offers operates on a model because it is used by an admin to see what relations exist to offer in that model and provides the data needed to make decisions about suspending/resuming a connected consumer, removing a misbehaving consumer connection etc. NB juju offers and list-offers are aliases for the same command.

juju find-offers operates on a controller because it is intended to be a way to search for any available offers matching a given interface or endpoint or even offers contained in a given controller and/or model (you specify a URL fragment).

juju show-offer allow doesn't operate on a model because it takes a full offer URL as an argument. The URL specifies the controller and model and offer name.

juju consume also takes a URL as an argument. You can leave off bits of the URL that aren't necessary, eg if both the consuming model and offering model are in the same controller you don't have to specify the controller part of the URL

I think the semantics are clear here, but my point is that as a user I just expect things to work the same. I expect `juju status -m model1` to work just like `juju add-relation -m model1 kubernetes-master etcd` to work just like `juju offer -m lma telegraf:prometheus-client`. I just assume as a user that -m does what I expect: select the model that I want to use.

I understand that the controller holds the actual data, but I think that is an implementation detail that shouldn't concern the user. They simply shouldn't worry themselves with it. They just want a consistent experience.

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

Can we reconsider the importance of this bug ?
The discrepancy is frustrating and can be unnecessarily time consuming

As a thought experiment, consider this case

juju offer -m foomodel myctrl:barmodel.mysql:db

The above doesn't make sense since a different model is specified in the offer url vs the -m arg.

Offers are specified by URL which contains the model (and optionally controller). Adding -m conflicts with this and would lead to a whole other set of problems.