Means to query for pending changes to a unit

It would definitely be an API change, since all of the types returned are strings (including "status"), but using StatusInfo.Status instead of just Status, at least in `goal-state`

If the upgrade channel hasn't been sent anything yet, there's not much we can do about it, but it's worth asking

An interesting feature to discuss, but not sure that will be 'easy' to implement.

Is this being able to query from inside the charm or from an end-user?
From inside the charm, it is a bit dangerous to "look into the future for
what might happen" given that the future may change by the time you
actually get there. If there are specific things that you want to know
about, we can look to add them. `goal-state` was an original design about
peeking at the model, but the encouragement is to understand why you need
to know about parts of the model that you haven't been told yet, vs waiting
until you are told about that part of the model.

On Wed, May 18, 2022 at 1:10 PM Leon <email address hidden> wrote:

> Public bug reported:
>
> It would be handy to be able to query/list the queued/pending changes
> for a given unit.
>
> For example, when I upgrade a 2-unit app, the status shows everything as
> active/idle.
> Then, 40 seconds in, unit/1 gets upgraded.
> Another 40-70 seconds in, unit/0 gets upgraded.
>
> For integration tests it would be nice to know if there's anything
> pending that didn't happen yet.
>
> An example of a pending change that is already queryable is
> planned_units [1], via goal-state [2].
>
> [1]
>
> https://github.com/canonical/operator/blob/448c8b17efe05d1d700599496cc6a19e318f5127/ops/model.py#L1915
>
> [2] https://juju.is/docs/sdk/hook-tools#heading--goal-state
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: feature
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1974065
>
> Title:
> Means to query for pending changes to a unit
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1974065/+subscriptions
>
>

My current use case is integration tests, so it's not from inside the charm but from python-libjuju.

This is needed to avoid hard-coding empirical sleep duration to wait for a multiunit upgrade to complete. I would like to be able to know, from within an integration test, that an app is undergoing a change, or that a unit still has stuff to do.

In python-libjuju lingo: I would like to be able to tell "wait_for_idle" or "block_until" to return only after a multiunit upgrade is complete.

Currently I hardcoded "90 seconds", within which I have found my 2-unit upgrade to reliably complete.