You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(proxy/tap): remove unused trait system (#4477)
`linkerd-proxy-tap` contains data plane facilities that undergird "tap", a
system for inspecting traffic inside of a service mesh.
this crate contains an `iface` submodule that defines a number of
traits intended to provide a set of generic interfaces for uses like
testing, or other transport protocols. however, this suite has not been
used for these purposes. these traits are only used internally. some types
implement these traits, only to provide empty implementations that do nothing.
this means that we pay for the complexity associated with this abstraction,
for no current benefit. this branch removes these traits, to help simplify
the `linkerd-proxy-tap` crate.
* refactor(tap): remove unused `Tap` trait
this commit concerns the `linkerd-proxy-tap::iface::Tap` trait.
this trait was, per the documentation of the `iface` submodule:
> These interfaces are provided to decouple the service implementation from any
> Protobuf or gRPC concerns, hopefully to make this module more testable and
> easier to change.
>
> This module is necessary to seal the traits, which must be public
> for Registry/Layer/grpc, but need not be implemented outside of the `tap`
> module.
traits like this *are* a useful way to permit e.g. tests to mock i/o,
decouple implementations from the particulars of certain protocols, and
so forth.
however, this `Tap` trait is only used within the context of the
`Registry` structure, and is not used for tests.
traits like this have a cost, in the form of complexity in the
implementation. a registry that is generic across a "tap" then leaks
complexity into our middleware, which must include e.g. bounds for the
tap, its request payload, and its response payload.
this commit removes this generic flexibility, and phrases calling code
in terms of this concrete structure. the `can_tap_more()` and `tap()`
methods are now inherent methods, rather than trait methods
implementations. see `linkerd/proxy/tap/src/grpc/server.rs`.
doing this simplifies bounds in `linkerd/proxy/tap/src/service.rs`.
Signed-off-by: katelyn martin <kate@buoyant.io>
* refactor(tap): remove noöp `TapRequestPayload` type
this commit removes `TapRequestPayload`.
we define a `TapPayload` trait, ostensibly to abstract over the task of
"tapping" streams going in and out of workloads. this trait is
implemented by two types, `TapRequestPayload` and `TapResponsePayload`.
note this trait implementation, however:
```rust
impl iface::TapPayload for TapRequestPayload {
fn data<B: Buf>(&mut self, _: &B) {}
fn eos(self, _: Option<&http::HeaderMap>) {}
fn fail<E: HasH2Reason>(self, _: &E) {}
}
```
..and this struct definiction:
```rust
#[derive(Debug)]
pub struct TapRequestPayload {}
```
we do not tap the request payload. we don't store any state in this
type, not is it affiliated with a meaningful trait implementation.
all of `Body<B, T>`'s relevant logic is related to managing its
`TapPayload`s, which as we can see above, are inert. we do not need to
wrap the body in a `Body<B, T>` wrapper if `T` does not apply any
behavior. as in the removal of the `Tap` trait, this is introducing
complexity without any concrete motivating need.
we can remove this trait implementation, and the TapRequestPayload type.
Signed-off-by: katelyn martin <kate@buoyant.io>
* refactor(tap): remove unused `TapResponse` trait
again, we have a trait that is only implemented once, by a single type.
we define an interface here, without any consumers using it. this commit
removes the `TapResponse` trait and replaces calling code with
invocations of inherent methods.
Signed-off-by: katelyn martin <kate@buoyant.io>
* refactor(tap): remove `TapPayload` trait
in a previous commit, we removed the `TapRequestPayload` trait. this
leaves us with a single implementer of this trait. as before, this is
defining an interface with no other consumers.
not only can we remove this trait, but in doing so, we'll discover that
one of these trait methods was never being used!
by removing this unused abstraction, we not only simplify the code
relying on that interface, but the compiler can note that certain parts
of that interface aren't serving us any purpose.
Signed-off-by: katelyn martin <kate@buoyant.io>
* nit(tap): remove inert `Registry` type alias
now that we aren't defining `Registry` as a generic structure, this type
alias is inert. we can instead reëxport it.
Signed-off-by: katelyn martin <kate@buoyant.io>
* refactor(tap): `Inner` is not generic
this type does not need to be defined as a generic.
see <#4477 (comment)>.
Co-Authored-By: Co-authored-by: Alejandro Martinez Ruiz <amr@buoyant.io>
Signed-off-by: katelyn martin <kate@buoyant.io>
* refactor(tap): remove `TapRequestPayload`
see:
- #4477 (comment)
- #4477 (comment)
we removed trait implementations for this type in 337ceda. we can go
further than this, and remove it altogether.
Co-Authored-By: Co-authored-by: Alejandro Martinez Ruiz <amr@buoyant.io>
Signed-off-by: katelyn martin <kate@buoyant.io>
---------
Signed-off-by: katelyn martin <kate@buoyant.io>
Co-authored-by: Co-authored-by: Alejandro Martinez Ruiz <amr@buoyant.io>
0 commit comments