Multi-language support for analysis #165
Conversation
Signed-off-by: Emily McMullan <[email protected]>
| emptyDir: {} | ||
| ``` | ||
|
|
||
| If a user wishes to run a community provider, or override a supported provider, they must provide a yaml with the container definition. This can be passed in from a new flag such as `--unsupported-provider`. This configuration will then be added to the podman pod spec during kantra's runtime. |
There was a problem hiding this comment.
is there a way we could just take image, and port and not an entire container spec?
There was a problem hiding this comment.
I wonder if we start with image and port, with the note that we could eventually need to add support for more stuff because you may need to mount something, or Env Var and maybe even a specific start command?
There was a problem hiding this comment.
We can do this and continue to let kantra deal with the volume mounts.
There was a problem hiding this comment.
If conforming provider images were obligated to accept an environment variable for a port to bind to (something like ENTRYPOINT provider --port ${PORT}), then Kantra could just decide a port and further reduce the amount of stuff that needed to be provided by the user.
| ### Default Rulesets for Supported Providers | ||
|
|
||
| As of now, we have a set of default rules for the Java provider: https://github.com/konveyor/rulesets/ | ||
| We will want to add more default rulesets for each provider, such as `rulesets/golang` and `rulesets/java`. For delivery of these rulesets, they will be packaged in a known location in each providers' Dockerfile. In kantra, this/these path(s) will be set to `--rules`, unless this default behavior is disabled by the user. |
There was a problem hiding this comment.
I feel like we shouldn't be seggregating rules by provider, but I think that's a different discussion
There was a problem hiding this comment.
I can make this section less definitive then, and add the thought to 'open questions'.
| to Linux operating system. | ||
| ``` | ||
|
|
||
| These multi-use rulesets can be found in `rulesets/common` and can use labels such as `konveyor.io/provider=go` and `konveyor.io/provider=java` to filter the common rules for relevant providers. For each running provider, their individual rulesets can be evaluated, as well as searching in `rulesets/common` for any rules with these provider labels. |
There was a problem hiding this comment.
IMO, instead of seggregating by directories, we should just use labels to indicate which providers a certain rule applies to
There was a problem hiding this comment.
I think the point is, that they are rules, that are specifically developed to be common and should live in a place where java ruleset author can rely on. If that makes sense?
There was a problem hiding this comment.
@pranavgaikwad @shawn-hurley is this something we want to decide here? Or leave it generic for now, and resolve later?
Signed-off-by: Emily McMullan <[email protected]>
| emptyDir: {} | ||
| ``` | ||
|
|
||
| If a user wishes to run a community provider, or override a supported provider, they must provide a yaml with the container definition. This can be passed in from a new flag such as `--unsupported-provider`. This configuration will then be added to the podman pod spec during kantra's runtime. |
There was a problem hiding this comment.
If conforming provider images were obligated to accept an environment variable for a port to bind to (something like ENTRYPOINT provider --port ${PORT}), then Kantra could just decide a port and further reduce the amount of stuff that needed to be provided by the user.
| ### Default Rulesets for Supported Providers | ||
|
|
||
| As of now, we have a set of default rules for the Java provider: https://github.com/konveyor/rulesets/ | ||
| We will want to add more default rulesets for each provider. For delivery of these rulesets, they will be packaged in a known location in each providers' Dockerfile. In kantra, this/these path(s) will be set to `--rules`, unless this default behavior is disabled by the user. |
There was a problem hiding this comment.
Should the concept of default rules be part of the provider contract? Provider writers could build the default rules into the image and have the provider load them without Kantra or any other caller needing to know where they are in the image. This would help reduce the distinction between supported and community providers since we wouldn't have to do any special-case setup of built-in rules for providers we know about, and built-in rules would automatically work for ones we don't. (We could still have a flag in the init config to turn off the default rules if we felt that was necessary.)
There was a problem hiding this comment.
I'm not sure if they should be part of the provider contract, as I think we may want the distinction between providers we support and community providers. It could be possible for someone to write their own provider with a set of custom rules that we wouldn't want as default rules.
There was a problem hiding this comment.
I think we are missing the mapping of the languages to providers as @mansam points out. I think it has to solve a couple of problems
- It needs to solve the default mapping ("Java" -> Java-provider, "yaml" -> yaml-provider, xml....).
- It needs to be overridable
- It needs to be ok, to turn off a provider for a language, (I have Yaml code but I don't want the yaml provider to be used)
- It needs to be able to ignore known unknown languages (JavaScript is an example right now).
I think it can be a whole new section
Signed-off-by: Emily McMullan <[email protected]>
| } | ||
| ``` | ||
|
|
||
| If a provider mapping is not found, kantra will look for `--unsupported-provider`. |
There was a problem hiding this comment.
I think that for now this will work, in the future we will want to:
- Enable this to be some config file for the user to set once and leave it, so they don't have to do this every time
- Once they do that, enable a "strict" option, that will fail the command if providers are not found.
I think that we can do this as a follow on, but I do worry about the UX of this without those quality of life enhancements.
|
LGTM |
Signed-off-by: Emily McMullan <[email protected]>
No description provided.