Skip to content

ROSAENG-62089: doc: Add feature-gated write-mode design doc and update api-management - #154

Open
cdoan1 wants to merge 1 commit into
openshift-online:mainfrom
cdoan1:cdoan/featuregate-update
Open

ROSAENG-62089: doc: Add feature-gated write-mode design doc and update api-management#154
cdoan1 wants to merge 1 commit into
openshift-online:mainfrom
cdoan1:cdoan/featuregate-update

Conversation

@cdoan1

@cdoan1 cdoan1 commented Jul 18, 2026

Copy link
Copy Markdown
Collaborator

Move the feature-gated write-mode design from rosa-hyperfleet PR #678 to this repo alongside the api-management spec it extends. Update api-management.md to reflect gate-aware write-mode overrides in the FieldMeta data model, validation loop, and marker documentation.

Description

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactoring (no functional changes)
  • CI/CD or tooling change

Testing

  • Unit tests pass (make test)
  • Integration tests pass (if applicable)
  • Manual verification completed

Checklist

  • My code follows the project's coding conventions
  • I have updated documentation as needed
  • I have added tests that prove my fix/feature works
  • All new and existing tests pass

Summary by CodeRabbit

  • Documentation
    • Added a design proposal for feature-gated write-mode controls.
    • Documented how feature gates can change field mutability between mutable, immutable, and service-set modes.
    • Clarified runtime validation, gate precedence, examples, migration considerations, and open design questions.

Move the feature-gated write-mode design from rosa-hyperfleet PR #678
to this repo alongside the api-management spec it extends. Update
api-management.md to reflect gate-aware write-mode overrides in the
FieldMeta data model, validation loop, and marker documentation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@openshift-ci

openshift-ci Bot commented Jul 18, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cdoan1

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 18, 2026
@coderabbitai

coderabbitai Bot commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Walkthrough

The API management documentation now defines feature-gate-aware write-mode overrides. A companion design proposal specifies marker syntax, field metadata, runtime effective-mode resolution, examples, migration guidance, trade-offs, and open questions.

Changes

Feature-Gated Write-Mode Control

Layer / File(s) Summary
Marker contract and scope
docs/api/api-management.md, docs/api/feature-gated-write-mode-design.md
Defines FeatureGateAwareWriteMode, its base and gate-specific values, and its independence from visibility gating.
Metadata and runtime enforcement
docs/api/api-management.md, docs/api/feature-gated-write-mode-design.md
Describes FeatureGateWriteMode, GatedWriteModes, registry generation, gate enablement checks, first-match resolution, and write-mode validation.
Examples and adoption details
docs/api/feature-gated-write-mode-design.md
Adds schema examples, migration guidance, trade-offs, open questions, and references.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 10 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Ai-Attribution ⚠️ Warning The PR commits use AI attribution via Co-Authored-By: Claude Opus 4.6, but no Assisted-by or Generated-by Red Hat trailer is present. Replace the AI Co-Authored-By trailer with Red Hat’s Assisted-by or Generated-by trailer format, or remove AI attribution if it wasn’t used.
✅ Passed checks (10 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
No-Weak-Crypto ✅ Passed PASS: The PR is docs-only, and the changed docs contain none of the banned algorithms, custom crypto, or secret/token comparisons.
Container-Privileges ✅ Passed PR only updates docs; the touched files contain no privileged-manifest settings like privileged, hostPID, hostNetwork, hostIPC, SYS_ADMIN, or allowPrivilegeEscalation.
No-Sensitive-Data-In-Logs ✅ Passed PASS: The PR only updates docs; the new/modified examples contain no passwords/tokens/PII or log payloads, and secret-pattern searches returned no hits.
No-Hardcoded-Secrets ✅ Passed Only docs changed; scans found no API keys, tokens, passwords, private keys, embedded-credential URLs, or long base64 literals.
No-Injection-Vectors ✅ Passed Only Markdown docs changed; no SQL/shell/eval/pickle/yaml/os.system/dangerouslySetInnerHTML patterns were present in the modified files.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the new feature-gated write-mode design document and the related API Management update.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 7

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/api/feature-gated-write-mode-design.md`:
- Line 27: Update the “Example 1 — Customer-tier based control” heading to
hyphenate the compound adjective as “customer-tier-based,” preserving the rest
of the heading.
- Line 380: Remove the internal generation prompt comment from the published
design document, leaving the surrounding design content unchanged.
- Around line 153-165: Update featureGateAwareWriteModePattern and the
extraction logic in MarkerScanner.extractMarkers to handle empty featureGate
values consistently with the data model: either reject empty gate names during
marker parsing or explicitly treat them as the default gate when matching at
runtime. Ensure the chosen behavior prevents an empty-gate override from being
silently treated as a normal feature gate.
- Around line 67-73: Resolve the HyperFleetEtcdConfig stage contradiction by
choosing a TechPreview gate or revising the documented Default-customer
behavior, then apply that choice consistently in
docs/api/feature-gated-write-mode-design.md lines 67-73, 240-245, and 260-269:
update the EtcdSpec gate annotation, test matrix, and progressive-rollout
example accordingly.
- Around line 100-114: Standardize the gate-aware write-mode metadata contract
by selecting one canonical FieldMeta field name and representation at
docs/api/feature-gated-write-mode-design.md:100-114, then update every
corresponding JSON example at
docs/api/feature-gated-write-mode-design.md:121-140 and registry/runtime example
at docs/api/api-management.md:217-224 to use it consistently.
- Around line 218-234: Update the validation Request and IsFeatureGateEnabled
flow so enabled feature gates are derived from the customer’s authorized feature
set and entitlement lookup rather than a client-supplied EnabledFeatureGates
field. Keep any request-level snapshot internal, populate it only after
authorization succeeds, and ensure gate checks use that authorized snapshot.
- Around line 180-187: The templateField.GatedWriteModes field must preserve
override order for first-match generation and consistent serialization. Replace
the map type with the ordered slice representation used elsewhere in the design,
and update any related generation or serialization code to consume that ordered
form without changing existing semantics.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift-online/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 7b18051a-6c1c-4825-b816-a5bf351435b4

📥 Commits

Reviewing files that changed from the base of the PR and between 35f68d9 and 7d6868f.

📒 Files selected for processing (2)
  • docs/api/api-management.md
  • docs/api/feature-gated-write-mode-design.md


**Scenario**: A field is **GA** (no `+openshift:enable:FeatureGate` marker) but we want to give specific customers the ability to mutate a field that is otherwise immutable or service-set.

**Example 1 — Customer-tier based control**:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Hyphenate “customer-tier-based.”

This user-facing heading should use the compound adjective form.

🧰 Tools
🪛 LanguageTool

[grammar] ~27-~27: Use a hyphen to join words.
Context: ...ervice-set. Example 1 — Customer-tier based control: - **Standard customers...

(QB_NEW_EN_HYPHEN)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` at line 27, Update the “Example
1 — Customer-tier based control” heading to hyphenate the compound adjective as
“customer-tier-based,” preserving the rest of the heading.

Source: Linters/SAST tools

Comment on lines +67 to +73
// Gated field with different write-modes per feature set
// Default: service-set (platform-managed)
// TechPreview+: mutable (customer-controlled)
// +hyperfleet:write-mode=service-set
// +hyperfleet:validation:FeatureGateAwareWriteMode:featureGate="HyperFleetEtcdConfig",writeMode="mutable"
// +openshift:enable:FeatureGate=HyperFleetEtcdConfig
Etcd *EtcdSpec `json:"etcd,omitempty"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Resolve the HyperFleetEtcdConfig stage contradiction.

The examples and tests require this gate to distinguish Default from TechPreview customers, but docs/api/api-management.md defines it as GA, which makes it available to Default customers.

  • docs/api/feature-gated-write-mode-design.md#L67-L73: use a TechPreview gate or revise the stated Default behavior.
  • docs/api/feature-gated-write-mode-design.md#L240-L245: align the test matrix with the selected gate stage.
  • docs/api/feature-gated-write-mode-design.md#L260-L269: align the progressive-rollout example with the same stage.
📍 Affects 1 file
  • docs/api/feature-gated-write-mode-design.md#L67-L73 (this comment)
  • docs/api/feature-gated-write-mode-design.md#L240-L245
  • docs/api/feature-gated-write-mode-design.md#L260-L269
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` around lines 67 - 73, Resolve
the HyperFleetEtcdConfig stage contradiction by choosing a TechPreview gate or
revising the documented Default-customer behavior, then apply that choice
consistently in docs/api/feature-gated-write-mode-design.md lines 67-73,
240-245, and 260-269: update the EtcdSpec gate annotation, test matrix, and
progressive-rollout example accordingly.

Comment on lines +100 to +114
**Proposed FieldMeta**:

```go
type FieldMeta struct {
FieldPath string
WriteMode WriteMode // Base mode (fallback)
FeatureGate string // Gate required for visibility
Hidden bool
FeatureGateAwareWriteModes []FeatureGateWriteMode `json:"featureGateAwareWriteModes,omitempty"`
}

type FeatureGateWriteMode struct {
FeatureGate string // Gate name; empty string = default (no gates enabled)
WriteMode WriteMode
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Standardize the gate-aware write-mode metadata contract.

The documents use different field names for the same registry data, which can produce incompatible generated metadata and runtime consumers.

  • docs/api/feature-gated-write-mode-design.md#L100-L114: choose the canonical FieldMeta field name and representation.
  • docs/api/feature-gated-write-mode-design.md#L121-L140: update JSON examples to use that canonical name.
  • docs/api/api-management.md#L217-L224: update the registry/runtime example to the same name.
📍 Affects 2 files
  • docs/api/feature-gated-write-mode-design.md#L100-L114 (this comment)
  • docs/api/feature-gated-write-mode-design.md#L121-L140
  • docs/api/api-management.md#L217-L224
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` around lines 100 - 114,
Standardize the gate-aware write-mode metadata contract by selecting one
canonical FieldMeta field name and representation at
docs/api/feature-gated-write-mode-design.md:100-114, then update every
corresponding JSON example at
docs/api/feature-gated-write-mode-design.md:121-140 and registry/runtime example
at docs/api/api-management.md:217-224 to use it consistently.

Comment on lines +153 to +165
var featureGateAwareWriteModePattern = regexp.MustCompile(
`\+hyperfleet:validation:FeatureGateAwareWriteMode:featureGate="([^"]*)",writeMode="(mutable|immutable|service-set)"`,
)

func (s *MarkerScanner) extractMarkers(field *ast.Field, fieldPath string) *FieldMeta {
// ... existing code ...

var gatedModes []FeatureGateWriteMode
for _, match := range featureGateAwareWriteModePattern.FindAllStringSubmatch(comments, -1) {
gatedModes = append(gatedModes, FeatureGateWriteMode{
FeatureGate: match[1],
WriteMode: WriteMode(match[2]),
})

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Define or reject empty featureGate overrides.

The regex accepts featureGate="", while the data model says an empty gate means “default.” The runtime algorithm only checks whether a gate is enabled, so an empty-gate override will not reliably match. Either reject empty gate names or implement explicit fallback semantics.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` around lines 153 - 165, Update
featureGateAwareWriteModePattern and the extraction logic in
MarkerScanner.extractMarkers to handle empty featureGate values consistently
with the data model: either reject empty gate names during marker parsing or
explicitly treat them as the default gate when matching at runtime. Ensure the
chosen behavior prevents an empty-gate override from being silently treated as a
normal feature gate.

Comment on lines +180 to +187
```go
type templateField struct {
FieldPath string
WriteMode string
FeatureGate string
Hidden bool
GatedWriteModes map[string]string
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

rg -n 'GatedWriteModes|FeatureGateAwareWriteModes|map\[string\]string' docs pkg

Repository: openshift-online/rosa-hyperfleet-api

Length of output: 10590


Keep the overrides ordered. GatedWriteModes map[string]string breaks the first-match semantics used elsewhere in this design because map iteration is unordered; use an ordered slice here too so generation and serialization stay consistent.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` around lines 180 - 187, The
templateField.GatedWriteModes field must preserve override order for first-match
generation and consistent serialization. Replace the map type with the ordered
slice representation used elsewhere in the design, and update any related
generation or serialization code to consume that ordered form without changing
existing semantics.

Comment on lines +218 to +234
The validation Request needs a new method:

```go
type Request struct {
// ... existing fields ...
EnabledFeatureGates []string
}

func (r *Request) IsFeatureGateEnabled(gateName string) bool {
for _, gate := range r.EnabledFeatureGates {
if gate == gateName {
return true
}
}
return false
}
```

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== feature-gated-write-mode-design.md (relevant ranges) ==\n'
wc -l docs/api/feature-gated-write-mode-design.md
sed -n '200,250p' docs/api/feature-gated-write-mode-design.md
printf '\n---\n'
sed -n '350,385p' docs/api/feature-gated-write-mode-design.md

printf '\n== api-management.md (relevant search) ==\n'
rg -n "feature gate|entitlement|authorization context|customer’s feature set|feature set|gates" docs/api/api-management.md
printf '\n---\n'
sed -n '1,260p' docs/api/api-management.md

Repository: openshift-online/rosa-hyperfleet-api

Length of output: 18173


Derive feature gates from authorization context, not request data.
EnabledFeatureGates should come from the customer’s feature set and entitlement lookup, not from a client-supplied request field. Keep any request snapshot internal and populate it only after authorization.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` around lines 218 - 234, Update
the validation Request and IsFeatureGateEnabled flow so enabled feature gates
are derived from the customer’s authorized feature set and entitlement lookup
rather than a client-supplied EnabledFeatureGates field. Keep any request-level
snapshot internal, populate it only after authorization succeeds, and ensure
gate checks use that authorized snapshot.


---

<!-- Generation prompt: review rosa-hyperfleet#678, adapt for rosa-hyperfleet-api docs/api/, cross-reference api-management.md, apply style rules (tables for structured field lists, ASCII art for digraphs, bullet points in tables, relative paths from docs/). -->

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Remove the generation prompt from the published design document.

This is an internal review artifact rather than product documentation.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/api/feature-gated-write-mode-design.md` at line 380, Remove the internal
generation prompt comment from the published design document, leaving the
surrounding design content unchanged.

@cdoan1 cdoan1 changed the title Add feature-gated write-mode design doc and update api-management ROSAENG-62089: doc: Add feature-gated write-mode design doc and update api-management Jul 31, 2026
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 31, 2026
@openshift-ci-robot

openshift-ci-robot commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

@cdoan1: This pull request references ROSAENG-62089 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Move the feature-gated write-mode design from rosa-hyperfleet PR #678 to this repo alongside the api-management spec it extends. Update api-management.md to reflect gate-aware write-mode overrides in the FieldMeta data model, validation loop, and marker documentation.

Description

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactoring (no functional changes)
  • CI/CD or tooling change

Testing

  • Unit tests pass (make test)
  • Integration tests pass (if applicable)
  • Manual verification completed

Checklist

  • My code follows the project's coding conventions
  • I have updated documentation as needed
  • I have added tests that prove my fix/feature works
  • All new and existing tests pass

Summary by CodeRabbit

  • Documentation
  • Added a design proposal for feature-gated write-mode controls.
  • Documented how feature gates can change field mutability between mutable, immutable, and service-set modes.
  • Clarified runtime validation, gate precedence, examples, migration considerations, and open design questions.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants