✨ application insights

[pranavgaikwad]

No description provided.

[shawn-hurley]

What about chaining and these rules? do we have any sort of validation or rules around this?

[rromannissen]

I'm not sure about Insights not having a Category. I can imagine some rules author wanting to categorize insights in the same fashion that tags are classified into tag categories. For example, imagine that someone is writing rules that identify architecture components from the different layers of an application. It could make sense to allow that rules author to create categories such as "Frontend" or "Persistence" to organize the different insights. @agoncal @kthatipally please let me know your thoughts on this.

[pranavgaikwad]

@rromannissen those are still categories on tags, but not on incidents that get created. Does it make sense? But note that tag categories are not the same as issue categories

[rromannissen]

What about adding tag metadata in the incident section of the analysis output instead of using the category field? That would be information that the Hub could use to categorize insights so users are allowed to filter them.

[shawn-hurley]

Would the rule labels suffice for the filtration? We may need some mechanism to save this information in the hub, I am not aware if the labels are there are not, but it does feel like labeling the rules with "Frontend" and/or "Persistence" would also make sense in that case.

[rromannissen]

Since insights would be mostly derived from rules that use the tag action, I think it makes sense to have a way to associate tags with the insights they produce. That would be a more straightforward UX than what I was thinking about with reusing the Category field. Users would go into the Insights view and filter insights based on tags, which is already a familiar concept for them. I'm not sure about modeling this with anything else, as we could have potential mismatches between tags and labels/categories, and that would feel odd from a UX perspective.

[pranavgaikwad]

@rromannissen I feel like category field should not be re-used. We can add the labels containing the original tags on the incident and then in the UI, look at these labels and provide a filtering option. We can also show the value of the label in the table view.

[rromannissen]

I agree with the category field not being reused, I feel like tags are the natural way to classify insights. How tag metadata is surfaced in incidents (labels, a special field) is irrelevant as long as the Hub can use that to allow the classification of issues. If you think labels are the most convenient way to do this, I'm perfectly ok with that as long as @jortel is!

[kthatipally]

Love the write-up. I agree with @rromannissen that categorizing insights is beneficial for providing customers with a holistic view. However, I'm of the opinion that our existing tag categories (e.g., caching, backend) are generic for the application and cannot trace back to the actual rules in the existing implementation. I love the idea of incorporating labels instead, as they offer a way for customers to filter insights and can essentially serve the same purpose as tags.

[pranavgaikwad]

What about chaining and these rules? do we have any sort of validation or rules around this?

@shawn-hurley chaining will work as usual. I don't think I understand your concern

[shawn-hurley]

Just want to know if it was supported and if we could make sure that this is added to the enhancement. I assumed it should, but wanted to ask.

[rromannissen]

I'm not sure about insights that don't generate a tag. Looks more like a way to accommodate existing rules that match this pattern than a good way to establish a convention of what an insight should be. If that's the case, we can always identify the existing rules that fall into this second category and figure out a way to add tags, or if they don't make sense, have them removed.

[shawn-hurley]

- customVariables: []
  description: RESTful Web Services @Context annotation has been deprecated
  effort: 0
  message: Future versions of this API will no longer support `@Context` and related
    types such as `ContextResolver`.
  ruleID: jakarta-ws-rs-00001
  when:
    java.referenced:
      location: ANNOTATION
      pattern: jakarta.ws.rs.core.Context

What tag would make sense for this rule? or is this not an insight?

I am asking to understand what the impact of the proposal made would have on a concrete rule example, just to better understand.

[pranavgaikwad]

If we do remove this requirement for an insight, I think we should mandate a non-zero effort value on incidents.

[rromannissen]

@shawn-hurley I would add something like a generic Deprecated API tag to that rule, so the user is able to filter and find all deprecated APIs in a given application. If we want, we can add an additional more fine grained tag like Jakarta JAX-RS Deprecated API. That could be a convention we adhere to in curated rules that come out of the box with Konveyor, but there would be no way to enforce it with custom rules development. The tag itself being applied to applications in the portfolio would also be useful to identify the ones that might require some actions in the future.

[rromannissen]

@pranavgaikwad regarding non-zero effort value on incidents, I agree with you. Insights shouldn't have effort at all, and incidents related to a violation should always have some magnitude or they wouldn't be issues at all. Nevertheless, I'd be careful with the definition of what an insight is. It should be Rules that use the tag action to generate tags and have no effort and category associated to them, since it could make sense to have rules that generate violations and also tag an application at the same time.

[pranavgaikwad]

@rromannissen @shawn-hurley I updated this section to make it clear what happens in each scenario based on what a rule defines.

@rromannissen I changed the definition of an insight rule from "tagging rules and some other rules that have this condition" TO "any rule with 0 / nil effort value". I think this definition makes sense because it gives users a way to choose whether they want to create a message in the insight in addition to the tag....addressing @kthatipally concern below

[kthatipally]

@pranavgaikwad , Regarding the tagging rules,
The existing tagging rules definition specifies that rules only include 'tag' as actions without additional tag metadata like messages or incidents. e,g (https://github.com/konveyor/analyzer-lsp/blob/005a232243a9682f2bd1f0dd18379b0c1494bc8b/rule-example.yaml#L88 ). Given the proposed implementation for generating insights and compatibility with existing rules, insights would likely be generated with empty messages and incidents for those rules. This isn't particularly helpful. Should we consider adding metadata (messages) to these tagging rules to enhance their utility?

[kthatipally]

@pranavgaikwad , Are you referring to the repetitive incidents that occur when multiple tags are present in the rule? Eg: https://github.com/konveyor/rulesets/blob/d930baf2645d6a7ef9486c4f81bc40d8abc3a6af/default/generated/eap6/81-seam-ui.windup.yaml#L22

[pranavgaikwad]

Not specifically when there are more than one tags, but yeah..this is a good example. There aer instances where you could see this with single tags too.

[shawn-hurley]

LGTM