Epic Goal

• Auto detect microshift vendor/version during a cluster import.

Why is this important?

• microshift could be part of hybrid cloud blueprint
• microshift supports edge scenarios
• from data center to the edge customers want cluster has observability
• microshift is designed for the edge, so there is no monitoring stack
• after auto detect microshift vendor/version, Observability could treat microshift as just *KS to deploy monitoring stack
• https://microshift.io/docs/getting-started/

Scenarios

1. Official product name is "Red Hat Device Edge" and "Red Hat Build of MicroShift". 

"Infrastructure: Red Hat Device Edge"

Control Plane Type: Standalone

Distribution Version: MicroShift X.Y.Z

1. RHEL X.Y is a nice to have but not required (if even available)

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>