Epic Goal

• Avoid the installer to tag an existing AIM User Role that the customer is providing for IPI deployment in AWS.

Why is this important?

• For some customers due to policy restrictions the installer will not be able to tag a Role that already exists and is managed by the user and not the installer. This is preventing some customers to deploy a cluster in AWS using IPI and user provided AIM User Roles.

Scenarios

1. While deploying a cluster in AWS the installer won't add/modify tags on the user provided IAM User Roles

Acceptance Criteria

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

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>