Proposal For ADR-255 #4400
Draft
Proposal For ADR-255 #4400
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement support for arbitrary OpenShift version strings during cluster installation, protected by the Microsoft.RedHatOpenShift/ArbitraryVersions AFEC flag. This enables testing and development scenarios with custom builds or pre-release versions. Key changes: * Add FeatureFlagArbitraryVersions constant in pkg/api/featureflags.go * Enhanced validateInstallVersion() to check AFEC flag and allow arbitrary semantic versions when enabled * Updated function signatures to pass subscription documents for feature flag validation * Added comprehensive test coverage for enabled/disabled scenarios * Created documentation in docs/arbitrary-versions-feature.md When the feature flag is enabled, version validation only requires valid semantic versioning format, bypassing the CosmosDB enabled versions list. When disabled, existing validation behavior is preserved for backward compatibility. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
…ages
Complete the arbitrary versions implementation by adding intelligent image
resolution that falls back to Azure Container Registry (ACR) when versions
are not found in CosmosDB.
Key enhancements:
* Enhanced openShiftClusterDocumentVersioner with GetWithSubscription() method
* ACR fallback generates installer images using {ACRDomain}/aro-installer:{major.minor}
* Different OpenShift image resolution for Hive vs traditional installations
* CosmosDB versions always take precedence over ACR fallback
* Comprehensive test coverage for all ACR fallback scenarios
* Updated documentation with image resolution behavior and patterns
Resolution order:
1. Check CosmosDB OpenShiftVersions collection first
2. If not found and FeatureFlagArbitraryVersions enabled, generate ACR image specs
3. Installation proceeds with generated specs; fails if images don't exist in ACR
Example generated images:
- Installer: arosvc.azurecr.io/aro-installer:4.15 (for version 4.15.0-custom.build.123)
- OpenShift (Hive): arosvc.azurecr.io/ocp-release:4.15.0-custom.build.123
- OpenShift (Traditional): quay.io/openshift-release-dev/ocp-release:4.15.0-custom.build.123
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <[email protected]>
- Update _client_factory.py to use new base_url variable name for az CLI API endpoint. - Change item.properties.version in custom.py to item.version to match newer models.
- Removed print statement used for testing.
This change introduces the install_afec_feature flag to enable/disable arbitrary version support during cluster installation. The flag controls validation logic and feature availability while maintaining backward compatibility. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Which issue this PR addresses:
This PR introduces a Proof of Concept to demonstrate how ADR 255 would work. What tests are required for it, and documentation. This code was generated by Claude and should not be merged as is.
What this PR does / why we need it:
Proof of concept.
Test plan for issue:
Local testing and claude added unit and e2e tests.
Is there any documentation that needs to be updated for this PR?
Developer documentation and processes beyond what are in this PR would need to be updated if we choose to go the route of this proof of concept.
How do you know this will function as expected in production?
Can test in Canary, but ultimate if we go this route we approve the test accounts for the AFEC flag and we'll know in short order.