There are some aspects of hosting that are still being figured out. Like, what do we need to perform a useful env for development? testing on PRs (e2e)? QE like unstable envs for destructive actions? More?

To that extent, we need to think on what are the parts we need to control and what we might be able to reuse between use-cases.

Acceptance Criteria

• When we were given direction on how DevSandbox worked, we were told the hosted instance would not run in mini kube. We never inquired why, we should now to see if these are bendable points or not – Talk to Alexey & the DevSandbox folks to understand what that infra looks like
• Investigate / think on what are the parts of the hosted instance world, and what we need for each part / what we can reuse (see the details section)

Details

There are several "types" of instances we are looking at (see the document for more information on desires)

• Staging Env
  • Frontend: Hosted somewhere; long living URL, talks to static hosted backend
  • Backend: Static backend, stable / non-changing configuration or destructive actions take place (ie no operators removed / added to test)
• PR Env
  • Frontend: Cypress (or IQE?) tested env, runs against a unstable backend but one that is spun up for use-cases
  • Backend: Short-lived, unstable, to be used to test flows – should mirror Staging backend from an operator point of view
• QE Env
  • Frontend: Needed? TBD, maybe on demand?
  • Backend: Spun up in various states, very unstable, used to try to find break points in UI and in usage
• Developer Env
  • Frontend: Local for Plugin, hosted usage of a HAC-Core instance
  • Backend: THE Staging env? Do we need anything else? What's the risks? (would likely need a Prod SSO token service if we use Staging)