Attempt to load TLS settings immediately prior to starting watch (#1137)

Previously, the proxy would not attempt to load its TLS certificates until a fs
watch detected that one of them had changed. This means that if the proxy was
started with valid files already at the configured paths, it would not load 
them until one of the files changed.

This branch fixes that issue by starting the stream of changes with one event
_followed_ by any additional changes detected by watching the filesystem.

I've manually tested that this fixes the issue, both on Linux and on macOS, and
can confirm that this fixes the issue. In addition, when I start writing 
integration tests for certificate reloading, I'll make sure to include a test
to detect any regressions.

Closes #1133.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This commit is contained in:
Eliza Weisman 2018-06-15 17:32:55 -07:00 committed by GitHub
parent 2322dc955a
commit 45622744e8
1 changed files with 5 additions and 2 deletions

View File

@ -14,7 +14,7 @@ use super::{
webpki,
};
use futures::{future, Future, Stream};
use futures::{future, stream, Future, Stream};
use futures_watch::Watch;
/// Not-yet-validated settings that are used for both TLS clients and TLS
@ -89,7 +89,10 @@ impl CommonSettings {
let paths = self.paths().iter()
.map(|&p| p.clone())
.collect::<Vec<_>>();
::fs_watch::stream_changes(paths, interval)
// Generate one "change" immediately before starting to watch
// the files, so that we'll try to load them now if they exist.
stream::once(Ok(()))
.chain(::fs_watch::stream_changes(paths, interval))
.filter_map(move |_| {
CommonConfig::load_from_disk(&self)
.map_err(|e| warn!("error reloading TLS config: {:?}, falling back", e))