Epic Goal

• As we prepare to move over to using Cluster API (CAPI) we need to make sure that we have the providers in place to work with this. This Epic is to track the tech preview of the provider for AWS

Why is this important?

• What are the benefits to the customer, or to us, that make this worth
  doing? Fulfills a critical need for a customer? Improves
  supportability/debuggability? Improves efficiency/performance? This
  section is used to help justify the priority of this item vs other things
  we can do.

Drawbacks

• Reasons we should consider NOT doing this such as: limited audience for
  the feature, feature will be superceded by other work that is planned,
  resulting feature will introduce substantial administrative complexity or
  user confusion, etc.

Scenarios

• Detailed user scenarios that describe who will interact with this
  feature, what they will do with it, and why they want/need to do that thing.

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>