feat: metric plugin system based on hashicorp go-plugin #2514
Conversation
Codecov ReportBase: 81.66% // Head: 81.59% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2514 +/- ##
==========================================
- Coverage 81.66% 81.59% -0.07%
==========================================
Files 126 130 +4
Lines 19147 19469 +322
==========================================
+ Hits 15636 15886 +250
- Misses 2717 2766 +49
- Partials 794 817 +23
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
After talking with @jessesuen who brought up an idea to look into wasm for plugins. The findings of that research turned out to be that today wasm plugins are currently not an option for Rollouts they have some shortcomings such as no golang runtime currently support network requests or really any io syscalls. There are other maturity issues as well, so the plan is to continue with go-plugins and revisit wasm if/when it makes sense. |
zachaller
force-pushed
the
feat-plugin-system
branch
from
7c887c3
to
2b1e125
Compare
zachaller
force-pushed
the
feat-plugin-system
branch
from
bd72d42
to
a1ca692
Compare
|
Does this only support a single plugin at a time? It also requires admin-side config, where jobs did not, so perhaps that is also an issue. Or do I misunderstand that only one plugin can be provided? |
|
Yes this is an admin level config due to the fact in order to set it up you need to add a flag to the controller with a path to the binary executable plugin. This limits it to one plugin per controller aka you have some custom metrics system you company uses but it is not supported by rollouts this gives you the option to add that. You could create a plugin though that supports multiple systems etc. |
|
I did think about possibly doing a multiple plugin system that would allow end users to install other plugins per analysis templates but then we need to figure out how to package those up and install them as well etc. On the flip side I could also see this plugin system having someone else just create say a multi end-user plugin system that deals with packaging downloading plugins etc etc if people think that is valuable but would be curious about use cases either way. |
Signed-off-by: zachaller <[email protected]>
zachaller
force-pushed
the
feat-plugin-system
branch
from
2667fee
to
14fc188
Compare
…plugin-system Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
Signed-off-by: zachaller <[email protected]>
utils/plugin/plugin_downloader.go
Outdated
| return fmt.Errorf("failed to parse plugin location: %w", err) | ||
| } | ||
|
|
||
| finalFileLocation := filepath.Join(absoluteFilepath, plugin.Name) |
There was a problem hiding this comment.
how are we going to handle 2 plugins with the same name? wouldn't it be better to have some sort of namespace for plugins as well?
There was a problem hiding this comment.
correct this does not support two plugins with the same name I am not sure of the value 100% with that and it is somewhat controlled via the plugin themself because it is the registration method as well, aka plugins need to know where to look for their config at. I think we could provide a best practice as a plugin author to namespace them. Do you have any thoughts on what would make sense for namespace?
There was a problem hiding this comment.
Talking with leo we will probably try to enforce a strict file naming convention based on git repo to allow multiple plugins.
| "k8s.io/client-go/kubernetes/fake" | ||
| ) | ||
|
|
||
| func TestGetPluginLocation(t *testing.T) { |
There was a problem hiding this comment.
We use mockery to auto generate mocks from interfaces in Argo CD. This is something that you can have taken advantage as well to implement more test cases. Not a blocker, mainly a suggestion to improve the coverage.
Signed-off-by: zachaller <[email protected]>
| assert.Error(t, err) | ||
| } | ||
|
|
||
| func TestInitPlugin(t *testing.T) { |
There was a problem hiding this comment.
Small suggestion but personally I prefer BDD style test for readability. Example
There was a problem hiding this comment.
Will move to this on the traffic router plugin branch
|
Kudos, SonarCloud Quality Gate passed!
|
This adds support for a plugin system for metric providers using go-pluing from hashicorp.