Unable to retrieve application status from non-leader units

[Dmitrii Shcherbakov]

status-get has --application option which allows to retrieve application status and status of all units in that application.

There is, however, no way to retrieve the application status only (not the status of all units) from non-leader units. This seems strange considering there is a way to read leader data from non-leader units.

Usage: status-get [options] [--include-data] [--application]
# ...
Options:
--application (= false)
    print status for all units of this application if this unit is the leader

root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm# is-leader
False

root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm# status-get --application
ERROR finding application status: this unit is not the leader

juju run --unit apache-httpd/0 'status-get --application --include-data'
application-status:
  message: httpd app is ready
  status: active
  status-data: {}
  units:
    apache-httpd/0:
      message: httpd is ready
      status: active
      status-data: {}
    apache-httpd/1:
      message: httpd is ready
      status: active
      status-data: {}

[John A Meinel (jameinel)]

What is the use case for reading it? I want to watch out that it doesn't
become a mini peer relation that doesn't send notifications. Originally
there wasn't a status-get as it was meant to be a message for humans. We
added it so frameworks can see if a charm has set a status so the framework
doesn't clobber it.
What do non leader units need to read it for?

John
=:->

On Tue, Oct 29, 2019, 15:40 Dmitrii Shcherbakov <email address hidden>
wrote:

> Public bug reported:
>
> status-get has --application option which allows to retrieve application
> status and status of all units in that application.
>
> There is, however, no way to retrieve the application status only (not
> the status of all units) from non-leader units. This seems strange
> considering there is a way to read leader data from non-leader units.
>
> Usage: status-get [options] [--include-data] [--application]
> # ...
> Options:
> --application (= false)
> print status for all units of this application if this unit is the
> leader
>
> root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm#
> is-leader
> False
>
> root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm#
> status-get --application
> ERROR finding application status: this unit is not the leader
>
> juju run --unit apache-httpd/0 'status-get --application --include-data'
> application-status:
> message: httpd app is ready
> status: active
> status-data: {}
> units:
> apache-httpd/0:
> message: httpd is ready
> status: active
> status-data: {}
> apache-httpd/1:
> message: httpd is ready
> status: active
> status-data: {}
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> status-get has --application option which allows to retrieve application
> status and status of all units in that application.
>
> - There is, however, no way to retrieve application status from non-leader
> - units. This seems strange considering there is a way to read leader data
> - from non-leader units.
> + There is, however, no way to retrieve the application status only (not
> + the status of all units) from non-leader units. This seems strange
> + considering there is a way to read leader data from non-leader units.
>
> Usage: status-get [options] [--include-data] [--application]
> # ...
> Options:
> --application (= false)
> - print status for all units of this application if this unit is the
> leader
> + print status for all units of this application if this unit is the
> leader
>
> -
> - root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm#
> is-leader
> + root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm#
> is-leader
> False
>
> root@juju-382280-1:/var/lib/juju/agents/unit-apache-httpd-1/charm#
> status-get --application
> ERROR finding application status: this unit is not the leader
>
> -
> juju run --unit apache-httpd/0 'status-get --application --include-data'
> application-status:
> - message: httpd app is ready
> - status: active
> - status-data: {}
> - units:
> - apache-httpd/0:
> - message: httpd is ready
> - statu...

[Dmitrii Shcherbakov (dmitriis)]

Good question.

I agree that allowing charm authors to make minion unit states to be dependent on application status without notifications is going to lead to charm bugs, e.g. something like this:

if app.status == 'active' and is_unit_active:
    unit.status = 'active'
else:
    unit.status = 'maintenance'

would be problematic and leader data (peer relation app data) would be a better fit for something like this.

Thinking about this again, I can't find a good reason for units to be able to access app status compared to leader settings so maybe we can close this as "invalid" then.