Kubernetes provider module for the Konveyor analyzer #163
Conversation
Signed-off-by: Sam Lucidi <[email protected]>
|
|
||
| ### Test Plan | ||
|
|
||
| Functionality of the provider itself can be tested with a single-node cluster (seeded with known resources) |
There was a problem hiding this comment.
Is there any limitation on the current e2e system that would prevent us from creating a new test for this provider?
|
|
||
| ### Implementation Details | ||
|
|
||
| The Kubernetes provider will use Rego as its rules language, and will use the Open Policy Agent SDK |
There was a problem hiding this comment.
Could possibly mention the use of analyzer-lsp providerConfig and capability to evaluate rules/resources.
There was a problem hiding this comment.
Updated to mention that it will conform to the analyzer-lsp's gRPC provider interface (which would require that).
|
|
||
| The provider will initially surface two rule capabilities: One that is oriented towards ease-of-authorship in exchange for limited expressiveness (`rego.expr`), and one that permits freeform authoring of complex Rego modules (`rego.module`). | ||
| Ideally, the simpler rule format will strike a balance that enables most rules to be written in it. To facilitate the use of the simpler rule capability, | ||
| we will provide a built-in inventory of Rego rules that can be referred to by user-provided rules. |
There was a problem hiding this comment.
@shawn-hurley could this call for a "shim" for rego rules -> our rules? Maybe this isn't worth the trouble if there will only be a limited number of these.
There was a problem hiding this comment.
I thought that @mansam had by hand moved over the ones that were written. I don't know if there are other larger rego projects that we would want to convert.
I wonder if we have examples of those projects, I think it would make sense, I don't know them and don't know if it needed. Do you have any thoughts?
There was a problem hiding this comment.
If it's a small set of rules then I agree, no need. I'm not aware of any others.
Signed-off-by: Sam Lucidi <[email protected]>
|
|
||
| The provider will initially surface two rule capabilities: One that is oriented towards ease-of-authorship in exchange for limited expressiveness (`rego.expr`), and one that permits freeform authoring of complex Rego modules (`rego.module`). | ||
| Ideally, the simpler rule format will strike a balance that enables most rules to be written in it. To facilitate the use of the simpler rule capability, | ||
| we will provide a built-in inventory of Rego rules that can be referred to by user-provided rules. |
There was a problem hiding this comment.
I thought that @mansam had by hand moved over the ones that were written. I don't know if there are other larger rego projects that we would want to convert.
I wonder if we have examples of those projects, I think it would make sense, I don't know them and don't know if it needed. Do you have any thoughts?
|
|
||
| ### Test Plan | ||
|
|
||
| Functionality of the provider itself can be tested with a single-node cluster (seeded with known resources) |
There was a problem hiding this comment.
Is there a world, where we could have a "fake k8s client" that would allow us to run against a set of resources in a directory?
I think that this could be a follow-on especially when we start integrating the rules into the new yaml rule test that @pranavgaikwad is making.
There was a problem hiding this comment.
Yeah, I think we absolutely should look into doing that.
Signed-off-by: Sam Lucidi <[email protected]>
There was a problem hiding this comment.
Question:
Is there a use case for analyzing resources not deployed in a cluster. For example, manifests either user defined or generated in a git repository?
If so perhaps the provider could honor the Location instead of (or in addition) to the kubeconfig and namespaces.
This can be a follow up PR.
Signed-off-by: Sam Lucidi <[email protected]>
Fixes #162