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

fuzz: add bounds to statsh flush interval #8043

Merged
merged 3 commits into from
Aug 27, 2019
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion api/envoy/config/bootstrap/v2/bootstrap.proto
Original file line number Diff line number Diff line change
Expand Up @@ -99,7 +99,13 @@ message Bootstrap {
// performance reasons Envoy latches counters and only flushes counters and
// gauges at a periodic interval. If not specified the default is 5000ms (5
// seconds).
google.protobuf.Duration stats_flush_interval = 7 [(gogoproto.stdduration) = true];
google.protobuf.Duration stats_flush_interval = 7 [
(validate.rules).duration = {
lt: {seconds: 60},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would make this much larger, like 5 minutes max?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks

gte: {nanos: 1000000}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment here on what human readable time this is?

},
(gogoproto.stdduration) = true
];

// Optional watchdog configuration.
Watchdog watchdog = 8;
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
static_resources {
clusters {
name: "@"
connect_timeout {
nanos: 250000000
}
common_lb_config {
zone_aware_lb_config {
min_cluster_size {
value: 38
}
}
}
}
}
stats_flush_interval {
nanos: 32256
}
10 changes: 10 additions & 0 deletions test/server/server_fuzz_test.cc
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
#include <fstream>

#include "envoy/config/bootstrap/v2/bootstrap.pb.validate.h"

#include "common/network/address_impl.h"
#include "common/thread_local/thread_local_impl.h"

Expand Down Expand Up @@ -61,6 +63,14 @@ class AllFeaturesHooks : public DefaultListenerHooks {
};

DEFINE_PROTO_FUZZER(const envoy::config::bootstrap::v2::Bootstrap& input) {
try {
// Validate the input early.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to validate early? I think part of the goal of this test is to ensure that the validation logic itself is happening as expected, or are you thinking that config_fuzz_test plays this role, and sever_fuzz_test can do more useful things by getting validation cleared early?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured server_fuzz_test would have more overhead than config_fuzz_test, but I think if I want to make some distinction between these fuzz tests (i.e. only feeding the slow one valid configs), I'll make that clear later and actually analyze if their performance difference is significant.

TestUtility::validate(input);
} catch (const EnvoyException& ex) {
ENVOY_LOG_MISC(debug, "Controlled EnvoyException exit: {}", ex.what());
return;
}

testing::NiceMock<MockOptions> options;
AllFeaturesHooks hooks;
testing::NiceMock<MockHotRestart> restart;
Expand Down