Labs-led delivery in CY23 -- and impact to infrastructure

[mwalker5000]

Today, @eformat @oybed @mtakane @theisey @mwalker5000 met to discuss the potential future for TL500 infrastructure used for Labs-led runs of TL500. Here's a summary of our discussion and decisions -- feel free to chime in with questions or suggestions.

Should we continue to run Labs-led delivery of TL500 in CY23?
@mwalker5000: Yes

When should Labs lead the delivery, and what is the business goal for doing so?
@mwalker5000: We'll do it for:

1. strategic customers where we believe TL500 is appropriate to advance our relationship to the next step
2. Internal DevOps enablement education for our field (consultants and sellers)

Why couldn't we just use the forthcoming GLS infrastructure to do this today?

• Currently the GLS environment is designed to run a stable build of TL500 that could be up to 12 months old, in order to support stable runs by facilitators worldwide who may not be intimately familiar with the inner workings of the course code content.
• TL500 was originally designed and built to be able to run the latest release on any vanilla OpenShift in publicly accessible environment.
• As a stable release ages, it no longer represents the best practices of Red Hat and our customers.
• Stable releases may also contain bugs that remain unfixed
• The value proposition of our offering is diminished for our specific markets (namely: strategic customers, and internal field teams) when it drifts from what we actually do in the field
• It would be less marketable, and we'd have less ability to use it strategically

So then what are our infrastructure options today?

Current state means we'd remain dependent on:

• LodeStar (to capture engagement data, register users)
• Labs SRE Automation (to provision the environment)
• AWS as targeted public cloud (both other options could be considered)
• Internal SRE team to develop, support and maintain the above items in order to enable the rest of the team to deliver TL500

An alternate/backup approach might be:

• RHPDS, with the caveats:
  It's designed for quick product demos, not long-running training environments at the scale of a TL500 class room
  It would require an extra effort to setup users
  It would require an extra effort to ensure TL500 runs for 2+ weeks consecutively

Summary:

• Labs will continue to lead a subset of TL500 runs next year. They will run them for strategic Labs customers (as determined by Labs managers and team leads), and for internal field enablement (with further details to be determined once field enablement team has prioritized budget etc).
• In order to do this and do it well, Labs will need to maintain their own hosting infrastructure.
• If maintaining hosting infra becomes challenging due to personnel or other constraints, RHPDS is one of our recommended backup solution to explore.

[eformat]

A note on the current state of the nightly Testing that runs fully automated from GitHub.

https://github.com/rht-labs/tech-exercise/actions/workflows/run_tests.yaml

The tests are automated and run through Exercises 1+2 of TL500 from the actual source documentation (the code snippets are executed). This runs on a Single Node OpenShift (spot instance) 4.11 (latest stable) to keep costs low.

This continuous testing helps us catch any early issues in the starting exercises. It could be extended further if there was a desire:

• to other environments (e.g. GLS)
• to other versions of OpenShift
• test more Exercises (3 is a big one)
• to include install of the TL500 enablment infra charts as well (installing all the tools)