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

config: refactor filter registration #1083

Merged
merged 7 commits into from
Jun 13, 2017
Merged

config: refactor filter registration #1083

merged 7 commits into from
Jun 13, 2017

Conversation

mattklein123
Copy link
Member

@mattklein123 mattklein123 commented Jun 11, 2017

For LDS, we need to plumb a stats scope through to all of the filter
factory creation functions. This commit takes the opportunity to no
longer pass the full server and instead passes a new FactoryContext
interface which will allow us to more easily alter what is seen by
filters in the future. While making the same breaking change, I
took the opportunity to encode the type of filter into the registration
which removes a ton of boilerplate from various places. (We have
decided to remove the ability to explicitly configure filter type in the
v2 API).

Though this is a breaking change, since we
are still in the 1.4.0 release cycle I will not be deprecating
the new network/http filter registration functions that were
added during this cycle.

This commit also improves some related coverage and gets us up to
around 98.2%. I will do a follow up change with some other easy
coverage wins that I notice.

@htuch
Copy link
Member

htuch commented Jun 11, 2017

Seems reasonable at design level. To simplify review, could you split out the mechanical rename of scope/stats and any other trivials into a separate PR?

@mattklein123
Copy link
Member Author

Yes I will split it. Right now I'm just trying to clean up some stuff and see a coverage report.

@mattklein123 mattklein123 force-pushed the lds_refactor branch 2 times, most recently from e37f4db to 01c5941 Compare June 13, 2017 00:05
For LDS, we need to plumb a stats scope through to all of the filter
factory creation functions. This commit takes the opportunity to no
longer pass the full server and instead passes a new FactoryContext
interface which will allow us to more easily alter what is seen by
filters in the future. Though this is a breaking change, since we
are still in the 1.4.0 release cycle I will not be deprecating
the new network/http filter registration functions that were
added during this cycle.
@mattklein123
Copy link
Member Author

@lyft/network-team @htuch this is ready to go. I tried to reduce it down as much as possible. It's mostly just boilerplate changes. @htuch I will trade you the other reviews in the morning.

@mattklein123 mattklein123 changed the title config: refactor filter registration [WIP DO NOT REVIEW] config: refactor filter registration Jun 13, 2017
@mattklein123
Copy link
Member Author

Sorry it's ready to go modulo fixing the example config repo. Will do that in the morning. The rest is ready to review.

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


envoy_cc_library(
name = "filter_config_interface",
hdrs = ["filter_config.h"],
Copy link
Member

Choose a reason for hiding this comment

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

This should have deps for all the included header interfaces.

/**
* @return Upstream::ClusterManager& singleton for use by the entire server.
*/
virtual Upstream::ClusterManager& clusterManager() PURE;
Copy link
Member

Choose a reason for hiding this comment

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

I assume all of these are needed for existing filter and there is no further way to minimize the exposed surface.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, minimized as much as possible.

/**
* This lambda is used to wrap the creation of a network filter chain for new connections as they
* come in. Filter factories create the lambda at configuration initialization time, and then they
* are used at runtime. This maps JSON -> runtime configuration.
Copy link
Member

Choose a reason for hiding this comment

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

It's a bit unclear from this type signature that this is what is happening. All you get is a Network::FilterManager, whereas when I look at how this is used later, it's capturing JSON config in the lambda in some examples. I think maybe this should be made clearer.

enum class NetworkFilterType { Read, Write, Both };

/**
* This lambda is used to wrap the creation of a network filter chain for new connections as they
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Since this is std::function, it's not necessarily a lambda.

* of general error or a Json::Exception if the json configuration is erroneous. The returned
* callback should always be initialized.
* @param config supplies the general json configuration for the filter
* @param context supplies the filter's context.
Copy link
Member

Choose a reason for hiding this comment

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

Nit: @return


/**
* Returns the identifying name for a particular implementation of a network filter produced by
* the factory.
Copy link
Member

Choose a reason for hiding this comment

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

Nit: @return

/**
* Create a particular network filter factory implementation. If the implementation is unable to
* produce a factory with the provided parameters, it should throw an EnvoyException in the case
* of general error or a Json::Exception if the json configuration is erroneous. The returned
Copy link
Member

Choose a reason for hiding this comment

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

What if the factory lambda captures some JSON config and then finds an issue at runtime instantiation?

* Create a particular http filter factory implementation. If the implementation is unable to
* produce a factory with the provided parameters, it should throw an EnvoyException in the case of
* general error or a Json::Exception if the json configuration is erroneous. The returned
* callback should always be initialized.
Copy link
Member

Choose a reason for hiding this comment

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

Same comments as for the network filters above.

@@ -158,17 +152,17 @@ HttpConnectionManagerConfig::HttpConnectionManagerConfig(const Json::Object& con

// Now see if there is a factory that will accept the config.
auto search_it = namedFilterConfigFactories().find(string_name);
if (search_it != namedFilterConfigFactories().end()) {
if (search_it != namedFilterConfigFactories().end() && search_it->second->type() == type) {
Copy link
Member

Choose a reason for hiding this comment

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

Are there tests covering a found filter with wrong type?

Copy link
Member Author

Choose a reason for hiding this comment

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

Probably not. Will add.

@mattklein123
Copy link
Member Author

Note that re: the comments about the function documentation, I just copied that, but will go ahead and clean up the text to make it more clear.

mattklein123 added a commit to envoyproxy/envoy-filter-example that referenced this pull request Jun 13, 2017
@mattklein123
Copy link
Member Author

@htuch updated per comments

* callback should always be initialized.
* @param config supplies the general json configuration for the filter
* @param context supplies the filter's context.
* @return NetworkFilterFactoryCb fixfix
Copy link
Member

Choose a reason for hiding this comment

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

fixfix :-)

* @param config supplies the general json configuration for the filter
* @param stat_prefix prefix for stat logging
* @param context supplies the filter's context.
* @return HttpFilterFactoryCb fixfix
Copy link
Member

Choose a reason for hiding this comment

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

here as well, fixfix

Copy link
Member

@RomanDzhabarov RomanDzhabarov left a comment

Choose a reason for hiding this comment

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

lgtm

@RomanDzhabarov RomanDzhabarov merged commit e9c56dc into master Jun 13, 2017
mattklein123 added a commit to envoyproxy/envoy-filter-example that referenced this pull request Jun 13, 2017
* updates required for envoyproxy/envoy#1083

* update envoy
mattklein123 added a commit that referenced this pull request Jun 13, 2017
Cleanups from #1083. Rename
some variables and repoint to filter example master. No logic
changes.
mattklein123 added a commit that referenced this pull request Jun 13, 2017
Cleanups from #1083. Rename
some variables and repoint to filter example master. No logic
changes.
mattklein123 added a commit that referenced this pull request Jun 14, 2017
Regression from #1083. The listener
config needs two scopes. One for listener named stats, and one for global
named stats that need to be reaped during LDS processing.
mattklein123 added a commit that referenced this pull request Jun 14, 2017
Regression from #1083. The listener
config needs two scopes. One for listener named stats, and one for global
named stats that need to be reaped during LDS processing.
@mattklein123 mattklein123 deleted the lds_refactor branch June 16, 2017 23:00
jpsim pushed a commit that referenced this pull request Nov 28, 2022
Signed-off-by: Jose Nino <[email protected]>
Signed-off-by: JP Simard <[email protected]>
jpsim pushed a commit that referenced this pull request Nov 29, 2022
Signed-off-by: Jose Nino <[email protected]>
Signed-off-by: JP Simard <[email protected]>
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