EPIC Goal

As output from the Feb 5 parking lot, we are opening this spike epic as a 1.11 candidate to serve as a placeholder for pursuing e2e's for our various offerings.

As of the opening of this, the install RHDH is pursuing the migration of e2e from rhdh to the overlays repo (that epic will be linked to this one).

Next, jrichter@redhat.com from QE has an epic opened to pursue lightspeed plugin e2e evaluation ... aside from install validation, there was some discussion during the parking lot about researching how other lightspeed projects do e2e, and what CLI or non-browser based access methods are available.

Jan also has coded up some e2e's for the llamstack template/sample over in https://github.com/redhat-ai-dev/llama-stack-agentic-sample/tree/main/e2e that could sever as a basic guidance.

In taking on additional e2e integration, including with repo's off of our redhat-ai-dev org, I found a fair amount of openshift/release infra for the redhat-developer org

https://github.com/openshift/release/tree/master/core-services/prow/02_config/redhat-developer 

https://github.com/openshift/release/tree/master/clusters/hosted-mgmt/hive/pools/rhdh 

https://github.com/openshift/release/tree/master/ci-operator/config/redhat-developer 

https://github.com/openshift/release/tree/master/ci-operator/jobs/redhat-developer 

https://github.com/openshift/release/tree/master/ci-operator/step-registry/redhat-developer 

If need be we should confirm/pursue use of the rhdh hive pools.

As a fallback, we refrain on e2e at the redhat-ai-dev level and only invoke it via temporary or periodic jobs once things promote to a redhat-developer RHDH repo like the overlays.

I posited, with general consensus, that we should refrain from spinning up new GPU/AI clusters, and either use

• our dev cluster
• advancements on RH internal model availability from IT
• or with stringent control, our budgeted team OpenAI / Gemini licenses