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

xds: define empty config protos #9581

Merged
merged 20 commits into from
Jan 8, 2020
Merged

Conversation

kyessenov
Copy link
Contributor

Description: define empty config protos for all filters expecting google::protobuf::Empty
Risk Level: medium (change of config type)
Testing: unit
Docs Changes: done
Release Notes: define config protos for all extensions

derekargueta and others added 8 commits December 18, 2019 23:36
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #9581 was opened by kyessenov.

see: more, trace.

@kyessenov
Copy link
Contributor Author

I am wondering why there is a fallback in translateOpaqueConfig that does JSON round-tripping to convert a proto into another proto. While that helps here to convert Empty to an empty proto, it seems a bit unsafe to allow arbitrary Any to Any conversion.

Signed-off-by: Kuat Yessenov <kuat@google.com>
@htuch
Copy link
Member

htuch commented Jan 7, 2020

@kyessenov can you give an example of how the unsafe conversion could be an issue? I think usually we should expect that in an opaque config, the intent is to describe the type that belongs to the filter. If it's untyped config, it's fine to JSON convert. For typed config, we probably could be a bit stricter on the fallback; only allow the existing or previous types of a specific message to be converted, but that seems a nice-to-have safety improvement, not a particularly dangerous thing as is.

@htuch htuch self-assigned this Jan 7, 2020
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

This is great, thanks so much for taking this on (and @derekargueta for kicking off this initiative).

@htuch htuch added the waiting label Jan 7, 2020
@kyessenov
Copy link
Contributor Author

@htuch It's odd because going through JSON loses type information, so if you have two Anys with different types for the same field, it's unclear what happens. It also means we cannot use the type as the primary way to identify the extension (what if you use one extension type as Any for another extension).

Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Generally LGTM, some comments and need to fix docs build. Thanks.

// Fail in an obvious way if a plugin does not return a proto.
RELEASE_ASSERT(config != nullptr, "");

// Check that the config type is not google.protobuf.Empty
RELEASE_ASSERT(config->GetDescriptor()->full_name() != "google.protobuf.Empty", "");
Copy link
Member

Choose a reason for hiding this comment

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

Nice-to-have expect-death test for this..

Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGTM modulo versionless packages comment and CI passing, thanks!
/wait

api/BUILD Outdated
@@ -89,13 +99,16 @@ proto_library(
"//envoy/config/rbac/v3alpha:pkg",
"//envoy/config/resource_monitor/fixed_heap/v2alpha:pkg",
"//envoy/config/resource_monitor/injected_resource/v2alpha:pkg",
"//envoy/config/retry/omit_canary_hosts:pkg",
"//envoy/config/retry/previous_hosts:pkg",
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 switch these to be in versioned packages? I'm working on a PR to fix previous_priorities as a versionless special case, trying to avoid any new ones creeping in.

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.

Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Thanks!

@repokitteh-read-only repokitteh-read-only bot removed the api label Jan 8, 2020
@htuch htuch merged commit 2d5a4e9 into envoyproxy:master Jan 8, 2020
@kyessenov kyessenov deleted the empty-proto branch January 8, 2020 18:45
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