-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
extensions: strongly prefer type URL lookup #20397
Conversation
Signed-off-by: Kuat Yessenov <kuat@google.com>
Lots of issues... Will require a slog to clean up the codebase from duplicate type URL registrations. |
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
@markdroth would you mind reviwing the API changes here /wait-any |
source/common/config/utility.h
Outdated
Factory* factory = Utility::getFactoryByType<Factory>(message.typed_config()); | ||
if (factory != nullptr) { | ||
return factory; | ||
if (message.has_typed_config()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a step in the wrong direction. My understanding is that we want to go in the direction that the type_url always defines the extension to use. It should not be optional -- we should reject extensions for which there is no embedded config type. If an extension does not need any config, it should still define its own config message type, which can be empty. That way, we still have a way to uniquely identify it.
Note that gRPC already does the above. It has no concept of Envoy's extension names; the extension name idea is considered legacy and IMHO should be removed from Envoy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is the legacy definitions that allow empty typed_config (e.g. HTTP filters in listeners). I think the new definitions already require defined typed_config in which case this condition is always true, but we still have instances without any typed_config in the wild and in the tests here. The proposal is basically restrict the usage of extension names only to those remaining instances without any typed_config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern is that this change does nothing to prevent new extensions from being added without a typed_config. And by documenting the fact that this does work, it actually seems to encourage people into doing that in the future, on the incorrect assumption that this is a supported and intended approach.
I would really prefer to lock this down rather than documenting the fact that it works. How about the following instead:
- Fix all remaining extensions in the Envoy repo to have typed_configs.
- Add a runtime option to reject extensions that do not specify a typed_config. Initially, this will be off by default, but in release N+1, it will be changed to be on by default.
- Add a log message for any extension that does not specify a typed_config, warning people that the config will stop working by default in release N+1.
- At some point in the future, we can remove the runtime option and support only extensions that specify typed_config.
@mattklein123 or @htuch, thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markdroth The specific problem that I'm seeing is that the following pattern happens:
name: <extension_name>
typed_config:
@type_url: <unrelated proto type URL, e.g. struct>
Requiring typed config does not help with this problem. This PR does help. I agree with the second step to deprecate missing typed_config, but that's a different problem, and we can do it in a followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an extension is being configured with the wrong type_url, that definitely seems like something that we should be rejecting. But I think we could eliminate this through basically the same process I described above. Basically, we would implement the warning message and the runtime option after we fail the type_url lookup, and it would be the same regardless of whether the type_url lookup fails because there was no type_url or because the type_url was invalid.
In other words, the code here would be something like this:
Factory* factory = Utility::getFactoryByType<Factory>(message.typed_config());
if (factory != nullptr) {
return factory;
}
LogWarningMessage();
if (runtime_flag_allows_invalid_type_urls) {
return Utility::getFactoryByName<Factory>(message.name());
}
return nullptr;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@htuch Is there a way to use a codepath for-by-name lookup only in existing tests? I tried to get a sense of how much work it is to define protos for every test extension and that seems overwhelming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on a journey to set runtime guard for all legacy tests using by-name lookup. I found internal use for raw_buffer
inside listener manager which I fixed, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kyessenov I think we should file a bug for cleaning up the test extensions. It's a good bug for folks who want to make some early contributions I think (once we have an example PR to point them at to show what needs doing, which would be really useful).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#20476. The bulk of the work is done in this PR, we can make a small follow-up to demonstrate the clean-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM, thanks, I'm good with this PR.
Signed-off-by: Kuat Yessenov <kuat@google.com>
/lgtm api |
This PR has a high potential of having merge conflicts with newly introduced test extensions. Do you think we can merge it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the update, LGTM also
Does it make sense to merge main first to make sure CI is green. Otherwise it would just be reverted. |
Merged main and resolved a conflict. |
@yanavlasov this has been waiting 7 days. what's the plan here? |
This broke
|
It's a merge race. Let's just fix it forward. cc @kyessenov |
#20719 should fix this test. |
- Updated .bazelversion - Reacted to changes in envoyproxy/envoy#20397. Proto extensions are now looked up by @type rather than name in envoy. Getting onto this standard is too much work for this nighthawk update, so instead: - Added a runtime override for all integration test yaml files - Added a runtime override for fake stats sink in the proccess_test unit test Signed-off-by: Nathan Perry <nbperry@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a large number of docs are still using the outdated method and will no longer work. Some examples are docs/root/intro/arch_overview/http/http_connection_management.rst previous_hosts
, a few using envoy.transport_sockets.raw_buffer
- just some examples.
Do we have a plan to update these all?
Yes, those are not using validate code fragments, so it's difficult to identify all case. I can do a sweeping pass over |
/cc @phlax as maybe there is a way to scan for non-validated code fragments ? |
#20812 for a quick pass. |
Use type_url to look up extensions. This prevents the undesirable practice of putting invalid protobufs to avoid a type lookup or duplicating the type URL. Risk Level: medium, affects extensions with duplicated type URLs or no configuration Testing: yes Docs Changes: yes, this has been the recommendation for awhile. Release Notes: yes Runtime Guard: envoy.reloadable_features.no_extension_lookup_by_name Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov kuat@google.com
Commit Message: Use
type_url
to look up extensions. This prevents the undesirable practice of putting invalid protobufs to avoid a type lookup or duplicating the type URL.Risk Level: medium, affects extensions with duplicated type URLs or no configuration
Testing: yes
Docs Changes: yes, this has been the recommendation for awhile.
Release Notes: yes
Runtime Guard: envoy.reloadable_features.no_extension_lookup_by_name