Pagination support for IVS Images page

[rushk014]

Currently we implement client side filtering for the various column filters provided under the Images page. In order to support server side pagination, there are a few roadblocks with respect to the Rancher <PaginatedResourceTable/> component.

1. Based on the new Steve API pagination documentation here, it is unclear how we would implement server-side filtering for the Image name column, which is constructed from the VulnerabilityReport object through a combination of fields:
   ${report.imageMetadata.registryURI}/${report.imageMetadata.repository}:${report.imageMetadata.tag}

   • It may be possible by utilizing chained partial match operators, but based on the definition of the exact field here it seems to me that we would need to inverse behavior where for each of the fields registryURI, repository, tag:
     • Filter Value: docker.io/testRepo/alpine
     • Exact: false. "quay.io/testRepo/alpine:3.4" no, "docker.io/testRepo/other:1.0", no, "docker.io/testRepo/alpine:3.4" yes

   Meaning a partial of the filter value must match at least one of the composite fields, but if there are multiple partials of the filter value that match fields, all must match (so that we don't return quay.io/testRepo/alpine:3.4 when the filter param is docker.io/testRepo/alpine.

2. It is unclear how the Group by repository flag would function under server-side pagination.

• It seems this structure would require 2 levels of pagination (ie. Load the first X repositories, then for each one load the first X images matching that repository field). It may be possible to use sorting to ensure the Steve API returns VulnerabilityReport in an ordered way (by repository field), however it is unclear how the frontend could translate that into a workable UI.

• Consider the case where Table rows per page is set to 50 and there are 100 VulnerabilityReports of which 51 belong to registryA and 49 to registryB. Then we would receive the first 50 records (all belonging to registryA) and render the table as having one row (registryA) with a paginated subtable containing the 50 loaded images. If the user clicks to the next page on the subtable (since there are 51 images associated with registryA), should the UI load the next 50 records (1 belonging to registryA and the rest registryB) and then at that time render a second row within the master table?

• We can also consider the case where there are >50 repositories (each containing >50 images) and likewise run into implementation issues

[richard-cox]

1

Q: we should align the filter in Image with the values in Image name. that might mean some of this is dropped?

spent some time on this, we could think of smart ways to parse the registry/repo/repo:tag string and AND/OR parts together, however we would then also need to do something different for sort (which is possible). at this stage though, if fields are already being manually constructed in the imageMetadata object anyway this one should be added there as well

update: it looks like this might be happening already, see metadata.fields.1 (e.g. ghcr.io/rancher-sandbox/sbombastic/test-assets/golang:1.12-alpine)

2

group by disabled

• server-side paginated list of vulnerabilityreports

group by enabled

Approach 1

• server-side paginated list of vulnerabilityreports sorted by imageMetadata.repository
  • The UI and lists has a group by functionality which could be used here to make things easier
• only a single repository can be expanded at once
• once a repository is expanded it shows a server-side paginated list of vulnerabilityreports filtered on a specific imageMetadata.repository

this won't work, the UI only supports one server-side paginated list of a type at the same time. it can do server-side stuff outside of lists, but not within them.

Approach 2

• work with UX to think of an alternative way to handle this
• we could....
  • drop down showing each repository - we should be able to determine this by getting all registries and finding unique repos
  • on selection show a server-side paginated list of vulnerabilityreports filtered on a specific imageMetadata.repository
  • the condensed vulnerabilities line chart showing results from just that repo would need to be placed outside of the list

Indexed Fields

Important note - anything sorted or filtered on server-side needs to be indexed by rancher. it does some fields automatically though (https://extensions.rancher.io/extensions/next/performance/scaling/lists#choosing-fields-to-display-sort-and-filter-on), specifically CRD additionalPrinterColumns. It looks like some of this is happening already, specifically for vulnerabilityreports

• metadata.fields.0 name
• metadata.fields.1 image (e.g. ghcr.io/rancher-sandbox/sbombastic/test-assets/golang:1.12-alpine)
• metadata.fields.2 platform
• metadata.fields.3 looks like it's the sum of CVEs - 45 (0 suppressed)? given this isn't purely numerical though it wouldn't help for sort (which would be by string).