Support filtering module for validation checks

[shrutiparabgoogle]

Currently, the filtering module resides in server/registry/internal/storage. This module provides two main functionalities:

• defines what field_names are allowed in filters for specific resources.
• Compiles the filter expression from string to cel.Program

We can use these functionalities to validate the filter expressions defined in various definitions (mainly in Manifests, ScoreDefinitions and ScoreCardDefinitions). Most of these definitions include a pair of pattern and filter, right now we can validate pattern definitions but not filter definitions.

Solution:

1. Refactor and promote the filtering module to the same level as server/registry/names package. We can then use the filtering module in the same way as we are using names package for validating resource patterns.
2. Once step 1 is in place, add validation checks for filter expressions in Manifest, ScoreDefinition and ScoreCardDefinition.

[timburks]

Do we want filtering in rules to include all of the same criteria that we use to filter in the server? Filters passed to list methods can refer to fields in the message, but as implemented in the server, the filters operate on entities from the models package that are internal and specific to our database storage.

I don't think that we want to move that out of internal, or to pkg, which is actually where I think names belongs (we didn't have pkg when names was created).

Instead of implementing it directly in the controller, could filtering instead be done on the server by passing the desired filters through to list methods?

Is this issue only about validating filter expressions and not evaluating them? If so, maybe the internal filtering package could be split into a public part that goes into pkg and only validates expressions with the rest staying in internal.

[shrutiparabgoogle]

The purpose of introducing filter module in the scoring framework is more than just validating the filters.

In a ScoreDefinition, we define the target pattern as follows:

target_resource:
   pattern: "apis/-/versions/-/specs/-"
   filter: "mime_type.contains('opennapi.yaml')"

this means that this particular scoreDefinition can be applied to api specs of type "openAPI".

Now, when we invoke the score command, the input to the score command is a single/collection of specs: compute score projects/demo/locations/global/apis/petstore/versions/1.0.0/specs/openapi.yaml

• The score command will fetch all the resources (in this case specs) supplied through the input
• For each resource it will try to find which ScoreDefinitions can be applied, in order to do that, it will check:
  • if the resource matches the target pattern: apis/-/versions/-/specs/-
  • if the resource matched the target filter: mime_type.contains('openapi.yaml') (We need evaluation at this step)
• Once we have a definition, apply that definition to the supplied resource and compute the score.

As described above we need to evaluate the filter on the supplied resource to decide if a definition can be used to calculate the score for that resource. My assumption till now was that the filters are based on the protos, but because they are based on our internal models, it is creating some confusion in implementation. I want to keep the fields (that can be filtered on) in the API and in this framework identical so that users don't have to learn two separate things.

Validation is just an add on thing that I am doing, while validating ScoreDefinitions, but the critical need is for the use case described above. This is the issue to support filters in Scoring framework (which unfortunately doesn't have great explanation in it).

[timburks]

Can filtering be offloaded to the server by passing filters to the List RPCs? I'm assuming you're getting resources from the server using List calls, so could you include the filter when requesting them?