"juju offers" ignores -m flag

Offers aren't model specific. They're based on the controller. I'd expect the offers command to take a controller argument to list out all offers available on that controller.

I would expect juju offers to show the list of available offers on the currently selected controller. I'm double checking permissions/ACL as I thought you just needed a valid account on the controller.

So find-offers did show the offer correctly, but at the moment I'm not able to recall what the diff in find-offers vs list-offers and since this was the same user making and running offers the error on the model seems strange.

I can do the following without error (note it works without -m also):

$ juju bootstrap aws
$ juju add-model prod-nagios
$ juju deploy nagios
$ juju offer nagios:monitors
$ juju offers -m prod-nagios --format yaml
nagios:
  application: nagios
  store: ian
  charm: cs:nagios-27
  offer-url: admin/prod-nagios.nagios
  endpoints:
    monitors:
      interface: monitors
      role: requirer
  users:
    admin:
      display-name: admin
      access: admin
    everyone@external:
      access: read

These errors:

$ juju offers
ERROR model "prod-nagios/prod-nagios" not found (not found)
$ juju offers -m "prod-nagios"
ERROR model prodstack-is:prod-nagios/prod-nagios not found
$ juju offers -m "admin/prod-nagios"
ERROR model "prod-nagios/prod-nagios" not found (not found)

imply that the "prod-nagios" model is on a different controller than the current default controller. So this would work:

$ juju offers -m <ctrlname>:prod-nagios

The above is at odds with the output of the juju models command shown in the bug description though. I would guess that there could have been a mix up perhaps in setting things up.

Can you please provide each command used from bootstrap to list-offers and I can try and reproduce from there? There should only be 5 commands as per my example.

Hello,

We are using common, long running, controller which was bootstrapped a long time ago so I did not have to bootstrap it.

The model was added using internally written automation tooling, if needed we can provide you with source code.

Once model was in place we used mojo to deploy the environment, here is the spec:
https://code.launchpad.net/~jacekn/canonical-mojo-specs/nagios

And once deployed I run the following commands:
$ juju offer nagios:monitor
$ juju offers

I run both of them from the same shell, one after another. At this stage there was no 2nd controller or model involved. I created an offer and simply wanted to confirm it was in place.

This does not work either:
$ juju offers -m <ctrlname>:prod-nagios

I tried:
$ juju offers -m prodstack-is:prod-nagios
ERROR model prodstack-is:prod-nagios/prod-nagios not found

In above output username is incorrect. Juju uses "prod-nagios/prod-nagios" but it should be "admin/prod-nagios" as per "juju models" output:

$ juju models
Controller: prodstack-is

Model Cloud/Region Status Machines Cores Access Last connection
admin/prod-nagios* prodstack-45/bootstack-ps45 available 1 1 admin 7 minutes ago

I also tried this:
$ juju offers -m prodstack-is:admin/prod-nagios
ERROR model "prod-nagios/prod-nagios" not found (not found)

But this makes it ignore controller name.

It appears there's an issue when a user other than the one who created the offer accesses it from a different controller.

@Ian Booth (wallyworld),

I think you are 100% right. Model resolution at offer command is not correct.
Instead of
```
c.NewControllerAPIRoot()
```

at https://github.com/juju/juju/blob/develop/cmd/juju/crossmodel/list.go#L87

we should be calling

```
(c *ModelCommandBase) NewAPIRoot()
```

as this will get both the correct model and the correct controller.

@anastasia, the correct API NewControllerAPIRoot() is being used (offers uses a controller facade).

The issue was simply that the api call to query the offers on the target controller omitted the owner of the model hosting the offer (hence the not found error).

@jacekn, note that juju offers command requires admin access to the model hosting the offer. It is for use by admins to allow visibility of who is connected to the offer and other such info. As a general user, who has been granted read access to the offer (or consume access), you should use the find-offers command to query a given controller to see what offers are available. If the user has read access, they can see the offers but not consume. You can specify a controller name to find all offers on a given controller, or a specific model name to find offers in just that model.

$ juju help find-offers
Usage: juju find-offers [options]

Summary:
Find offered application endpoints.

Details:
Find which offered application endpoints are available to the current user.

This command is aimed for a user who wants to discover what endpoints are available to them.

Examples:
   $ juju find-offers
   $ juju find-offers mycontroller:
   $ juju find-offers fred/prod
   $ juju find-offers --interface mysql
   $ juju find-offers --url fred/prod.db2
   $ juju find-offers --offer db2

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

@jacekn, note also that if the user running list-offers does not have read access (or higher) to the model containing the offer, they will get a not found error. list-offers is only intended to admin use. find-offers is probably what you want.

@wallyworld, thanks for the explanation.
I think it's worth updating help text for the offers command. I've just checked it and there is nothing about it being admin use only.