Replace args with struct for grpc registration. #4372
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Michael Nelson minelson@vmware.com
Description of the change
This is a prequel to #4370 . It doesn't make any functional change, but just pulls out the arguments to the dynamically loaded grpc registration function into a struct defined in the one place. This makes it easier moving forward for us to modify it when needed in the one place. Please see #4370 for an example where we ensure plugins have access to QPS and Burst options without having to change other plugins necessarily.
Benefits
Easier to modify grpc registration args in the future.
Possible drawbacks
Applicable issues
Additional information
I again hit an import naming issue here, because some plugins import both the generated plugins/v1alpha1 as well as our implementation module for plugins/v1alpha1. So @antgamdia , I looked up your earlier #4176 where you'd put some thought into this and found in the list there, where I think you found options for this same situation:
Now I assume the last entry there is incorrect (probably before you'd realised that some modules import both) as it duplicates the alias of the 3rd and the import path of the first. Similarly, I think the 2nd is misnamed (it's a flux plugin), and so I have used here the examples from the 1st and 3rd entries in the above snippet for the generated module and our implementation module.
Let me know if that's not what you intended.