Skip to content

add messageValidationContext into CommonFactoryContext so xDS could u…#9621

Closed
stevenzzzz wants to merge 5 commits intoenvoyproxy:masterfrom
stevenzzzz:promote-validator
Closed

add messageValidationContext into CommonFactoryContext so xDS could u…#9621
stevenzzzz wants to merge 5 commits intoenvoyproxy:masterfrom
stevenzzzz:promote-validator

Conversation

@stevenzzzz
Copy link
Contributor

@stevenzzzz stevenzzzz commented Jan 9, 2020

Signed-off-by: Xin Zhuang stevenzzz@google.com

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md

Description: add messageValidationContext into CommonFactoryContext so xDS could use the correct messageValidator.

Risk Level: LOW, no behavior change.
Testing: unit test adjusted
Docs Changes: N/A
Release Notes: N/A
[Optional Fixes #Issue] #9635

…se dynamic validator

Signed-off-by: Xin Zhuang <stevenzzz@google.com>
Signed-off-by: Xin Zhuang <stevenzzz@google.com>
Signed-off-by: Xin Zhuang <stevenzzz@google.com>
@stevenzzzz
Copy link
Contributor Author

/assign htuch

RouteConfigProviderManagerImpl& route_config_provider_manager)
: config_(new ConfigImpl(config, factory_context.getServerFactoryContext(),
factory_context.messageValidationVisitor(), true)),
factory_context.messageValidationContext().staticValidationVisitor(),
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is right. You can have a static inline route in a dynamic Listener, for example, and we should be applying dynamic validation logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

revert it.
In the long run, I will probably make Listener validator passed down to RDS and its children object. (so that RDS doesn't depend on Listener).

Signed-off-by: Xin Zhuang <stevenzzz@google.com>
…mote-validator

Signed-off-by: Xin Zhuang <stevenzzz@google.com>
envoy::config::core::v3alpha::TrafficDirection direction() const override;
TimeSource& timeSource() override;
ProtobufMessage::ValidationVisitor& messageValidationVisitor() override;
ProtobufMessage::ValidationContext& messageValidationContext() override;
Copy link
Member

Choose a reason for hiding this comment

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

Why do we have both validation visitor and context as peers?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why do we have both validation visitor and context as peers?

removing of validator() will be in another PR, lots of files will be modified as I plan to pass the signal "added_via_api" (or a vlidator parameter) down from Listener to everythin.

Copy link
Member

Choose a reason for hiding this comment

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

Trying to figure out how this works.. do you have a draft PR to see the end results? As mentioned off-line, I'd like to:

  1. Thread validators around, vs. context+flag unless the flag is needed for some other purpose.
  2. Ensure that it's easy for consumers to automatically "do the right thing", without having to think too hard, otherwise we get folks picking random validators via copy+paste.

^^ guided the existing design. We need a bunch of comments to explain this interim solution in any case, as it's pretty confusing why both are there right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#9779 I have it now.
That PR doesn't include the removal of FactoryContext::messageValidationVisitor() tho.
So if we want to remove that later, we will need to pipe a picked validator from listenerImpl down to HCM::Config.

@stale
Copy link

stale bot commented Jan 21, 2020

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Jan 21, 2020
@stevenzzzz
Copy link
Contributor Author

stevenzzzz commented Jan 22, 2020 via email

@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Jan 22, 2020
@yanavlasov yanavlasov requested a review from junr03 January 28, 2020 15:28
@junr03 junr03 self-assigned this Jan 28, 2020
@junr03
Copy link
Member

junr03 commented Jan 28, 2020

will review once merge conflicts updated.

/wait

@stevenzzzz
Copy link
Contributor Author

hi @junr03 could you please look at #9779 instead, so that one has a little bit more change contained, but is more clear reflection on my final goal of "making longlive srds/rds subscriptions".

@stale
Copy link

stale bot commented Feb 4, 2020

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Feb 4, 2020
@stale
Copy link

stale bot commented Feb 11, 2020

This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot closed this Feb 11, 2020
@stevenzzzz stevenzzzz deleted the promote-validator branch March 4, 2020 02:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale stalebot believes this issue/PR has not been touched recently waiting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants