Skip to content

test: convert router v1 JSON test configs to v2 YAML#6332

Merged
mattklein123 merged 9 commits intoenvoyproxy:masterfrom
derekargueta:dereka/4616
Mar 27, 2019
Merged

test: convert router v1 JSON test configs to v2 YAML#6332
mattklein123 merged 9 commits intoenvoyproxy:masterfrom
derekargueta:dereka/4616

Conversation

@derekargueta
Copy link
Copy Markdown
Member

@derekargueta derekargueta commented Mar 20, 2019

Description: This pull request converts all v1 JSON config test snippets to v2 YAML. There are multiple reasons for this:

  1. One way to load configs (parseRouteConfigurationFromV2Yaml)
  2. v1 API is deprecated. This makes testing v2 changes easier, so that one does not have to muck with the v1 to v2 translation code (i.e. [v1.8.0 (Oct 4, 2018) deprecation] Remove features marked deprecated in #3838 #4616)
  3. Remove another dependency on v1 API/JSON code
  4. Consistency of YAML/JSON in these tests.

notes

  • 1 test,TestBadCorsConfig, was removed in the process. It doesn't appear to violate any V2 API constraints so when passed through V2 parsing the test fails to throw any exceptions.
  • 2 tests, BadRouteEntryConfigMissingPathSpecifier and BadRouteEntryConfigNoRedirectNoClusters, were swapped to use EXPECT_DEATH instead of EXPECT_THROW_WITH_MESSAGE. The exceptions previously thrown were part of rds_json.cc when converting v1 to v2.

Besides the above mentions, no test assertions were modified, only the test data to conform to v2.

Risk Level: Low
Docs Changes: No functional changes
Release Notes: No functional changes
Pt. 1/2 of #4616

Signed-off-by: Derek Argueta dereka@pinterest.com

Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
@derekargueta derekargueta changed the title [test] convert router v1 JSON test configs to v2 YAML test: convert router v1 JSON test configs to v2 YAML Mar 20, 2019
@derekargueta
Copy link
Copy Markdown
Member Author

hmm the two tests I switched to EXPECT_DEATH fail in the release build since they're not release asserts.

[  FAILED  ] BadHttpRouteConfigurationsTest.BadRouteEntryConfigMissingPathSpecifier
[  FAILED  ] BadHttpRouteConfigurationsTest.BadRouteEntryConfigNoAction

These seem like good test cases to retain, but wasn't sure whether to

  1. switch them to expect assertions
  2. modify config_impl.cc to throw an exception in these cases (these are covered by Protobuf validation, but those aren't tested here. Should I be using a different config load function that will run protobuf validations?)
  3. remove these tests, relying on protobuf validation (don't think this would be right, as we should still exercise these paths)

@mattklein123
Copy link
Copy Markdown
Member

@derekargueta you are a hero, that's all I have to say.

@jmarantz jmarantz requested a review from snowp March 21, 2019 17:40
@derekargueta
Copy link
Copy Markdown
Member Author

So my update here: still a bit stuck on those 2 tests, trying to get them to throw exceptions again. It seems that the protobuf validation get's executed when running MessageUtil::Validate so I added that to parseRouteConfigurationFromV2Yaml after MessageUtil::loadFromYaml. When I try running that on route configs I get

bazel-out/darwin-fastbuild/bin/source/common/protobuf/_virtual_includes/utility_lib/common/protobuf/utility.h:226:10: error: use of undeclared identifier 'Validate'
    if (!Validate(message, &err)) {

Validate appears to come from Protobuf? Can't find its declaration/definition anywhere in Envoy source. I added the .pb.h files and bazel dependences, as specified by the docstring for MessateUtil::validate but still no go.

So my question (I suppose for @snowp) is am I moving in the right direction? Do we want to validate protobuf constraints as part of config tests? If we don't run validation, then malformed configs pass to config_impl.cc perfectly fine, just with default values I suppose.

@derekargueta
Copy link
Copy Markdown
Member Author

derekargueta commented Mar 21, 2019

FWIW the HCM config tests (my next target) are in a similar state - v1 JSON test configs that will throw errors during the v1-v2 translation phase, not protobuf validation.

Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
@derekargueta
Copy link
Copy Markdown
Member Author

Figured out how to apply proto validation here, so we should be green-light for test parity without relying on the exceptions thrown during the v1->v2 translation.

@derekargueta
Copy link
Copy Markdown
Member Author

/retest

@repokitteh-read-only
Copy link
Copy Markdown

🙀 failed invoking rebuild of ci/circleci: coverage: 500 Internal Server Error

🐱

Caused by: a #6332 (comment) was created by @derekargueta.

see: more, trace.

Copy link
Copy Markdown
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

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

Thanks, this looks great. Few comments/questions

TestEnvironment::writeStringToFileForTest("direct_response_body", "Example text 3");

// A superset of v1_json, with API v2 direct-response configuration added.
static const std::string v2_yaml = R"EOF(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

minor nit but maybe this shouldn't reference v2 anymore?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

sure


TestConfigImpl v2_yaml_config(parseRouteConfigurationFromV2Yaml(v2_yaml), factory_context_, true);
testConfig(v2_yaml_config, true);
testConfig(v2_yaml_config);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Since this is only invoked once now, maybe inline the lambda?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

sure

route:
cluster: some-cluster
idle_timeout: 0s
idle_timeout: 1s
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why did this change? Validation?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes, protobuf validation. (I'm no protobuf expert, but appears (validate.rules).duration.gt = {} is equivalent to > 0?)

I'm actually going to change this back to zero, but use EXPECT_THROW instead as that's the new expected behavior in v2. (ExplicitIdleTimeout below already tests a good idle_timeout so this test would be redundant)

Signed-off-by: Derek Argueta <dereka@pinterest.com>
snowp
snowp previously approved these changes Mar 25, 2019
Copy link
Copy Markdown
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

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

Thanks!

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thanks, so amazing. One question.

/wait-any

EXPECT_THROW_WITH_MESSAGE(
TestConfigImpl(parseRouteConfigurationFromJson(json), factory_context_, true), EnvoyException,
"routes must have redirect or one of cluster/cluster_header/weighted_clusters")
EXPECT_THROW(TestConfigImpl(parseRouteConfigurationFromV2Yaml(yaml), factory_context_, true),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Did this change because it's now handled by validation? Is it possible to include the validation error message? Same above?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Ah yeah, forgot to come back to these after figuring out protobuf validation. Handled now. Using _WITH_REGEX with the critical message part since the protobuf errors are pretty verbose

Signed-off-by: Derek Argueta <dereka@pinterest.com>
Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Thank you!!! HERO!

@mattklein123 mattklein123 merged commit 2a2a886 into envoyproxy:master Mar 27, 2019
@derekargueta derekargueta deleted the dereka/4616 branch March 27, 2019 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants