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] resolve the inconsistency treatment of parse-error vs validation-error in XDS onConfigUpdate(resources, version) API. #7508

Closed
stevenzzzz opened this issue Jul 9, 2019 · 6 comments
Assignees
Labels
enhancement Feature requests. Not bugs or questions. stale stalebot believes this issue/PR has not been touched recently

Comments

@stevenzzzz
Copy link
Contributor

stevenzzzz commented Jul 9, 2019

Issue Template

Title: Fully reject (reject-all) on parse-error or PGV validation-error in the "old" CDS onConfigUpdate(resources, version) API.

Description:

Before the delta API impl, CDS onConfigUpdate rejects a DiscoveryResponse if there is any parse-error (anyConvert failure) or validation-error (PGV validation error).
In the new CDS impl, the old "status-of-the-world" onConfigUpdate(resources, version) calls the delta form onConfigUpdate(added_resources, removed_resources, version) API, by splitting the "resources" into "added_resources" and "removed_resources".
The PGV validation errors are treated as forgivable errors (the delta form will skip the invalid ones), while the parse-errors (anyConvert) are treated differently: any parse-error in the old-form onConfigUpdate will cause a "reject-all" failure on the onConfigUpdate(resources, version) API call, as there is no try-catch in the function body.

In the onConfigUpdate(resources, version) function, parse-error should not be forgiven as well: we compute the to-be-removed resource names based on parsed proto's resource name, skipping a parse error means we will erroneously remove a resource.

Talked with @htuch, we'd like the impl to go back to the previous behavior: reject-all if there is any error (parse-error, PGV validation error) in the old form onConfigUpdate(resources, version) API call. And by design deltaAPI onConfigUpdate should tolerate both errors(Partial-reject).

[optional Relevant Links:]

See also discussion around #5739

@stevenzzzz
Copy link
Contributor Author

loop in @fredlas for discussion.

@htuch
Copy link
Member

htuch commented Jul 9, 2019

We need to be consistent across all xDS here as well. I would love to be able to have some generic code handle this (appropriately templated) to avoid having each xDS make the same mistake.

@stevenzzzz
Copy link
Contributor Author

sure thing, I will go through all the API impl to have a consistent behavior, there is actually a TODO I am leaving in PR #7451 about it.

@stevenzzzz stevenzzzz changed the title [CDS] resolve the inconsistency treatment of parse-error vs validation-error in CDS onConfigUpdate(resources, version) API. [XDS] resolve the inconsistency treatment of parse-error vs validation-error in XDS onConfigUpdate(resources, version) API. Jul 9, 2019
@htuch htuch added the enhancement Feature requests. Not bugs or questions. label Jul 9, 2019
@stale
Copy link

stale bot commented Aug 8, 2019

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Aug 8, 2019
@stale
Copy link

stale bot commented Aug 15, 2019

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

@stale stale bot closed this as completed Aug 15, 2019
@stevenzzzz
Copy link
Contributor Author

I think we still want this,reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests. Not bugs or questions. stale stalebot believes this issue/PR has not been touched recently
Projects
None yet
Development

No branches or pull requests

2 participants