update the proxy to use std::future and Tokio 0.2 #568
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This branch updates the proxy to use tokio 0.2 via the `tokio-compat` runtime. The proxy still uses `futures` 0.1 internally. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch begins a "top-down" update of the proxy to use `std::future`. I've started by commenting out most of the stack, making the proxy into a raw TCP forwarder/HTTP server that just always returns `200 OK <eof>`. Then, I've updated the top-level `serve` function to use `std::future`. This is pretty mechanical, but we _may_ want to consider doing some refactoring here in the future. Currently, most of the integration tests are failing, since they test functionality that is now commented out. I've added `ignore` attributes temporarily to disable those tests. However, since we are ignoring the tests rather than disabling them via conditional compilation, we will still try to build them, so this ensures we don't accidentally break any of these tests. There is a feature flag, "nyi", that can be enabled to run the ignored tests, so that we can test if changes have made any additional tests pass again. As functionality is re-enabled, we can re-enable the corresponding tests as well. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the core proxy components to use `std::future` and `tower` 0.3. This includes most of the `app` crate and its components, the `transport` crate, and some miscellaneous stuff in `proxy` that was necessary for everything else to work. I know this is a huge PR, but unfortunately, the coupling between these crates made it kind of necessary. In theory, the proxy's constituent crates are fairly loosely coupled, and in *most* cases, we don't need to make this kind of cross-cutting change, but using Tower traits as an interface is a big part of *how* we are able to implement this loose coupling. Given the constraint that the `master-tokio-0.2` branch should always compile, I don't think it's possible to do the `std::future` update without a branch like this. Fortunately, although large, the change here is mostly pretty mechanical. There's a lot of udpdating `Service` implementations to the new Tower 0.3 version of the trait, including some slight tweaks to future implementations to work with stack pinning. Some code (such as tap and the controller client) had to be commented out to avoid having to update additional proxy subsystems end-to-end in this branch; we will update those components in follow-up PRs. I haven't updated from tokio 0.1 async io to tokio 0.2 async IO; that will be a later pass. This is because having both `hyper` 0.12 and `tokio` 0.2 with the "net" feature in the dependency graph at the same time pulls in incompatible `iovec` versions and is _very_ hard to untangle. `hyper` and the io types (the `AsyncRead`/`Write` traits, sockets, etc) will have to move together. Once this PR lands and the new Tower version is wired all the way through the core of the proxy, it should be pretty easy to update the rest of the crates in separate, independent PRs. We can essentially go through the stack layer-by-layer, and update each component. Once that's done, then we can circle back and update Hyper and the IO traits to the Tokio 0.2 versions. Closes #474 (it's contained in this branch and can't be merged independently without breaking stuff) Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch ports the `linkerd2-timeout` crate and the `linkerd2-proxy-http` crate's `timeout` module (which depends on it) to use `std::future` and `tokio` 0.2's timers. I've also re-enabled the `push_*` methods for `timeout`, `probe_ready`, `fail_fast`, and `idle`, as well. This change should be pretty straightforward to read, as it's fairly mechanical in nature. I've basically just changed the code to account for the new APIs, but the implementation should be quite similar. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch ports the `linkerd2-stack` crate to use Tower 0.3 and `std::future` and tokio 0.2's timers. I've also re-enabled the `push_*` methods for layers exported by that crate. This change should be pretty straightforward to read, as it's fairly mechanical in nature. I've basically just changed the code to account for the new APIs, but the implementation should be quite similar. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Tower is currently being reorganized (all the sub-crates are being merged into feature-flagged modules of the main `tower` crate). This hasn't been released yet, but it has landed on git master. In addition, we need to pick up an upstream fix for a regression in the future returned by `ServiceExt::oneshot` (tower-rs/tower#447), which is currently unreleased; without this fix, a lot of stuff is broken and it's difficult to test changes in other linkerd crates. This branch updates everything that currently depends on `tower` 0.3 to use the same dependency, and enables the features that each crate currently uses in that crate's dependency. I've added a single patch to use the git version in the main workspace `Cargo.toml`; when the changes we need are published, the patch can be removed. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch ports the `linkerd2-buffer` to use `std::future` and `tokio` 0.2. I've also re-enabled the `push_spawn_buffer` fns in `svc`. Like #486 and #487, this change should be pretty straightforward to read, as it's fairly mechanical in nature. I've basically just changed the code to account for the new APIs. This one might be a _little_ more interesting, since it shows off some of the API differences in `tokio::sync` in 0.2 as well. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch re-enables a few `push_*` functions in `core/svc` that were either reimplemented and not un-commented, or that just required a tower version bump. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `concurrency-limit` middleware to std::future. The new implementation uses the new owned semaphore permit API added in Tokio 0.2.19 (tokio-rs/tokio#2421). Similarly to #490, the old implementation could not be directly translated due to `tokio::sync`'s `Semaphore` losing its `poll`-based API in 0.2. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This is a purely mechanical update that makes the API changes I'm sure you've all gotten pretty used to by now. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This does **not** update the payload module to `std::future`, since we are still on the futures 0.1 version of Hyper. It only updates the `tower-service` impls. This will be necessary to bring back the HTTP clients. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This will be the first step in the process of picking up the new Hyper. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `linkerd2-cache` crate (and `linkerd2-lock`, which it relies on), to use `std::future`. Unlike previous PRs, the `linkerd2-lock` update is a more substantial rewrite, because upstream API changes made the previous implementation no longer possible. In particular, `tokio::sync::Mutex` does not provide a `poll_acquire` method the way that `tokio_sync::Lock` did in Tokio 0.1. The removal of `poll_acquire` is largely due to the rewrite of Tokio's synchronization primitives to use an intrusive linked list-based semaphore (tokio-rs/tokio#2325), which requires waiters to be pinned to ensure safety of the intrusive list. Allowing permits to be acquired only from a future ensures correct pinning of waiters. Therefore, I've implemented a new `Lock` for Linkerd which uses a Tokio `Mutex` internally. The `Lock` owns a boxed instance of the future returned by `Mutex::lock_owned`, and drives it in `poll_acquire`. This allows adapting the poll-based Tower interface with the futures-only, pinned interface.
This branch updates `master-tokio-0.2` from the latest `master`. A lot of this diff is totally unrelated and is largely ignoreable (e.g. changes to the docker build configuration, etc). However, there was also a decently large chunk of code that had changed in both `master-tokio-0.2` and on master. The majority of the merge conflicts were related to the changes to `Accept` in #464, because `Accept` had also been updated to use `std::future` on `master-tokio-0.2`. A review should probably focus on the `Accept` codepaths. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This fixes a bug where the std::future version of `linkerd-concurrency-limit` fails to drive the wrapped service to readiness before calling it. Now, the inner service is polled once a semaphore permit has been acquired. Shoutout to @LucioFranco for noticing this! Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Applies the changes in #502 to the tokio-0.2 branch.
This branch updates the Hyper dependency to 0.13 (and thus also updates `http`/`http-body`), and updates all uses of `AsyncRead` and `AsyncWrite` and `tokio::net` types to use the Tokio 0.2 versions.This also implies updating `bytes` from 0.4 to 0.5. Unfortunately, this change is rather massive, but all these dependencies are pretty tightly coupled. It wasn't really possible to upgrade them incrementally the way it was for code in Linkerd, at least not without forking and patching the dependencies, which I wanted to avoid. ## Note on Test Support This branch also makes a great deal of changes to the test support code in `linkerd2-app-integration`. This is necessary because this code no longer compiled after updating Hyper and the IO traits. When practical, I've tried to make this a direct translation of the existing code. I think there's a lot of opportunity to improve this code and reduce complexity. In particular, the test-support clients work by spawning a background thread with a Tokio runtime on it, and sending work to that task and responses back over channels. This is so we can present a synchronous API to the tests themselves, and write straight-line code in tests rather than nested futures. In an async/await world, that's kind of unnecessary. We could switch the integration tests to be async functions written using `#[tokio::test]`, and remove the complexity of managing multiple background threads and runtimes for each test client (and server). We would probably still want to isolate the test _proxy_ in its own runtime as we do currently, but we could run all the test support code in the main test thread's runtime and not have to do all this messing around with threads and channels. However, I didn't do this kind of refactoring in this PR, beyond adding async _versions_ of some of the existing test support APIs (which still use channels internally). These were added for use in tests which have to call into async APIs from other crates and therefore need to be `async fn`s. I wanted to avoid totally rewriting the test support code in this branch, however, since it's already a huge change. ## Note on IO Trait Changes The `BoxedIo` trait used to have a special `shutdown_write` method that would call `std::net::TcpStream::shutdown(Shutdown::Write)`. This was added because Tokio 0.1's `<TcpStream as AsyncWrite>::shutdown` did _not_ call this method; it simply returned `Ok(())`. However, Tokio 0.2's `<TcpStream as AsyncWrite>::poll_shutdown` *does* call `std::net`'s `TcpStream::shutdown`. Since `BoxedIo` was ported directly from the 0.1 code and still called both `AsyncWrite::poll_shutdown` _and_ `Io::shutdown_write`, we would try to shut down the stream twice, and the second call would fail with a "transport endpoint is not connected" error. This broke the `tls_accept` tests, which expected there to be no error. This commit removes the `Io::shutdown_write` method, since Tokio's `TcpStream` now does what we want. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
I had forgotten that `linkerd2-stack-metrics` is actually kind of load bearing: the `TrackServiceLayer` is necessary for powering cache eviction as well as being used for debugging. It turns out that we need this to create stacks that work. This branch ports `linkerd2-stack-metrics` to std::future. This change was pretty trivial; I just updated to use the new `tower::Service` trait. I also pruned a bunch of dependencies that this crate wasn't actually using from the Cargo.toml. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This change modifies HTTP error-labeling to detect I/O errors and label them explicitly. Previously all I/O errors were reported as `unexpected`. Additionally, an `errno` label is included when possible. Fixes linkerd/linkerd2#4364
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
It turns out that most of the tests that can be re-enabled as a result of #516 expect URIs to be normalized. Therefore, I ported the `normalize_uri` layer to std::future. This is a pretty mechanical translation. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Now that the HTTP connect- and accept-side machinery has all been updated to use `std::future`, we can start turning the proxy back into...a proxy. This branch does so on the inbound side. Much of the actual functionality (approximately everything not directly required to actually proxy requests) is still disabled, as a lot of the code still needs to be updated. I had to make a few additional changes in order to get the proxy to compile, primarily to deal with trait bounds on `Service` impls that were no longer satisfied as a result of changes made to update other parts of the codebase. I also disabled two more of the `transparency` integration tests, both of which tested whether the proxy stripped connection-level headers from proxied requests. Previously, these were passing "accidentally" — because the proxy was replaced with a HTTP server that just responded to every request with an empty 200 OK response, the headers were, of course, not present. Now that we're actually proxying requests, these tests fail, because the code for stripping headers has yet to be updated. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
…std::future (#518) This branch updates the `linkerd2-proxy-resolve` crate to `std::future`. It also updates the `recover` module in `linkerd2-proxy-error`, which is a dependency of `resolve`, and `linkerd2-reconnect`, which depends on `recover` and therefore didn't compile after it was updated. The `linkerd2-proxy-resolve::recover` code currently only works when the underlying resolver's resolution and future types are both `Unpin`, and the backoff type is also `Unpin`. This is because this logic relies a bit on being able to move these values in and out of `Option`s. I tried to implement this without requiring these values to be `Unpin`, but the implementation of the `ResolveFuture`, which drives the resolution until it's connected and then returns it, was more or less impossible to translate in its current state. I suspect that this won't be an issue when updating code that depends on `recover` — I think the resolutions will probably be `Unpin` without any intervention from us. If not, we can always either `Box::pin` them, or try to do a more complete rewrite of this code so that it's refactored in a way that avoids these issues. In other cases, we can sometimes just replace code that is difficult to port to use `async`/`await`. Here, that was not possible, because we are implementing the `Resolution` trait, rather than a future. We _may_ want to consider rewriting `Resolution` to be a trait alias for a `Stream`, so that we can use the `async-stream` crate, but that may have other downsides, so I decided to not do that just yet. Hopefully this all makes sense! Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `linkerd2-proxy-dns` crate to `std::future` and the latest release of `trust-dns-resolver`, and updates the uses of DNS in `linkerd2-proxy-app` to track the changes. For the most part, this change is pretty straightforward. However, the `std::future` version of `trust-dns-resolver` changed how the background task driving DNS resolution is executed. Previously, it was returned by the `AsyncResolver` constructor, but now, the constructors are `async fn`s that implicitly spawn the background task on the runtime that executes them. Therefore, I had to change how the DNS resolver is constructed. I opted to build the admin runtime early and have it block on the DNS resolver construction, and then pass that runtime to the admin thread when it is spawned. This seemed better than making the DNS resolver lazy by making the underlying `trust-dns` async resolver an `Option` or something, and having it panic when the resolver hasn't been constructed yet. Doing that safely would have required adding a `RwLock` or something, which didn't seem ideal. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This is pretty straightforward, but it was necessary to bring back the destination service client. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `linkerd2-proxy-api-resolve` crate to use `std::future` and Tonic. Getting this to work required some upstream changes to linkerd/linkerd2-proxy-api#39 to pass different feature flags to Tonic, but the change here is pretty straigntforward. Depends on #518 and will be rebased onto `master-tokio-02` when that branch merges. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the proxy's control-plane client to use `std::future` and Tonic. This should unblock updating the outbound proxy (as it needs service discovery) and bringing back service profiles. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `balance` module in `linkerd2-proxy-http` to use Tower 0.3 rather than 0.1. This change is pretty trivial — it's just updating the dependencies in Cargo.toml and changing imports around to track code that moved around upstream. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `linkerd2-proxy-discover` crate to use `std::future` and Tower 0.3. Overall, this is a fairly mechanical change. The main upstream API difference is that `tower-discover` is now a trait alias for `Stream`, rather than a trait that user code can directly implement. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch turns the outbound side of the proxy back into a real proxy, similarly to what #516 did for the inbound side. Getting outbound to work again was somewhat more complex, since the outbound side also requires the load balancer (and, therefore, discovery). In order to get this all working, it was also necessary to update the `linkerd2-request-filter` crate (which was quite trivial), as it's necessary for the resolver to work, and to make some changes in the resolver so that all trait bounds were satisfied. In addition, now that both inbound and outbound work, we're now able to re-enable a large amount of the integration tests in the `transparency` and `discovery` modules. Some of these tests are still disabled, as they either depend on service profiles, HTTP upgrades and orig-proto, or header maniuplation, all of which have yet to be updated. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the identity service client to use `std::future` and async/await. Since the identity refresh daemon code ended up being somewhat tricky to make work with stack pinning, I opted to just replace it with a new async/await implementation instead. I've also re-enabled all the identity integration tests. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Previously, in the `futures` 0.1 version of the proxy, we provided `hyper` with a custom executor to propagate `tracing` spans to tasks spawned by `hyper`. In the process of updating the proxy to `std::future`, this was removed, meaning that any tasks spawned by hyper are missing their spans. This makes events recorded by `h2` and so on hard to debug, especially when many connections are open. This branch fixes this by adding an implementation of `hyper::Executor` that propagates the current span when spawning a task. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
**Note**: this branch was already approved (as #543), but was accidentally merged into the dev branch for #541, which it depended on and was set as the base until that branch merged. It looks like, when merging #543, I forgot to change the base branch back to `master-tokio-0.2`, and these changes never made it to master. --- This branch updates the proxy's OpenCensus tracing code and collector client to use Tonic and `std::future`, and puts the OpenCensus stack layers back in the inbound and outbound proxy. Of note: the previous implementation constructed a single client `Service` which was reused when restarting a new RPC if the stream terminated. Because Tonic's generated RPCs borrow the client service mutably for the duration of the RPC future, if we want these futures to be `'static`, we must move the service into the future. Rather than requiring the service to be `Clone`, I solved this by replacing the `Service` instance held by the client with a `NewService` instance. I don't *think* this should be an issue, let me know if I'm wrong? I'd like to do some additional testing with the OpenCensus integration tests but I'm opening this PR now to start getting reviews. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the `require_identity_on_endpoint` module in `linkerd2-app-outbound` to `std::future`. The tests for this functionality (`require_id_header::http2::disco_client_connects_to_tls_server` and `require_id_header::http1::disco_client_connects_to_tls_server`) now pass; however, they had already been re-enabled (they are tagged as flaky). Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the proxy tap machinery to use `std::future` and Tonic. Depends on #548 Signed-off-by: Eliza Weisman <eliza@buoyant.io>
When `linkerd2-buffer` was updated to `std::future` in PR #505, the behaviour of the buffer was changed subtly. The previous implementation of the buffer's `Dispatch` task was _poll-based_; it implemented its logic in an implementation of `Future::poll` with the following behavior: 1. Call `poll_ready` on the underlying service, returning `NotReady` if it is not ready. 2. Broadcast readiness to senders. 3. Call `poll_next` on the channel of requests. If a request is received, dispatch it to the service. If no request is ready, return `NotReady` (yield). Since this was an implementation of the `poll` function, if we yield due to the request channel being empty, when we are woken again by the next request, we resume _at the beginning of the `poll` function_. The new implementation, however, was written using async/await syntax. Async/await generates a state machine which, when woken after yielding at an await point, resumes _from the same await point it yielded at_. This means that if the new implementation yields because the request channel is empty, when it is woken by a request, it will **not** drive the service to readiness before sending that request. Instead, the previously acquired readiness from before the task yielded is consumed by that request. This behavior is totally fine with regards to the `tower-service` readiness contract. All the contract requires is that a call to `poll_ready` must return `Ready` before each call to `call`. It doesn't matter if there was a long period of time in between `poll_ready` and `call`, as long as the readiness was not consumed by another `call`. However, it is **not** fine from the perspective of the load balancer. The load balancer relies on `poll_ready` to drive updates from service discovery. This means that if a long period of time passes between when the balancer becomes ready and when it is called, it may have a stale service discovery state. Therefore, this change in behavior broke a large number of the proxy's integration tests that expect changes to service discovery state to be reflected in a timely manner. This commit fixes this issue by updating the new `dispatch::run` implementation to drive the service to readiness immediately before dispatching a request. Once the service is driven to readiness initially, we advertise that it is ready, and call `try_recv` on the request channel. If there is a request already in the channel, we can consume the existing readiness. Otherwise, if there is not a request immediately available, and we have to wait on the channel, we will drive the service to readiness again before calling it. This ensures that service discovery changes are reflected for the next request after they occur, rather than for the request _after_ that request. Signed-off-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: Oliver Gould <ver@buoyant.io>
* outbound: Prevent loops (#525) This change modifies the outbound proxy to fail to build services targetting localhost:4140 (where 4140 is the outbound port). This prevents looping and will result in 502s. * Add loop detection to inbound & TCP forwarding (#527) e77fe18 introduced loop detection to the outbound HTTP proxy. This change extends this behavior to the inbound HTTP proxy and the TCP proxy for both inbound and outbound. This helps ensure malicious requests can't consume proxy resources. * Test loop detection (#532) This change adds (flakey) tests for loop detection. The tests are flakey because they require static ports to work properly. (We cannot configure the original dst port to be the same as the interface port if the interface port is not known). * fallback: Unwrap errors recursively (#534) This change modifies the fallback layer to inspect error sources recursively to determine if the given error type is satisfied. A stack-helper is also added for this case. * app: Split inbound/outbound constructors into components (#533) This change does not change any functionality. It only restructures the inbound and outbound proxy modules so that the clients and servers can be instantiated separately. This will support gatewaying requests between the inbound and outbound proxy. * Introduce a gateway between inbound and outbound (#540) When the proxy receives inbound requests without an original dst address (or with a original dst address matching the inbound listener), the proxy currently fails these requests. This change modifies the proxy to attempt to accept these requests and forward them back through the outbound router. The gateway requires that all requests are received over an mTLS-secured connection. It also refines the destination through DNS to determine the canonical-form name as well as an outbound original dst IP. All gatewayed destinations must have a suffix as set by the `LINKERD2_PROXY_INBOUND_GATEWAY_SUFFIXES` environment variable. All requests that do not meet these criteria are failed with a `403 Forbidden` status. * gateway: Add a Forwarded header When the gateway forwards requests, it now adds a `Forwarded` header including the source identity, the local identity, and the destination authority. * Fail requests that loop through the gateway This change uses the gateway's `Forwarded` header to detect if the request has already transited through this gateway. This is determination is made by comparing ID strings, so this will prevent gateway daisy-chaining when clusters do not use distinct identity domains. * gateway: Return errors instead of responses (#547) This ensures that error metrics are recorded and that logging is emitted uniformly. This also ensures that gRPC requests don't get HTTP error responses. * Fail requests that loop through the gateway (#545) This change uses the gateway's `Forwarded` header to detect if the request has already transited through this gateway. This is determination is made by comparing ID strings, so this will prevent gateway daisy-chaining when clusters do not use distinct identity domains. * inbound: Do not cache gateway services (#549) When the inbound caches gateway services, it eagerly obtains an outbound service to cache. If the outbound service employs a traffic split, this inbound service is pinned to a specific leaf, and requests will never be routed to the other leaf. This change moves the gateway fallback to be outside all of the inbound caches, so that outbound splits work as intended.
Looks like the `linkerd2-error-metrics` crate was never updated to `std::future`. This branch takes care of that and adds back the HTTP error metrics layers. This should be a pretty trivial review. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Although the `Drain` type which powers the proxy's graceful shutdown machinery was updated in #482, we were not actually triggering graceful shutdowns. This is because the Hyper `ConnectionFuture` was wrapped in a compatibility adapter which did not allow access to the inner future so that we could call the `graceful_shutdown` method on it. When we updated to the `std::future` version of Hyper, the graceful shutdown code was not re-enabled. This branch puts back the call to `ConnectionFuture::graceful_shutdown`. It also re-enables the shutdown integration tests, which pass now. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Upstream changes to `trust-dns-resolver` removed the background task to drive DNS resolutions. Now, the resolution is performed as part of the lookup future. This means that resolutions are now occurring "inline" when we call into a resolver, rather than on the background thread. This caused issues with failed resolutions preventing the proxy from shutting down. This should hopefully fix that. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch re-enables all the proxy integration tests that hadn't already been turned back on. It turns out that almost everything just works! Depends on #560 Signed-off-by: Eliza Weisman <eliza@buoyant.io> * remove ENOTCONNs from HTTP transport metrics tests The way Hyepr handles disconnections has changed, so we no logner see this errno. This is actually more consistent with the way clean disconnections are handled for raw TCP traffic, anyway! Signed-off-by: Eliza Weisman <eliza@buoyant.io> * put back upgrade service that i apparently forgot Signed-off-by: Eliza Weisman <eliza@buoyant.io> * cargo.lock * fix zero length `read`s in transparency tests whoops --- `Vec::clear` sets the length to 0, so no bytes are read into the buffer. fixed this by just allocating a new vec like the tests used to do, it's fine, they're just tests. Signed-off-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: Oliver Gould <ver@buoyant.io>
The probe-ready middleware is unused and its test is flakey. Let's remove it.
This change drops unneeded dependencies on tokio-compat and futures-0.1. It adopts the new basic scheduler. It does not port integration test infrastructure.
This PR removes a few remaining compiler warnings from master-tokio-0.2 and re-adds deny attributes for warnings. Also, I've updated all crates to consistently use tracing-futures v0.2 (previously, some crates were on 0.2 while others were still on 0.1).
* make: Support CARGO_TARGET for multi-arch builds (#497) This change adds support for a `CARGO_TARGET` environment variable. When set, this value is passed to i.e. `cargo build --target` to support cross-compilation for multi-architecture builds. Signed-off-by: jaerik <erik.jansson@axis.com> Co-authored-by: Erik Jansson <erikja@axis.com> * Add a CODEOWNERS (#558) This CODEOWNERS change will ensure that proxy-maintainers are requested on all PRs. Co-authored-by: Erik Jansson <45871810+jaerik@users.noreply.github.com> Co-authored-by: Erik Jansson <erikja@axis.com>
hawkw
changed the title
olix0r
approved these changes
Jun 16, 2020
olix0r
added a commit
to linkerd/linkerd2
that referenced
this pull request
Jun 23, 2020
This release primarily features an upgrade of the proxy's underlying Tokio runtime and its related libraries. We've observed lower latencies in initial benchmarks, but further testing and burn-in is warranted. Also, the proxy now honors the `LINKERD_PROXY_LOG_FORMAT=json` configuration to enable JSON-formatted logging. --- * Add a CODEOWNERS (linkerd/linkerd2-proxy#558) * Fix shellcheck issues in shell scripts (linkerd/linkerd2-proxy#554) * update the proxy to use std::future and Tokio 0.2 (linkerd/linkerd2-proxy#568) * Prune unused dependencies (linkerd/linkerd2-proxy#569) * Support LINKERD_PROXY_LOG_FORMAT=json (linkerd/linkerd2-proxy#500) * Change docs references from "master" to "main" (linkerd/linkerd2-proxy#571) * Upgrade tokio-rustls & webpki. (linkerd/linkerd2-proxy#570) * Makefile: Add shellcheck recipe (linkerd/linkerd2-proxy#555) * Update proxy-api dependencies (linkerd/linkerd2-proxy#573) * integration: fix missing traces (linkerd/linkerd2-proxy#572) * Update Rust to 1.44.0 (linkerd/linkerd2-proxy#574) * Use async/await to simplify connection-accept task (linkerd/linkerd2-proxy#575) * Update Rust to 1.44.1 (linkerd/linkerd2-proxy#576) * outbound: Split HTTP endpoint builder (linkerd/linkerd2-proxy#578) * Simplify protocol detection with async/await (linkerd/linkerd2-proxy#577) * Pin proxy-api at v0.1.13 (linkerd/linkerd2-proxy#579)
olix0r
added a commit
to linkerd/linkerd2
that referenced
this pull request
Jun 24, 2020
This release primarily features an upgrade of the proxy's underlying Tokio runtime and its related libraries. We've observed lower latencies in initial benchmarks, but further testing and burn-in is warranted. Also, the proxy now honors the `LINKERD_PROXY_LOG_FORMAT=json` configuration to enable JSON-formatted logging. --- * Add a CODEOWNERS (linkerd/linkerd2-proxy#558) * Fix shellcheck issues in shell scripts (linkerd/linkerd2-proxy#554) * update the proxy to use std::future and Tokio 0.2 (linkerd/linkerd2-proxy#568) * Prune unused dependencies (linkerd/linkerd2-proxy#569) * Support LINKERD_PROXY_LOG_FORMAT=json (linkerd/linkerd2-proxy#500) * Change docs references from "master" to "main" (linkerd/linkerd2-proxy#571) * Upgrade tokio-rustls & webpki. (linkerd/linkerd2-proxy#570) * Makefile: Add shellcheck recipe (linkerd/linkerd2-proxy#555) * Update proxy-api dependencies (linkerd/linkerd2-proxy#573) * integration: fix missing traces (linkerd/linkerd2-proxy#572) * Update Rust to 1.44.0 (linkerd/linkerd2-proxy#574) * Use async/await to simplify connection-accept task (linkerd/linkerd2-proxy#575) * Update Rust to 1.44.1 (linkerd/linkerd2-proxy#576) * outbound: Split HTTP endpoint builder (linkerd/linkerd2-proxy#578) * Simplify protocol detection with async/await (linkerd/linkerd2-proxy#577) * Pin proxy-api at v0.1.13 (linkerd/linkerd2-proxy#579)
olix0r
added a commit
that referenced
this pull request
Jun 10, 2021
The tap tests were disabled in #568. This change restores these tests, updating them to use quickcheck v1.
olix0r
added a commit
that referenced
this pull request
Jun 10, 2021
The tap tests were disabled in #568. This change restores these tests, updating them to use quickcheck v1.
olix0r
added a commit
that referenced
this pull request
Jun 10, 2021
The tap tests were disabled in #568. This change restores these tests, updating them to use quickcheck v1.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch updates the proxy codebase from
futures0.1 and Tokio 0.1to
std::future, Tokio 0.2, and the associated ecosystem. Wherever Icould, I've tried to keep this translation as mechanical as possible. In
a few places, some significant structural changes and refactoring was
necessary, largely due to stack pinning requirements, but there should
be no behavioral changes. The new ecosystem does present opportunities
for more significant refactoring, but we should probably do that in
follow-up changes instead.
All of this code has already been reviewed in a series of incremental
PRs to the
master-tokio-0.2branch. This branch's history can be readfor details on the update process. In addition, all the proxy's
integration tests have been updated and now pass against this branch,
and performance testing indicates that there have been no significant
changes.
Signed-off-by: Eliza Weisman eliza@buoyant.io