Hive Impact Assessment

Based on the installer changes, this is a new knob in the install-config – so transparently supported by hive for day 0.
It appears not to be related to MachineSets (at least not directly – see below) so there should be no need to change the MachinePool API for day 2.

Optional: The ancestor cards talk about OCM validating that this field is set (to a certain value?) when certain kinds of machines are in play: namely for Local and Wavelength Zones. So there's the question of whether hive should do similarly:

• Day 0: Introspect install-config (and possibly generated MachineSets). If Edge/Wavelength machines are in play, ensure the MTU field is set (to some value?)
• Day 2: If a MachinePool is created that requests Edge/Wavelength machines, discover the MTU (from where?) and reject the MP if the MTU is not set (to some value?)

In general, hive tries to stay out of the business of doing this kind of validation. We don't like duplicating upstream logic that is subject to change without notice. (E.g. if we're validating some MTU range, and AWS adds support for a broader range, we'll be over-validating until we can get a code fix published. E.g. if installer adds another compute type that this applies to, we would be under-validating until we add recognition of that new compute type. Etc etc.)

So I'm going to make the judgment call that we should not implement any of this validation. However, we should ensure that, if the user does manage to make... whatever mistake this is, the error experience is scrutable.

Also of note is that hive does not yet have support for

• Local Zones: HIVE-2253
• Wavelength Zones: HIVE-2372

I shall be adding those as blocker links here.

TL;DR

This epic should comprise only a QE effort to:

• Test that using this configuration correctly via hive works as expected.
• Test that using this configuration incorrectly via hive results in some relatively sane error state.

OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

• Add support to the Installer to specify a custom MTU for the cluster network

Why is this important?

• …

Scenarios

1. ...

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>