-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
3
-
False
-
-
False
-
team-loki sprint 230, team-loki sprint 231, team-loki sprint 232, team-loki sprint 233, team-loki sprint 234
-
0
GROOMING CHECKLIST:
You can find out more information about ARO workflow, including roles and responsibilities here. Some items in the list should be left for Team Leads (TL) and Region Leads (RL) to perform. Otherwise, all other fields should be populated.
- Size and Scope - this Epic can be accomplished by a single Functional Team (ideally in under a quarter)
- Component has been set to `ARO`
- Labels have been set appropriately for the type of work (only use one):
- Product Management (customer-driven) work should always include `mcsp-aro` and `Ready4TLGrooming`
- Toil mitigation (SRE-Driven) work should always include `shift-improvement` and `Ready4RLGrooming`
- If the shift-improvement item is appropriate for new team members, add label 'Good-First-Item'
- Links for Parents, Blockers, and/or Dependencies have been set for Epics/Issues, including those that must complete before work on this item can begin
- The below template is complete for User Story, Acceptance Criteria, Customer Experience, and Breadcrumbs
- (TL/RL only) The FixVersion has been set to `SREPYYYYQX` for the expected release period for the Epic
- (TL/RL only) If applicable, set a Target End Date for items that have a promised delivery date
- (TL/RL only) The Priority has been set
- (TL/RL only) When all above items are complete, the `team-X-backlog` and `Ready4FLGrooming` labels have been added, the `Ready4TLGrooming` or `Ready4RLGrooming` label has been removed, and this checklist has been deleted from the Epic
USER STORY:
What are we attempting to achieve? You might need to duplicate this a few times.
[NEEDS CLARIFICATION]
As a customer I want ARO to allow the creation of Hyper-V Gen II instance types (for masters and workers? Is there choice?)
ACCEPTANCE CRITERIA:
What is "done", and how do we measure it? You might need to duplicate this a few times.
[NEEDS CLARIFICATION]
- ARO creates clusters that support Hyper-V Gen II instance types (when selected at install time? by default if supported? can customers force gen 1?)
CUSTOMER EXPERIENCE:
Only fill this out for Product Management / customer-driven work. Otherwise, delete it.
- Does this feature require customer facing documentation? YES/NO
- If yes, provide the link once available
- Does this feature need to be communicated with the customer? YES/NO
-
- How far in advance does the customer need to be notified?
- Ensure PM signoff that communications for enabling this feature are complete
-
- Does this feature require a feature enablement run (i.e. feature flags update) YES/NO
- If YES, what feature flags need to change?
- FLAG1=valueA
- If YES, is it safe to bundle this feature enablement with other feature enablement tasks? YES/NO
- If YES, what feature flags need to change?
BREADCRUMBS:
Where can SREs look for additional information? Mark with "N/A" if these items do not exist yet so Functional Teams know they need to create them.
- ADR: a
- Design Doc: b
- Wiki: c
- Similar Work PRs: d
- Subject Matter Experts: e
- PRD: f
NOTES:
If there's anything else to add.
- ARO currently hard-codes the Hyper-V generation at the image level. RHCOS image SKUs are generated in https://github.com/openshift/ARO-Installer/blob/fd507b37f851684c760e4d5b4fe75040fe3076db/pkg/util/rhcos/rhcos.go#L31 and passed to the install-config.yaml at https://github.com/openshift/ARO-Installer/blob/fd507b37f851684c760e4d5b4fe75040fe3076db/pkg/installer/generateconfig.go#L277
- RHCOS images for aro can be found by running `az vm image list --publisher azureopenshift --all`, for 4.11, you'll see `aro_411` (gen 1) and `411-v2` (gen 2) images. We may need to consider re-publishing RHCOS images to fit an easier-manipulated image name (e.g. so we can just add `-v2` to the end of the gen1 image name)