Skip to content

listener: add listener info to the contexts#31067

Merged
alyssawilk merged 21 commits intoenvoyproxy:mainfrom
kyessenov:add_listener_info
Dec 6, 2023
Merged

listener: add listener info to the contexts#31067
alyssawilk merged 21 commits intoenvoyproxy:mainfrom
kyessenov:add_listener_info

Conversation

@kyessenov
Copy link
Copy Markdown
Contributor

Commit Message: Refactor to consolidate listener info and expose it in wider contexts. The concrete issue was that I wanted to use listener properties (direction) in the access logger, but only the filter context has it. By keeping the information in one place, I think we can also trim the large listener proto in the future.
Risk Level: low, internal refactor
Testing: regression
Docs Changes: none
Release Notes: none

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>
@wbpcode
Copy link
Copy Markdown
Member

wbpcode commented Nov 28, 2023

Great job. But I believe the AccessLogFactoryContext will be removed soon. And now FactoryContext is used by the logger factory directly.
Would you like to do the clean up directly? I mean to remove the AccessLogFactoryContext in this patch directly. :)

@wbpcode wbpcode self-assigned this Nov 28, 2023
@kyessenov
Copy link
Copy Markdown
Contributor Author

Oh, didn't realize the access log factory context is gone. Yes, I can delete it here, since this PR already forces some minor refactors on the code.

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

@wbpcode wbpcode left a comment

Choose a reason for hiding this comment

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

Thanks. LGTM overall. Only two comments are added.

Comment thread envoy/network/listener.h
Comment thread envoy/server/factory_context.h Outdated
@zirain
Copy link
Copy Markdown
Member

zirain commented Nov 28, 2023

The concrete issue was that I wanted to use listener properties (direction) in the access logger

IIUC, envoy can expose TrafficDirection to access log with this patch?

@kyessenov
Copy link
Copy Markdown
Contributor Author

@zirain Yes, the goal is to make istio_stats act like an access logger, which implies the regular access loggers will have access to everything istio_stats uses.

@zirain
Copy link
Copy Markdown
Member

zirain commented Nov 28, 2023

@zirain Yes, the goal is to make istio_stats act like an access logger, which implies the regular access loggers will have access to everything istio_stats uses.

that's great, I recall I need this.

Copy link
Copy Markdown
Member

@wbpcode wbpcode left a comment

Choose a reason for hiding this comment

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

Just take a full pass. It's pretty great and I have no much comments to it. Sorry again for the noise of ListenerInfo and ListenerConfig. I think your previous design maybe better.
Thanks so much for your great contribution. And please check the CI.

Comment thread contrib/generic_proxy/filters/network/test/config_test.cc
Comment thread envoy/network/listener.h Outdated
* A configuration for an individual listener.
*/
class ListenerConfig {
class ListenerConfig : public ListenerInfo {
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.

if it's because the lifetime problem, then I think you previous design is reasonable. (sorry

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

No worries, reverted. I kept the change to remove listenerConfig from ListenerFactoryContext and isQuicListener from FactoryContext.

Comment on lines -36 to +38
ON_CALL(context_, listenerMetadata()).WillByDefault(ReturnRef(listener_metadata_));
ON_CALL(context_, listenerInfo()).WillByDefault(ReturnRef(listener_info_));
ON_CALL(listener_info_, metadata()).WillByDefault(ReturnRef(listener_metadata_));
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.

ON_CALL(context_.listener_info_, ...); is enough. We needn't create a local listener info again.

This reverts commit a63a39d.

Signed-off-by: Kuat Yessenov <kuat@google.com>
Signed-off-by: Kuat Yessenov <kuat@google.com>
wbpcode
wbpcode previously approved these changes Nov 30, 2023
Copy link
Copy Markdown
Member

@wbpcode wbpcode left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks. cc Hi, @alyssawilk, could you also take a look when you have free time in case I missed something, thanks.

@wbpcode wbpcode assigned alyssawilk and unassigned wbpcode Nov 30, 2023

class ListenerInfoImpl : public Network::ListenerInfo {
public:
explicit ListenerInfoImpl(const envoy::config::listener::v3::Listener config)
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.

nit, this can be a reference 'const envoy::config::listener::v3::Listener& config'

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good catch, thanks.

Copy link
Copy Markdown
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

Very nice clean up!

/**
* @return ListenerInfo description of the listener.
*/
virtual const Network::ListenerInfo& listenerInfo() const PURE;
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.

I like the consolidation but it feels like a regression to add more listener info into the non-listener-named factory context. I suspect it'd be a complete PITA to move this accessor down to the ListenerFactoryContext but have we tried to see how bad it would be?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We'd have to change the signature of network filters at the very least - HCM needs isQuic check which needs the listener info. I suspect most of the uses for FactoryContext are actually ListenerFactoryContext. What is called ListenerFactoryContext is only used by listener filters.

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.

I suspect most of the uses for FactoryContext are actually ListenerFactoryContext. What is called ListenerFactoryContext is only used by listener filters.

Yeah, actually almost all FactoryContext is a listener factory context that provide isQuicListener, listenerMetadata, listenerTypedMetadata, etc. methods.

Maybe we can just rename it to ListenerFactoryContext in the future with a simple name replacement, if we want.

*/
virtual const Network::ListenerConfig& listenerConfig() const PURE;
};
class ListenerFactoryContext : public virtual FactoryContext {};
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.

ooc if we keep this and it has no functions can it just be typeddefd to FactoryContext or does that cause inheritance problems?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It's still painful with mocks/fakes. I thought it's better to delete it then - do you want to try that?

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.

I think we can just clean up it with a new PR.

createListenerFilterFactories();
validateFilterChains();
buildFilterChains();
buildUdpListenerFactory(config, parent_.server_.options().concurrency());
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.

mild preference for leaving these function definitions as-is and adding a protected accessor config() which returns info->config()

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I thought it would be good to delete config() accessor long term because storing the proto as-is can be expensive with large listeners or Wasm. It's only needed for config dump which can be optimized to recreate the proto like it's done in some other places.

namespace Envoy {
namespace Server {

class EmptyListenerInfo : public Network::ListenerInfo {
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 not just create a listener info impl with minimal contents?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Didn't want to bring a dependency on extensions...

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.

admin already depends on listener no? and listenre is moving back to core code soon. we could alternately factor it out into a minimal library? I'm just not a fan of one-off admin classes but I can look the other way if it's a pain =P

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sure, if we're OK sharing the code in listener_manager, I deleted this dummy class.

envoy::config::core::v3::TrafficDirection FactoryContextImpl::direction() const {
return config_.traffic_direction();
}
const Network::ListenerInfo& FactoryContextImpl::listenerInfo() const { return listener_info_; }
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.

nice clean up

Signed-off-by: Kuat Yessenov <kuat@google.com>
soulxu
soulxu previously approved these changes Dec 1, 2023
Copy link
Copy Markdown
Member

@soulxu soulxu left a comment

Choose a reason for hiding this comment

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

LGTM, thanks

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

wbpcode commented Dec 5, 2023

CI still requires a check.

@wbpcode
Copy link
Copy Markdown
Member

wbpcode commented Dec 5, 2023

/wait

@kyessenov
Copy link
Copy Markdown
Contributor Author

Hmmm, might be something unrelated https://dev.azure.com/cncf/envoy/_build/results?buildId=157018&view=logs&jobId=8c169225-0ae8-53bd-947f-07cb81846cb5&j=8c169225-0ae8-53bd-947f-07cb81846cb5&t=d1a98671-b7ba-5fbf-f06c-ff337c010df4.

/retest

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

wbpcode commented Dec 6, 2023

/retest

@wbpcode
Copy link
Copy Markdown
Member

wbpcode commented Dec 6, 2023

(Recently, we also are refactoring factory context related things which result in some conflictions. Sorry for that. There are still last one PR.)

@alyssawilk alyssawilk merged commit 148fd48 into envoyproxy:main Dec 6, 2023
* without reaching to Envoy maintainers first.
*/
class ListenerAccessLogFactoryContext : public virtual CommonFactoryContext {
class FactoryContext : public virtual CommonFactoryContext {
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.

@kyessenov need to update the comment of this class? it looks like a little mismatch?

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.

5 participants