Harness provides no means to test ops.model.Application.planned_units()

The test harness provides no means to test what happens when a charm is scaled up or down and its logic relies on ops.model.Application.planned_units(). This could be addressed via a ops.testing.Harness.set_planned_unit(<int>) handle and, to my understanding, should fire a config_change event.

[pengale]

Thank you for the discussion here.

I think that I have a better idea of some of the historical intent in the harness code, and I’m more on board with letting folks directly set planned_units, rather than forcing them to add a peer.

I can work on putting together a PR addressing this. Though I think that, as noted above, @mmanciop’s use case probably does need to be addressed by adding a peer relation, as the most consistent (and correct, I think) way of a charm getting information about its peers.

[jameinel]

I would probably just add testing.Harness.set_planned_units(N) and not try to abstract through goal-state. Yes it happens to be implemented that way, but if we can change the response from get_planned_units() rather than having a charm author go via a deprecated interaction. (We may have to have set_planned_units generate a fake goal-state response, but I would want that hidden underneath Harness and not exposed to the charmer)

At present juju doesn’t generate an event when goal state changes (one of its many failings), so there isn’t an equivalent event for the framework to generate. But at the very least having Harness.set_planned_units() would let charmers test their logic around what the number of units they expect to see, and how many units show up from add_relation_unit.

On Wed, Oct 20, 2021 at 9:09 AM Pete Vander Giessen < @.***> wrote:

@mmanciop https://github.com/mmanciop to get the planned units information out of the system, you need to proactively seek it. Goal state is a reflection of changes elsewhere, but changes to goal state do not cause hooks to fire. (I think that this is part of the reason that we’re trying to move away from it!)

I’m tempted to suggest adding your logic checking goal state to the config changed hook, because that fires often. But we are trying to move away from that pattern across Juju.

It might be that you do need to add a peer relation here, not to exchange information like a username and password, but simply to allow the peers to tell each other that they exist.

@juanmanuel-tirado https://github.com/juanmanuel-tirado @jameinel https://github.com/jameinel do you have any thoughts on this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/636#issuecomment-947649993, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7PCDDYENLAKT73FUF3UH25PRANCNFSM5FO57YWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.