https://docs.google.com/document/d/1ID_IhXPpYY4K3G_wa1MYJxOb3yz5FYoOj3ONSkEDsZs/edit?tab=t.0#heading=h.yvv1wy2g0utk

Goal

• As a service provider I the cluster admin to only manipulate fields of the nodeclass API that won't impact the service ability to operate, e.g. userdata and ami can't be changed.
• As a service provider I want to be the solely authoritative source of truth to set input that impacts the ability to operate AutoNode.

Why is this important?

• The way we implement this will have UX implications for cluster admin which has direct impact on customer satisfaction.

Scenarios

We decided to start by using validating admission policies to implement ownership of ec2NodeClass fields. So we can restrict fields crud to a particular service account.
This has some caveats:

• If a field that the service own is required in the API, we need to let the cluster admin to set it on creation even though we'll clobber it by reconciling a controller. To mitigate this we might want to change the upstream CEL validations of the ec2NodeClass API
• The raw userdata is exposed to the cluster admin via ec2NodeClass.spec.userdata
• Since we enforce the values for userdata and ami via controller reconciliation there's potential room for race conditions

If using validating policies for this proves to be satisfactory we'll need to consider alternatives, e.g:

• Having an additional dedicated CRD for openshiftnodeclass that translates into the ec2NodeClass and completely prevent the cluster admin from interacting with the latter via vap.
• having our own class similar to eks so we can fully manage the operational input in the backend.

1. # ...

Acceptance Criteria

• Dev - Has a valid enhancement if necessary
• CI - MUST be running successfully with tests automated
• QE - covered in Polarion test plan and tests implemented
• Release Technical Enablement - Must have TE slides
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions:

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Technical Enablement <link to Feature Enablement Presentation>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Enhancement merged: <link to meaningful PR or GitHub Issue>
• 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>