Closed tonyandrewmeyer closed 3 months ago
@benhoyt it would be great to get your feedback on this as well, since you're the Pebble King (tm) and also did the custom notices in Juju/ops/Harness.
By the way, I have every expectation that this might take a few rounds of review since it's my first non-trivial contribution to Scenario :smile:.
Thanks @tonyandrewmeyer. Something came up so I have a busy day tomorrow, but I hope to be able to review this Thursday or Friday.
Shall we get this moving forward again?
Shall we get this moving forward again?
Yes! Ben was keen on pausing until we had progressed the 7.0 discussions, but I think we are far enough along with those now.
If this aligns with the 7.0 style, then it would be:
notice1 = Notice(...)
notice2 = Notice(...)
container = Container("my-container", can_connect=True, notices={notice1, notice2})
state_in = State(containers={container})
state_out = ctx.run(ctx.on.my_container_pebble_custom_notice(notice=notice2), state_in)
# Presumably you would not ever want to get existing notices, since the charm can't change them, but
# could in theory call `notify()`, although it seems like the workload ought to be doing that, not the charm.
new_notice = state_out.get_container(container).get_notice(key=...)
But for the current main, then it would be:
notice1 = Notice(...)
notice2 = Notice(...)
container = Container("my-container", can_connect=True, notices=[notice1, notice2])
state_in = State(containers=[container])
state_out = ctx.run(container.get_notice(notice2.key), state_in)
new_notice = state_out.containers["my-container].get_notice(...)
I think it would be worth having this PR implement the latter (there are a couple of fixes I need to make, most of which I have locally but haven't pushed), and then a separate PR for the 7.0 branch (probably the same one that changes everything else).
@PietroPasotti could you please give this a fresh review?
Adds support for Pebble custom notices:
PebbleNotice
class, which is essentially the same as anops.pebble.Notice
but has default values to make it easier to work with in a testing context.Container
s have a newnotices
attribute, which is a list of notices that have been seen prior to the event.Container
s have a newcustom_notice_event
property, which is sugar for creating a-pebble-custom-notice
event.It seems like having the
custom_notice_event
property on the notice (and corresponding changes, likeEvent
would have anotice
attribute) would be nicer, but (pebble)Notices
don't know which container they are in, butPebbleCustomNoticeEvent
does have the container as an attribute. We can't have thePebbleNotice
know which container it is in and also have the container be passed the list of notices because that's circular. APebbleNotice
could take theContainer
as an argument, and could 'register' itself on the container, but that doesn't seem like the Scenario way.This also forces the sugar to be for the most recent notice (more precisely: the last one in the list) in the container, but that does seem reasonable - it seems like this would be the behaviour in Juju as well.
Another option would to not have the sugar (and
Event
could take anotice
), but it does seem like it's both nicer and more Scenario if it is there. Happy to get feedback on this!The required version of ops is bumped to 2.10 to get the Pebble custom notices support there (particularly in the mock Pebble client).
There are a few small adjustments to support a second type of pebble/workload event.
I had hoped to have
PebbleNotice
inherit fromops.pebble.Notice
(and_DCBase
) They are both frozen dataclasses, but in Scenario it's better if there are suitable default values for everything except the key, but the key isn't the first argument for a pebbleNotice
, so this generates errors if done simply. Nothing else in Scenario is currently doing this, so it seems ok, but let me know if you want me to explore that more.