We would like the ability to specify centrally views which are useful across a large number of API requests.

At this point in time we would ideally not be adding any additional manual steps taken for new releases or GA dates. Is it possible to design the views mechanism so it can be independent of release.

Example API request today:

https://sippy.dptools.openshift.org/api/component_readiness?baseEndTime\=2023-10-31T23:59:59Z\&baseRelease\=4.14\&baseStartTime\=2023-10-04T00:00:00Z\&confidence\=95\&excludeArches\=arm64,heterogeneous,ppc64le,s390x\&excludeClouds\=openstack,ibmcloud,libvirt,ovirt,unknown\&excludeVariants\=hypershift,osd,microshift,techpreview,single-node,assisted,compact\&groupBy\=cloud,arch,network\&ignoreDisruption\=true\&ignoreMissing\=false\&minFail\=3\&pity\=5\&sampleEndTime\=2024-02-28T23:59:59Z\&sampleRelease\=4.15\&sampleStartTime\=2024-02-22T00:00:00Z

Imagine a new query parameter "view" = "last_2_weeks_vs_prev_ga_4_weeks".

Ideally sampleRelease is not part of the view but remains a query parameter. This would allow for saved views to be easily re-used across multiple releases and would eliminate the need for manual steps when new branches are cut or GA'd. baseRelease should be calculated by the view relative to sampleRelease and/or latest GA.

Resulting in ?view=last_2_weeks_vs_prev_ga_4_weeks&sampleRelease=4.16

baseRelease 4.14 would be assumed while 4.15 was waiting to GA, and then automatically switch over to baseRelease 4.15 once it GA's. The view remains the same and does not need manual updates.

Other params are encompassed in the view. Perhaps passing any of them explicitly in addition to a view would override the view generated values. (not required initially just an idea)

Internally I would expect go code to generate the query parameters on the fly based on the view and releases specified, not hard coded. I don't think we would ever want to bake in hard coded timestamps into a view.

baseStartTime and baseEndTime should be able to be calculated on the fly in relation to the GA date of the baseRelease, or relative to now. (i.e. compare against 4.14 GA, or compare against 4.15 four weeks ago through two weeks ago.

sampleStartTime and sampleEndTime should be the same but typically would be some duration ago through now.

excludeArches excludeClouds groupBy etc should all be straight forward hard coded in the view.

UI could then show the views list as a dropdown, disabling the custom selections if used.

Sample views could be: default (as today), single-node, multiarch, hypershift. (should these be combined with naming that inidcates the timespam per above?)