-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dispatch Managing Actor #54
Conversation
Marenz
commented
Sep 11, 2024
- Reset release notes
- Add dispatch runner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few really minor comments to check for, LGTM otherwise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say all comments are mostly bike shedding, but in particular I think not using configuration and use dispatch update is important, I think it can get a bit confusing for people dealing with dispatches and configuration (as in config manager) too. I really think we should replace all `configuration mentions to update/dispatch update.
Also I found the example a bit confusing, which ideally it shouldn't be the case, the example should help make things less confusing :P
match running: | ||
case RunningState.STOPPED: | ||
_logger.info("Stopping dispatch...") | ||
await self._stop_actors("Dispatch stopped") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "Stopped by a dispatch".
I don't like |
Why don't you like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see there was not much progress or replies on my comments. I guess you are focusing on getting shit to work, which sounds totally reasonable, but just saying that I didn't review much in this round.
1509e1b
to
ba6bd9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice to see the new scheduling algorithm! 🎉 Way better than what we had before.
Lots of comments, so here is a summary:
Things I think needs to be addressed before merging:
-
These commits need a commit message with a body that describes what's going on, it is really hard to review them without more information of what was wrong and how it was fixed:
Fix wrong running behaviors with duration=None
Rewrite internal architecture to be more flexible
Add dispatch runner
(less important but it would be nice, is not a trivial class)
-
Finish the renaming of
config
->update
-
The hack in the tests (session-wide
event_loop
fixture), we can't really merge this if something is so fucked up that makes tests hang or make the interpreter segfault 😬 -
Figure out if we really need to support multiple actors, it is still make noise in my head, my feeling is we should encourage having one actor to handle one dispatch type, if that actor needs other supporting actors, it should be the actor itself in charge of spawning them.
-
If we are doing more renaming (like
DispatchManagingActor
andpayload
->options
), it might be good to do them now too to avoid having breaking changes in the future.
The rest is minor or too big for this PR, so I will create follow-up issues.
dry_run: bool | ||
"""Whether this is a dry run.""" | ||
|
||
payload: dict[str, Any] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bikeshedding: Payload sounds weird to me. For a whole dispatch it makes sense (or at least it was the best we could find) but in this context maybe something like options
is more intuitive? To be honest I think options
might be a good choice for the specs too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about inputs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that could work too, I think we discussed options
at some point but wasn't perfectly accurate as some "options" might not be optional. I guess inputs
is an improvement in that sense. Maybe parameters
could work too.
And I still think "update" sucks and "configuration" was better. "Update" doesn't fit at all in the whole naming scheme |
Addressed points 1 - 5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more instances of config and we need support for multiple actors for now (temporarily). I will also create issues for the stuff we can address in the future.
dry_run: bool | ||
"""Whether this is a dry run.""" | ||
|
||
payload: dict[str, Any] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that could work too, I think we discussed options
at some point but wasn't perfectly accurate as some "options" might not be optional. I guess inputs
is an improvement in that sense. Maybe parameters
could work too.
|
bc76d7e
to
7003801
Compare
@@ -165,6 +165,7 @@ disable = [ | |||
[tool.pytest.ini_options] | |||
testpaths = ["tests", "src"] | |||
asyncio_mode = "auto" | |||
asyncio_default_fixture_loop_scope = "function" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this seems to be related to an update to https://github.com/pytest-dev/pytest-asyncio/releases/tag/v0.24.0. Issue: pytest-dev/pytest-asyncio#924
Signed-off-by: Mathias L. Baumann <[email protected]>
* Dispatch.running() was always returning RUNNING for duration None * Dispatch.next_run_after() was made aware that there is no next run for inf. Duration * Dispatch._until() now raises when used with Dispatch.None * Actor: delay marking a Dispatch as deleted, otherwise checks wrongly detect it as no longer running. Signed-off-by: Mathias L. Baumann <[email protected]>
The internal scheduling architecture was rewritten: Instead of using one task per dispatch that will start/stop them, we now have a queue of events and a timer that is rescheduled to the earliest next event each time it triggers. Previously we had to do complicated re-scheduling and cancelling of tasks, now we always just update the event in the queue. Signed-off-by: Mathias L. Baumann <[email protected]>
A useful actor to help control and manange another actor using dispatches. Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
As recommended by the deprecation warning Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
Signed-off-by: Mathias L. Baumann <[email protected]>
The merge-base changed after approval.
It looks like now cross-arch tests are consistently failing. This must be definitely a timing issue, the slowest the system is, the more likely we hit this bug and tests hang. Created an issue about it: |