---
# System prepended metadata

title: Component readiness data

---

## Thoughts:
- Clicking through the different tabs trying to find the job results layout is cumbersome.  It takes 5 different tabs just to get to that page.
    - Opening a new tab every time you click a link is not ideal.  I think while still within the Component Readiness tool it should update the panel you're looking at in some nested way with historical significance so you can "go back" in some way.
    - Actions from meeting: TRT team to open JIRA to discuss and address this
- I personally think its more valuable to try and identify regressions against the **CURRENT** state of the historical version, given that we have backported bug fixes and such for issues that reflect a new state of the product that should be maintained versus allowing us to consider a "worse than we knew" state of the product at that time.
    - From deads: comparison is against master. So what this comparison does is compares current state of master to 4.13 pre-GA
    - 
- I think adjusting the timing window of comparison is a hindrance more than a boon to the efforts of identifying *active* regressions.
    - In most of the results I'm seeing blocks of time with increased failures, but its not sporadic enough among all the results to help identify anything new in the windows of time.  What I mean is, if you're comparing one week of the current release against 4 weeks of the previous release, the algorithm makes note of a regression.  What happens if you narrow that data to only the latter 2 weeks?  The signal could be more/less clear for the historical version during that period, and reveal the opposite result.  With the sample size being adjustable, the data can be manipulated to show better or worse results reflecting a reality different than the statistical representation.
- Instead of having the option to adjust filters for 1, 2, and 4 week arguments, why not have those buttons simply show those results (cached from single requests of that data), and use the search/filters to adjust your view of the data in those results?
  - Maintaining input fields for specific timing windows and such should still be available, but "easy consume" fields would make sense for fast-viewing by other teams that are simply "monitoring" 99% of the time they use the tool.
- You should also compare between skip versions.
    - Wouldn't regressions be identifiable between 4.14 and 4.12 if the delta between 4.14 and 4.13 is too small but between 4.14 and 4.12 is double that?
- Smart matching of errors across components to the same job with a common underlying issue: For example the failures related to cloud compute [here](https://sippy.dptools.openshift.org/sippy-ng/component_readiness/test_details?arch=amd64&baseEndTime=2023-05-16%2023%3A59%3A59&baseRelease=4.13&baseStartTime=2023-04-18%2000%3A00%3A00&capability=operator-conditions&component=Cloud%20Compute%20%2F%20Other%20Provider&confidence=95&environment=ovn%20no-upgrade%20amd64%20aws%20standard&excludeArches=arm64%2Cheterogeneous%2Cppc64le%2Cs390x&excludeClouds=openstack%2Calibaba%2Cibmcloud%2Clibvirt%2Covirt%2Cunknown&excludeVariants=hypershift%2Cosd%2Cmicroshift%2Ctechpreview%2Csingle-node%2Cassisted%2Ccompact&groupBy=cloud%2Carch%2Cnetwork&ignoreDisruption=true&ignoreMissing=false&minFail=3&network=ovn&pity=5&platform=aws&sampleEndTime=2023-09-10%2023%3A59%3A59&sampleRelease=4.14&sampleStartTime=2023-08-01%2000%3A00%3A00&testId=Operator%20results%3Aff3f4ce2ada4b853ece12306b1ef3eaf&testName=operator%20conditions%20machine-api&upgrade=no-upgrade&variant=standard) and the ones related to [image-registry](https://sippy.dptools.openshift.org/sippy-ng/component_readiness/test_details?arch=amd64&baseEndTime=2023-05-16%2023%3A59%3A59&baseRelease=4.13&baseStartTime=2023-04-18%2000%3A00%3A00&capability=operator-conditions&component=Image%20Registry&confidence=95&environment=ovn%20no-upgrade%20amd64%20aws%20standard&excludeArches=arm64%2Cheterogeneous%2Cppc64le%2Cs390x&excludeClouds=openstack%2Calibaba%2Cibmcloud%2Clibvirt%2Covirt%2Cunknown&excludeVariants=hypershift%2Cosd%2Cmicroshift%2Ctechpreview%2Csingle-node%2Cassisted%2Ccompact&groupBy=cloud%2Carch%2Cnetwork&ignoreDisruption=true&ignoreMissing=false&minFail=3&network=ovn&pity=5&platform=aws&sampleEndTime=2023-09-10%2023%3A59%3A59&sampleRelease=4.14&sampleStartTime=2023-08-01%2000%3A00%3A00&testId=Operator%20results%3Aad47fd0f8db4a5195cee022678627c9b&testName=operator%20conditions%20image-registry&upgrade=no-upgrade&variant=standard) point to the same set of jobs which have failed during installation. Technically it is not completely related to this component and can be classified as "install failures". Is there a way to smartly aggregate or point those out?
    - suggestion from deads: Would it help to have a view to exclude looking at jobs with certain failures through a filter so we don't have duplicate component failures with the same job 
- Can you massage the view a bit to "lock" the column and row headers into the view?  That way scrolling down through components or to the right through configurations won't lose track of what row/column you're looking at.

## Known issues
- https://issues.redhat.com/browse/TRT-1232: inconsistent monitoring view signal

## Investigations
