-
Notifications
You must be signed in to change notification settings - Fork 83
[pluggable-validation / 2]: implement core adjustment validation. #170
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -229,6 +229,11 @@ func (p *plugin) isExternal() bool { | |
| return p.cmd == nil | ||
| } | ||
|
|
||
| // Check if the plugin is a container adjustment validator. | ||
| func (p *plugin) isContainerAdjustmentValidator() bool { | ||
| return p.events.IsSet(Event_VALIDATE_CONTAINER_ADJUSTMENT) | ||
| } | ||
|
|
||
| // 'connect' a plugin, setting up multiplexing on its socket. | ||
| func (p *plugin) connect(conn stdnet.Conn) (retErr error) { | ||
| mux := multiplex.Multiplex(conn, multiplex.WithBlockedRead()) | ||
|
|
@@ -675,6 +680,26 @@ func (p *plugin) StateChange(ctx context.Context, evt *StateChangeEvent) (err er | |
| return nil | ||
| } | ||
|
|
||
| func (p *plugin) ValidateContainerAdjustment(ctx context.Context, req *ValidateContainerAdjustmentRequest) error { | ||
| if !p.events.IsSet(Event_VALIDATE_CONTAINER_ADJUSTMENT) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Could we make use of
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here, I'd prefer to keep, in that regard, the boilerplate to forward the request to the plugin identical to the other boilerplates. The is*-checker is used in a different context, where it is more readable to hide the test behind a function with a self-explanatory name.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If there is a strong feeling against having both, then I think I'd rather get rid of isContainerAdjustmentValidator() and write it out in the other context. |
||
| return nil | ||
| } | ||
|
|
||
| ctx, cancel := context.WithTimeout(ctx, getPluginRequestTimeout()) | ||
| defer cancel() | ||
|
|
||
| rpl, err := p.impl.ValidateContainerAdjustment(ctx, req) | ||
| if err != nil { | ||
| if isFatalError(err) { | ||
| log.Errorf(ctx, "closing plugin %s, failed to validate request: %v", p.name(), err) | ||
| p.close() | ||
| } | ||
| return fmt.Errorf("validator plugin %s failed: %v", p.name(), err) | ||
| } | ||
|
|
||
| return rpl.ValidationResult(p.name()) | ||
| } | ||
|
|
||
| // isFatalError returns true if the error is fatal and the plugin connection should be closed. | ||
| func isFatalError(err error) bool { | ||
| switch { | ||
|
|
||
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.
Just a note for the future that we might want to revisit this slightly and think about whether we want to limit the concurrency a bit; might become an issue if there are many validator plugins. No need to change as part of this PR.
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.
@chrishenzie Yes, I think it will be a good idea to emphasize in the documentation that during the validation phase there is no 'plugin ordering by index' as validating plugins are run in parallel.
But regarding users wondering "why they don't get priority", I think they should not. Any presumed ordering/priority would be relevant only if it was possible to force validation both to fail and to succeed. But our semantics is deliberately such that the latter is not possible.
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.
true and users of the api may want ordering regardless of our scheme... E.g. I will only approve after ___ approval, if my check is also valid. Allocate claim foo before claim foo'...
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.
typically one would have a set operating in parallel at a level where the higher levels must finish first? built-in, set-a.. set b with a dependency in set-a..
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 validations are a logical AND, so if any fails the container is rejected. I don't think you can model "I will only approve after $foo approval" since if $foo rejects the container is rejected anyway, and if $foo succeeds then you'd also succeed your validation?