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

Require Rust 1.23 in proxy Dockerfile-deps #105

Merged
merged 1 commit into from
Jan 5, 2018
Merged

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Jan 4, 2018

After merging #104, Conduit will not build against pre-1.23 Rust versions. This PR updates the Dockerfile to require this version.

Signed-off-by: Eliza Weisman eliza@buoyant.io

@briansmith
Copy link
Contributor

Please merge this into your other PR so that both changes happen in the same merge. You can do this by changing the base branch of this PR from "master" to the branch for your other PR. Then when you merge this PR, it will get merged into the other PR, and then you can merge the combined thing at once into master.

More generally, it's good to break things into multiple PRs but we should never have a merge to master that breaks the build even temporarily.

@hawkw
Copy link
Member Author

hawkw commented Jan 4, 2018

@briansmith, I was originally going to make this change in PR #104, but @olix0r requested that the Dockerfile change be made separately. In the future, I think we should codify this in documentation somewhere.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@hawkw hawkw merged commit 2bd9f99 into master Jan 5, 2018
@hawkw hawkw removed the reviewable label Jan 5, 2018
@olix0r olix0r deleted the eliza/update-rust branch April 20, 2018 01:03
khappucino pushed a commit to Nordstrom/linkerd2 that referenced this pull request Mar 5, 2019
The control client implements a backoff service that dampens reconnect
attempts to the control plane by waiting a fixed period of time after a
failure.

Furthermore, the control client logs errors each time a reconnect
attempt fails.

This change moves backoff logic from
control::destination::background::client to proxy::reconnect.

Because the reconnect module handles connection errors uniformly, muting
repeated errors, it also has enough context to know when a backoff
should be applied -- when the underlying NewService cannot produce a
Service.

If polling the inner service fails once the Service has been
established, we do not want to apply a backoff, since this may
just be the result of a connection being terminated, a process being
restarted, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants