"upgrade available" in juju status is misleading

Can you provide more details on the setup.

Is this a controller you owned and bootstrapped? Are you admin on it?

I believe the model should only show the upgrade available if the controller is up to that version and models on that controller are eligible to upgrade. I wonder if this is that you're not of high enough permissions to upgrade and that error isn't clear or if there's different logic in checking if an upgrade is available and we need to update that end.

This looks like something where we know there is an upgrade available, but
you have to upgrade the controller model before you can upgrade another
model.
 $ juju upgrade-model -m controller
then you can
 $ juju upgrade-model
In the other models.

However, this is fairly clear that we aren't communicating it well.

On Thu, Sep 27, 2018 at 4:56 PM Richard Harding <email address hidden>
wrote:

> Can you provide more details on the setup.
>
> Is this a controller you owned and bootstrapped? Are you admin on it?
>
> I believe the model should only show the upgrade available if the
> controller is up to that version and models on that controller are
> eligible to upgrade. I wonder if this is that you're not of high enough
> permissions to upgrade and that error isn't clear or if there's
> different logic in checking if an upgrade is available and we need to
> update that end.
>
> ** Changed in: juju
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1793514
>
> Title:
> "upgrade available" in juju status is misleading
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1793514/+subscriptions
>

Ok, at the start then I would update so that we don't output that a model can be upgraded unless the controller is at that version as well.

So to clarify - this happened for the _controller_ model. Juju status says:
$ juju status
Model Controller Cloud/Region Version SLA Timestamp Notes
controller canonistack-lcy01 canonistack/lcy01 2.4.1 unsupported

I bootstrapped it a while ago and I'm the admin.

I am unable to reproduce with 2.4.1. I tried 2.4.4 as well.

$ juju version
2.4.1-cosmic-amd64
$ juju status -m controller
Model Controller Cloud/Region Version SLA Timestamp Notes
controller test-2.4.1 localhost/localhost 2.4.1 unsupported 10:57:54-05:00 upgrade available: 2.4.6

Machine State DNS Inst id Series AZ Message
0 started 10.241.227.188 juju-3bbf7b-0 xenial Running

$ juju status
Model Controller Cloud/Region Version SLA Timestamp
default test-2.4.1 localhost/localhost 2.4.1 unsupported 10:58:32-05:00

Model "admin/default" is empty.
$ juju upgrade-model
best version:
    2.4.6
ERROR model cannot be upgraded to 2.4.6 while the controller is 2.4.1: upgrade 'controller' model first
$ juju upgrade-juju
best version:
    2.4.6
ERROR model cannot be upgraded to 2.4.6 while the controller is 2.4.1: upgrade 'controller' model first
$ juju upgrade-juju -m controller
best version:
    2.4.6
started upgrade to 2.4.6

I tried with the different agent-stream settings also. The only difference there was that the devel agent-stream suggested 2.5-beta1 instead of 2.4.6.

Any additional info to reproduce would be appreciated.

[Expired for juju because there has been no activity for 60 days.]

It doesn't seem obvious from earlier updates to this ticket, but this occurs when the streams.canonical.com metadata differs from the cache in the local OpenStack cloud. This bug occurs when the local cloud's syncing is broken but the controller can reach streams.c.c and see that there is an update available. What appears to be happening is that juju status is using only the presence of new versions in streams.c.c as a flag, whereas juju upgrade-juju is using streams.c.c plus the local cache.

What I think the behaviour should be is:
1) Warn when the streams.c.c and locally-available agents don't match.
2) Make juju status and juju upgrade-juju use the same check for upgrade availability, which takes into account both sources.

I think the issue is that you have to upgrade the controller first, which
is currently "juju upgrade-juju -m controller", and *then* you can upgrade
individual model agents (juju upgrade-model).

On Thu, Sep 20, 2018 at 4:20 PM Jacek Nykis <email address hidden>
wrote:

> Public bug reported:
>
> juju status told me I had upgrade available:
>
> $ juju status
> Model Controller Cloud/Region Version SLA
> Timestamp Notes
> controller canonistack-lcy01 canonistack/lcy01 2.4.1 unsupported
> 13:01:52+01:00 upgrade available: 2.4.3
>
> So I tried to upgrade:
> $ juju upgrade-model
> no upgrades available
> $ juju upgrade-juju
> no upgrades available
>
> It's not clear whether the upgrade really is available or not. If it is
> then juju client should handle it better.
> I think first improvement could be to ensure that "juju status" and "juju
> upgrade-{juju,model}" use the same method to detect available upgrades.
>
> juju client I'm running is 2.4.1-xenial-amd64
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1793514
>
> Title:
> "upgrade available" in juju status is misleading
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1793514/+subscriptions
>

Per #4, he was trying to upgrade using the selected "controller" model.

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.