Conversation
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
|
Few more todos before merging.
|
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
Signed-off-by: julianstephen <julian.stephen@gmail.com>
| } | ||
|
|
||
|
|
||
| class NemoCheckv2(Plugin): |
There was a problem hiding this comment.
question: how distinct is the plugin implementation here vs. the external plugin itself https://github.com/kagenti/plugins-adapter/blob/main/plugins/examples/nemocheck/nemocheck/plugin.py ?
I was expecting that we would be able to use similar code but only the packaging (referencing the class path here vs. packaging up as a server for external) would be different?
There was a problem hiding this comment.
We can, but each of the example is a bit independent and cross dependency may not be nice. We can refactor out the call-nemo-check logic outside both, but where do we house it? Will have to make some common-plugin-utils that needs to be an independent module that can be used in in both plugins.
Another option is to simply keep the nemo internal plugin and add some packaging logic for the external one to pull the code from the internal plugin. The external one has a full project structure that can be containerized etc. Or we can simply nix the external one and fix some of the v2 naming in the internal one.
There was a problem hiding this comment.
Another option is to simply keep the nemo internal plugin and add some packaging logic for the external one to pull the code from the internal plugin.
Yes I was thinking along these lines, especially as an example this seems easier to present as "internal first" rather than generally expecting the two separate servers deployed with the external plugin, but we can keep the extra packaging logic as an example, without having the code duplicated. The v2 naming is confusing if there's not fundamental plugin or API changes
side note we can probably move the nemoguardrails requirement out from default requirements afterward https://github.com/kagenti/plugins-adapter/blob/main/requirements.txt
| description: "Adapter for nemo check server" | ||
| version: "0.1.0" | ||
| author: "Julian Stephen" | ||
| config: |
There was a problem hiding this comment.
Should the relevant hooks be present here?
evaline-ju
left a comment
There was a problem hiding this comment.
Based on availability we will merge this as is - I will plan to refactor this separately to unify the nemo check plugins and/or absorb this into my current tool response draft #32
|
Refactor will be tracked in #33 |
Summary
Nemo-check server called as an internal plugin. Fixes #20
Related issue(s)
Related to PR #17
Few more todos:
[] Document how to configure this internal plugin
[] Update primary readme with links to this internal plugin
[] Test failure cases