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

[Vern Hart]

Most juju commands allow you to specify `-m model` to operate in a different model than the current model. Additionally, you can specify JUJU_MODEL as an environment variable to override the current model context.

The only commands that operate in the context of a model but don't allow you to use -m or JUJU_MODEL to set the model have to do with cross model relations:

    juju offer
    juju show-offer
    juju find-offers
    juju remove-offer

Interestingly, the following cmr related commands DO honor the -m argument:

    juju list-offers
    juju offers

It would be nice if I could create an offer (juju offer) without affecting the current model.

[Ian Booth (wallyworld)]

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.

[Mike Wilson (knobby)]

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.

[Vern Hart (vern)]

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.

[Ian Booth (wallyworld)]

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

[Mike Wilson (knobby)]

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.

[Canonical Juju QA Bot (juju-qa-bot)]

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.

[Romain Couturat (romaincout)]

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

[Ian Booth (wallyworld)]

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.

[Alex Lutay (taurus)]

I was planning to bugreport async DB usability problem and noticed this issue.

I confirm the following command does the job well!
> juju offer mymodel.mysql:endpoint

All the explanations about model/controller belongings make sense, but...
in the same same time it is so counterintuitive!

Is it possible to create alias:

> juju offer -m mymodel mysql:endpoint

to behave identically to:

> juju offer mymodel:mysql:endpoint

To be more newbies friendly! Tnx!