Consider different approaches to power management priorities

[llucax]

Coming from #904 (review).

Currently when 2 identical requests are made to the power manager via the high-level interface (same set of components with the same priority), a warning is logged and both requests will have a deterministic but unknown priority between them (one will win, the user just don't know which one). This could lead to undesired behavior if it was done unintentionally, which could lead to problems that are hard to anticipate.

One alternative approach would be to reject the second request (by raising an exception), as suggested in #904 (comment), but there is the concern that this could lead to unnecessary crashes (#904 (comment)).

One thing that could make things worse is there is a default priority, which means users not explicitly setting a priority can potentially be hit by this at any time, as some other actor might be using the same set of components and not specifying a priority either. Maybe a way to make this less likely could be to always require passing a priority.

Follow-up issues

• Rename xxx_pool() functions to new_xxx_pool() #915
• Make the priority argument for xxx_pool() required #916

[shsms]

Maybe a way to make this less likely could be to always require passing a priority.

Completely agree, I was suggesting the same, but maybe it wasn't clear in #904 (comment)

[shsms]

I'm also still wondering if having 2 actors using the same set of components and the same priority

Now that I think about it, we already have such a case, where the PowerManager creates a *pool instance to access the _system_power_bounds method, but also an issue to fix it: #907

I can't think of any legitimate reason to have two actors having the same priority, based on our model of priorities. Even the bounds that are streamed from such pools will corresponding to their relative ordering. They will look like they have different priorities in all ways.

Having to specify a priority could be annoying for users that just have a single decision making actor in their app, which is likely to be a big proportion of the users. Is a tough problem.

[llucax]

Is a tough problem.

Yeah, this is my conclusion too. So my feeling is we'll hardly find a solution that is safe and easy to use for everyone.

One more thing that I was thinking of while looking at some code using microgrid.battery_pool() is, like with the metric receivers, maybe it would be better to make it explicit that a battery pool (or a * pool) is being created, and use new_battery_pool(...). At least for me it is much clearer that I need to save my battery pool if I use pool = microgrid.new_battery_pool(...), than if I use pool = microgrid.battery_pool(...), which looks like I'm getting an existing one. Specially when for grid() for example, we are supposed to have only one grid (singleton) object (even if we have more than one grid connection, is like we'll only have one "grid pool", I guess 🤔 ...., I hope! 😆 ).

So if you agree I will create an issue to rename those functions too.

[shsms]

True, they are constructors, it makes sense to add new_ to them.

[shsms]

and it would go some ways to prevent such issues as well.

[llucax]

• Rename xxx_pool() functions to new_xxx_pool() #915
• Make the priority argument for xxx_pool() required #916

[llucax]

FYI @frequenz-floss/python-sdk-team