Epic Goal

• The installer should be able to create Cluster API Machines and resources instead of Machine API Machines and resources
• This will allow us to start switching new clusters to CAPI only
• Allow users to switch between MAPI & CAPI machine manifests in the install config

Why is this important?

• We want to stop installing new Machine API clusters and get users onto the new Cluster API infrastructure
•  

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Installer can create either MAPI or CAPI manifests, based on install config input
• Installer work is looped into the feature gate for MAPI/CAPI transition

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>