Story (Required)

As a consumer of RHDH trying to implement the use of RHDH profiles for my Operator my install methods, I want to be able to implement an RHDH profile for my already existing deployments.
 

Background (Required)

• Investigate how the RHDH profiles work when there is an existing Operator deployment/existing Backstage deployments already present on a cluster.
• When speaking with Gennady he mentioned the need to redeploy your Kube objects (resources) so they can reconcile
• This investigation should yield insight into how exactly (if you even can do this), you can implement the profiles into an already existing operator/backstage deployment scenario.
  • If this is not possible at this time we should clearly indicate to users of the installer that it must be done fresh
• Updates by mvaldron
• Diverting investigation to focus primarily on the orchestration profile (helm chart) to avoid potentially needing to create our own bundle to use under OCP console
• It is unclear what has been included as part of the orchestrator profile / flavour work done by the RHDH Install Methods team
  • Some parts of the RHDH helm chart install method are suspected to be part of the orchestrator profile / flavour but are not confirmed
• We see its possible to use one CLI management tool for both flavours / profiles if we decide to use one or both, it would be desired to confirm from the profile / flavour side if this is correct

Out of scope

This issue should only concern the investigation work around the orchestrator profile / flavour and should not include:

• Investigation work regarding the CLI tool, should be left for the other spikes under the parent epic
• Investigation work regarding the operator flavour / profile that is unrelated to the orchestrator profile / flavour
  • If we decide to stay with using the RHDH operator for installs we will follow up with another spike for this profile

Approach (Required)

1. We'll need to reach out to the RHDH Install Methods team members who worked on the orchestrator flavour of RHDH profile to clarify some open questions we have on this approach to determine the work and whether this would be the path we use for the AI RHDH installer overhaul
   • What parts of their repositories are included as part of the orchestrator work?
   • Can we use this install method to perform deployment updates or does this also need redeployment as with the operator flavour?
2. Using the information from previous discussions, investigation work done, and the conversation(s) with the RHDH Install Methods team we'll need to determine how we can setup the profile and helm charts, preferring a design that allows multiple profile flavours with the same CLI management tool
   • Also, need to consider incorporating the gitops repositories, namely the rolling demo gitops, for installing the resources

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

Acceptance Criteria (Required)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

documentation updates (design docs, release notes etc)
demo needed
SOP required
education module update (Filled by RHDHPAI team only)
R&D label required (Filled by RHDHPAI team only)

Done Checklist

Code is completed, reviewed, documented and checked in
Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
Continuous Delivery pipeline(s) is able to proceed with new code included
Customer facing documentation, API docs, design docs etc. are produced/updated, reviewed and published
Acceptance criteria are met
If the Grafana dashboard is updated, ensure the corresponding SOP is updated as well