[AdminAPI] Use IngressClient for invocation and state mgmt
#3980
Conversation
muhamadazmy
force-pushed
the
pr3980
branch
2 times, most recently
from
6fbd35c to
1b6c108
Compare
muhamadazmy
force-pushed
the
pr3980
branch
7 times, most recently
from
3769517 to
a25372c
Compare
muhamadazmy
force-pushed
the
pr3980
branch
2 times, most recently
from
960bebd to
4a40737
Compare
tillrohrmann
left a comment
tillrohrmann
left a comment
There was a problem hiding this comment.
Thanks for creating this PR @muhamadazmy. The changes look good to me :-)
I left a comment about the removal of the "delete an invocation" API. I think it is ok to remove the API since it was deprecated in v1.4.0 but we need to make sure that it's communicated as part of the release. The Admin API version might have to be bumped if older clients could still call the old invocation deletion API.
| /// Terminate an invocation | ||
| #[openapi( | ||
| summary = "Delete an invocation", | ||
| deprecated = true, |
There was a problem hiding this comment.
This API was deprecated in 1.4.0. If we remove it with 1.6.0, then we certainly need to add a release note to make people aware. Additionally, we need to check
and whether we need to remove support for AdminApiVersion::V2 because we removed the old delete invocation endpoint. We should then also updaterestate/cli/src/clients/admin_client.rs
Line 34 in b9b8f28
There was a problem hiding this comment.
cc @slinkydeveloper for double checking whether we can remove this API.
| warn!("Could not append state patching command to Bifrost: {err}"); | ||
| MetaApiError::Internal( | ||
| "Failed sending state patching command to the cluster.".to_owned(), |
There was a problem hiding this comment.
Is this always true that the patch command could not be appended to Bifrost? What if the ingress is closing after having sent the command out?
| let result = state | ||
| .ingress | ||
| .ingest( | ||
| partition_key, | ||
| IngestRecord::from_parts(envelope.record_keys(), envelope), | ||
| ) | ||
| .await |
There was a problem hiding this comment.
What about rolling upgrades when there are still a few nodes that don't support the PartitionLeaderService yet?
There was a problem hiding this comment.
Ingress client will keep retrying when it gets an error until the record is committed. The only improvement i can think of here is to timeout if the operation takes too long.
muhamadazmy
force-pushed
the
pr3980
branch
7 times, most recently
from
a5593c7 to
2c784b6
Compare
- `ingress-client` implements the runtime layer that receives ingress traffic, fans it out to the correct partition, and tracks completion. It exposes: - `Ingress`, enforces inflight budgets, and resolves partition IDs before sending work downstream. - The session subsystem that batches `IngestRecords`, retries connections, and reports commit status to callers. - `ingress-core` only ingests records and notify the caller once the record is "committed" to bifrost by the PP. This makes it useful to implement kafka ingress and other external ingestion
Summary: Handle the incoming `IngestRequest` messages sent by the `ingress-core`
Summary: Refactor ingress-kafka to leverage on `ingress-client` implementation. This replaces the previous direct write to bifrost which allows: - Batching, which increases throughput - PP becomes the sole writer of its logs (WIP restatedev#3965)
- Use IngressClient instead of bifrost to write to partitions logs - Remove deprecated `delete_invocation`
2 participants
[AdminAPI] Use
IngressClientfor invocation and state mgmtdelete_invocationStack created with Sapling. Best reviewed with ReviewStack.
Shuffler#4024IngressClientfor invocation and state mgmt #3980ingress-client#3975IngestRequestmessage #3974CommitTokenback from notify_committed() #3968ingress-clientcrate #3976