Skip to content
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

Operation dispatcher FSM #77

Merged
merged 16 commits into from
Sep 10, 2024
Merged

Operation dispatcher FSM #77

merged 16 commits into from
Sep 10, 2024

Conversation

didierofrivia
Copy link
Contributor

@didierofrivia didierofrivia commented Aug 27, 2024

Part of the work needed for #58

This PR introduces the OperationDispatcher FSM, that it's responsible of not only keeping track of the current state of the operations, but also triggering the actual actions defined by configuration.
It also includes a refactor that was needed in order to wire the Filter, Services, ServiceHandlers and Operations together.

The implementation:

  • OperationDispatcher:
    • its responsible of building the operations and exposing the next function in charge of triggering the current
      Operation procedure
    • The next fn will return the current Operation when called.
  • Operation:
    • Exposes its State, Result and Extension
    • will trigger the request for the Auth/RateLimit GRPC service
    • It will also track and mutate the State (Pending -> Waiting -> Done)
    • Responsible of providing the hostcalls fns

Regarding the refactoring of the other pieces:

  • A new type GrpcMessage was created, implementing the trait Message in order to abstract its logic
  • GrpcService now keeps a Rc of Extension
  • GrpcServiceHandler.send method takes as args get_map_values_bytes and grpc_call following DI pattern in order to unit test the operations.
  • Configuration Actions have been added.

Notes

  • The wiring only replicates the previous behaviour, still needs to implement the actual flow with multiple actions
  • The Rules from the PluginConfiguration follows still the old state, duplicating DataType that resides within the Actions
  • Missing tests for the service module
  • FOR THE REVIEWERs OF THIS PR: Don't go per commit, just go for the Files Changed unless you want to go through a convoluted collection of changes.

@didierofrivia didierofrivia force-pushed the action_dispatcher branch 2 times, most recently from d1d196b to a66a992 Compare August 29, 2024 13:46
@didierofrivia didierofrivia changed the base branch from main to external-auth August 29, 2024 13:46
@didierofrivia didierofrivia force-pushed the action_dispatcher branch 10 times, most recently from ca3cdff to 876b38f Compare September 4, 2024 13:14
@didierofrivia didierofrivia changed the title [wip, feat] Action dispatcher state machine Action dispatcher FSM Sep 4, 2024
@didierofrivia didierofrivia self-assigned this Sep 4, 2024
@didierofrivia didierofrivia force-pushed the action_dispatcher branch 2 times, most recently from 88c2caf to 2b288a1 Compare September 4, 2024 18:17
@didierofrivia didierofrivia changed the title Action dispatcher FSM Operation dispatcher FSM Sep 4, 2024
@didierofrivia didierofrivia marked this pull request as ready for review September 4, 2024 18:35
@didierofrivia didierofrivia added the enhancement New feature or request label Sep 4, 2024
Copy link
Member

@alexsnaps alexsnaps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some notes, but I think this is good starting point... Let's iterate!

src/service.rs Outdated Show resolved Hide resolved
src/service.rs Outdated Show resolved Hide resolved
src/operation_dispatcher.rs Outdated Show resolved Hide resolved
{
#[allow(non_upper_case_globals)]
static instance: ::protobuf::rt::LazyV2<GrpcMessage> = ::protobuf::rt::LazyV2::INIT;
instance.get(|| GrpcMessage::RateLimit(RateLimitRequest::new()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The requirement for this confuses me... couldn't this "just" be a factory function and be passed around as a fn pointer instead? Not a big deal tho

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was to please the compiler, got the implementation from the message lib xD

self.operations.borrow().first().unwrap().get_result()
}

pub fn next(&self) -> Option<Operation> {
Copy link
Member

@alexsnaps alexsnaps Sep 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this signature will need to be somewhat rethought... Probably something along the lines of a

  • .start() that starts a "sequence", initial state (that would only be started in on_request_headers phase)
  • .next(...) with some params (gRPC response's token_id & response_size?) to go from one operation to the next (that would only ever be progressed in on_grpc_response phase, Pausewith the request)
  • () i.e. "void"/unit, i.e. nothing left to do, representing the terminated state (transitioned to in the on_grpc_response phase, possibly leaving more work for some other phase to handle, Continue with the request)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, after discussing about how would it be consumed on_grpc_response and the requirements to digest the actual response needing the response_size makes sense. Will shoot a following PR addressing this. Thanks!

Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
* Could get confusing with proxy_wasm `Actions`
* Also with plugin configuration `Action`

Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
* GrpcMessage type created

Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
* Easier to test, mocking fn
* Assigned fn on creation, default hostcall and mock on tests

Signed-off-by: dd di cesare <didi@posteo.net>
* Bonus: Addressed review regarding testing and Fn types

Signed-off-by: dd di cesare <didi@posteo.net>
@eguzki
Copy link
Contributor

eguzki commented Sep 6, 2024

I want to understand and follow. Shouldn't the distpatcher be called on the on_grpc_call_response method of the Context trait?

@didierofrivia
Copy link
Contributor Author

@eguzki you're correct, it should be call on on_grpc_call_response too, this PR is implementing the FSM but not changing the current behaviour. Next PR will address that since the API needs to change a bit, around this #77 (comment)

@eguzki
Copy link
Contributor

eguzki commented Sep 9, 2024

ok, let's go then. Forget about the clippy thing for now.

Copy link
Contributor

@eguzki eguzki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's iterate! 🔨

@didierofrivia didierofrivia merged commit 17cc2f0 into external-auth Sep 10, 2024
7 of 8 checks passed
@didierofrivia didierofrivia deleted the action_dispatcher branch September 10, 2024 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants