Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add ADR for architectural decision that diverge from CAPI contracts #99

Merged
merged 1 commit into from
Mar 26, 2025

Conversation

rccrdpccl
Copy link
Contributor

@rccrdpccl rccrdpccl commented Mar 17, 2025

Document architectural decisions that move away from CAPI contracts.

Summary by CodeRabbit

  • Documentation
    • Added a new section titled "ADRs" in the README.md file, providing structured references to architectural decision records related to distribution versions and upgrades.
    • Introduced two new documents detailing decisions on handling discrepancies between CAPI contracts and OpenShift's versioning, as well as managing upgrades in OpenShift environments.

@openshift-ci openshift-ci bot requested review from CrystalChun and eranco74 March 17, 2025 12:05
Copy link

coderabbitai bot commented Mar 17, 2025

Walkthrough

This pull request updates the project documentation by adding a new section titled "ADRs" in the README.md file. This section includes links to two newly created Architectural Decision Records (ADRs). The first ADR discusses the introduction of a custom distributionVersion field to handle discrepancies between Cluster API (CAPI) contracts and OpenShift's versioning. The second ADR focuses on utilizing the distributionVersion field for managing upgrades within OpenShift environments.

Changes

File(s) Change Summary
README.md Added an "ADRs" section with links to two new ADR documents: [001-distribution-version](docs/adr/001-distribution-version.md) and [002-distribution-version-upgrades](docs/adr/002-distribution-version-upgrades.md).
docs/adr/001-distribution-version.md
docs/adr/002-distribution-version-upgrades.md
Added new ADR documents detailing decisions on using the distributionVersion field to address CAPI contract discrepancies and to manage cluster upgrades.

Suggested labels

size/XS

Suggested reviewers

  • adriengentil
  • carbonin

Poem

I'm a little rabbit, hopping through the docs so bright,
Found new ADRs that make my day feel light.
Two documents now guide our version tale,
Helping clusters upgrade without fail.
With whiskers twitching, I celebrate this change in style!
Hip-hip, hop-hop—documentation done with a smile!


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@openshift-ci openshift-ci bot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Mar 17, 2025
@rccrdpccl
Copy link
Contributor Author

cc @jianzzha

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (4)
README.md (1)

245-248: Improve Markdown List Styling
The newly added ADR section uses dashes (-) for unordered list items, but markdownlint expects asterisks (*) for consistency. Consider updating the list markers for uniformity. For example:

- - [001-distribution-version](docs/adr/001-distribution-version.md)
- - [002-distribution-version-upgrades](docs/adr/002-distribution-version-upgrades.md)
+ * [001-distribution-version](docs/adr/001-distribution-version.md)
+ * [002-distribution-version-upgrades](docs/adr/002-distribution-version-upgrades.md)
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)

246-246: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)


247-247: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

docs/adr/001-distribution-version.md (1)

1-22: Clear and Comprehensive ADR Document
This ADR effectively explains the discrepancy between CAPI contracts and OpenShift versioning, and details the rationale for introducing the distributionVersion field. To further enhance documentation, consider a brief note on long-term strategies for upstream alignment.

docs/adr/002-distribution-version-upgrades.md (2)

9-9: Language Improvement: Use "cannot" Instead of "can not"
For improved clarity and to adhere to common usage, please replace "can not" with "cannot". For example:

- However, OpenShift versions can not be mapped directly to kubernetes versions.
+ However, OpenShift versions cannot be mapped directly to kubernetes versions.
🧰 Tools
🪛 LanguageTool

[style] ~9-~9: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...es version. However, OpenShift versions can not be mapped directly to kubernetes versio...

(CAN_NOT_PREMIUM)


29-31: Enhance Bullet Point Clarity with a Determiner
The bullet point currently reads:

- Diverges from the standard CAPI upgrade contract.

Consider revising it to include a determiner for grammatical clarity. For example:

- Diverges from the standard CAPI upgrade contract.
+ It diverges from the standard CAPI upgrade contract.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0c59463 and c948a59.

📒 Files selected for processing (3)
  • README.md (1 hunks)
  • docs/adr/001-distribution-version.md (1 hunks)
  • docs/adr/002-distribution-version-upgrades.md (1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
README.md

246-246: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)


247-247: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

🪛 LanguageTool
docs/adr/002-distribution-version-upgrades.md

[style] ~9-~9: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...es version. However, OpenShift versions can not be mapped directly to kubernetes versio...

(CAN_NOT_PREMIUM)


[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

🔇 Additional comments (1)
docs/adr/002-distribution-version-upgrades.md (1)

1-34: Thorough ADR Document on Upgrade Management
This ADR provides a detailed explanation of the challenges in mapping OpenShift versions to Kubernetes versions and conveys the necessity for a centralized upgrade process. Overall, it’s well-structured and informative regarding both the current approach and future upstream discussions.

🧰 Tools
🪛 LanguageTool

[style] ~9-~9: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...es version. However, OpenShift versions can not be mapped directly to kubernetes versio...

(CAN_NOT_PREMIUM)


[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
README.md (1)

246-247: Markdown List Style
The markdown linter (MD004) recommends using asterisks for unordered list items rather than dashes. Consider updating the list markers to asterisks for consistency with the expected style.

- [001-distribution-version](docs/adr/001-distribution-version.md)
- [002-distribution-version-upgrades](docs/adr/002-distribution-version-upgrades.md)
+ * [001-distribution-version](docs/adr/001-distribution-version.md)
+ * [002-distribution-version-upgrades](docs/adr/002-distribution-version-upgrades.md)
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)

246-246: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)


247-247: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

docs/adr/002-distribution-version-upgrades.md (2)

9-9: Language Consistency
There is a minor language suggestion for improved readability. Replace "can not" with "cannot" to maintain consistency and common usage.

- However, OpenShift versions can not be mapped directly to kubernetes versions.
+ However, OpenShift versions cannot be mapped directly to kubernetes versions.
🧰 Tools
🪛 LanguageTool

[style] ~9-~9: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...es version. However, OpenShift versions can not be mapped directly to kubernetes versio...

(CAN_NOT_PREMIUM)


31-31: Grammar Improvement
In this bullet point, consider inserting a determiner for clarity. For example, revising the sentence to start with "The risk of inconsistency..." can make the statement more complete.

- Risk of inconsistency if upstream changes are not accepted or if future changes conflict with our approach.
+ The risk of inconsistency if upstream changes are not accepted or if future changes conflict with our approach.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c948a59 and 99b229a.

📒 Files selected for processing (3)
  • README.md (1 hunks)
  • docs/adr/001-distribution-version.md (1 hunks)
  • docs/adr/002-distribution-version-upgrades.md (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • docs/adr/001-distribution-version.md
🧰 Additional context used
🪛 LanguageTool
docs/adr/002-distribution-version-upgrades.md

[style] ~9-~9: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...es version. However, OpenShift versions can not be mapped directly to kubernetes versio...

(CAN_NOT_PREMIUM)


[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

🪛 markdownlint-cli2 (0.17.2)
README.md

246-246: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)


247-247: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

🔇 Additional comments (3)
README.md (1)

245-248: New ADR Section Added
The addition of the "ADRs" section with links to the two new ADR documents clearly supports the PR objective of documenting architectural decisions diverging from CAPI contracts. The section is well placed and integrates naturally into the overall documentation.

🧰 Tools
🪛 markdownlint-cli2 (0.17.2)

246-246: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)


247-247: Unordered list style
Expected: asterisk; Actual: dash

(MD004, ul-style)

docs/adr/002-distribution-version-upgrades.md (2)

1-8: Clear and Comprehensive ADR Document
The ADR document effectively explains the rationale behind using the distributionVersion field to drive upgrades and addresses the challenges posed by the differences between OpenShift and standard CAPI versioning. The context, decision, and consequences are outlined in a structured manner that aligns well with the PR objectives.


32-33: Overall ADR Consequences
The "Consequences" section clearly identifies the risks and trade-offs of the current approach. This level of detail will be valuable during upstream discussions and for future reference.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (6)
docs/adr/001-distribution-version.md (3)

7-11: Typo Correction in Context

On line 9, the text starts with “luster API (CAPI)” instead of “Cluster API (CAPI)”. Please update the typo for clarity.

- luster API (CAPI) contracts rely heavily on the kubernetesVersion field ...
+ Cluster API (CAPI) contracts rely heavily on the kubernetesVersion field ...

19-21: Punctuation Enhancement in Consequences

In the first consequence (line 19), consider inserting a comma after “CAPI contract” for improved readability. For example:

- - This approach diverges from the CAPI contract but is necessary to support OpenShift versioning.
+ - This approach diverges from the CAPI contract, but is necessary to support OpenShift versioning.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~19-~19: Possible missing comma found.
Context: ...approach diverges from the CAPI contract but is necessary to support OpenShift versi...

(AI_HYDRA_LEO_MISSING_COMMA)


22-22: File Termination

Ensure the file ends with a newline (if not already) for consistency with POSIX standards.

docs/adr/002-distribution-version-upgrades.md (3)

17-17: Minor Punctuation Suggestion

On line 17, "This is effectively an in-place upgrade" could optionally end with a period for consistency. This is a stylistic choice.


28-31: Determiner Addition for Improved Readability

On line 31, the sentence begins with “- Current approach forces distributionVersion changes on the ControlPlane resource...”. Consider adding a determiner to read “forces the distributionVersion changes…” for improved grammar:

- - Current approach forces `distributionVersion` changes on the ControlPlane resource to represent the whole cluster’s version, which is not ideal.
+ - Current approach forces the `distributionVersion` changes on the ControlPlane resource to represent the whole cluster’s version, which is not ideal.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)


33-34: File Termination

Ensure the file ends with a newline (if not already) for standard compliance.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 99b229a and 2fdac78.

📒 Files selected for processing (3)
  • README.md (1 hunks)
  • docs/adr/001-distribution-version.md (1 hunks)
  • docs/adr/002-distribution-version-upgrades.md (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • README.md
🧰 Additional context used
🪛 LanguageTool
docs/adr/002-distribution-version-upgrades.md

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

docs/adr/001-distribution-version.md

[uncategorized] ~19-~19: Possible missing comma found.
Context: ...approach diverges from the CAPI contract but is necessary to support OpenShift versi...

(AI_HYDRA_LEO_MISSING_COMMA)

🔇 Additional comments (3)
docs/adr/001-distribution-version.md (1)

1-2: Title and Introduction Clarity

The title and header are clear and descriptive. No changes needed here.

docs/adr/002-distribution-version-upgrades.md (2)

1-2: ADR Title Clarity

The title clearly indicates the purpose of the ADR. No modifications are needed.


7-15: Context Section Review

The context is well explained. The rationale behind why OpenShift versioning cannot be directly mapped to kubernetesVersion is clearly articulated. No changes are needed.


## Context

luster API (CAPI) contracts rely heavily on the kubernetesVersion field to define Kubernetes versioning and manage upgrades. However, when dealing with OpenShift, there is no direct one-to-one mapping between the kubernetesVersion and OpenShift’s versioning scheme. Because of this, we had to introduce a custom field named `distributionVersion`.

Choose a reason for hiding this comment

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

"Cluster"

Copy link

@jianzzha jianzzha left a comment

Choose a reason for hiding this comment

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

It looks good to me in general

Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
docs/adr/002-distribution-version-upgrades.md (3)

3-7: Status Section Evaluation
The "Status" section simply marking the ADR as "Proposed" works, although adding a date or version identifier could improve traceability for future revisions.


7-20: Context Section Clarity
The context is well-explained, addressing the challenges in mapping OpenShift to Kubernetes versions and outlining why a centralized, unified approach is necessary. For consistency and increased clarity, consider capitalizing “Kubernetes” throughout the text.


28-33: Consequences Section – Grammar and Clarity Adjustment
The consequences are well-articulated, highlighting important trade-offs. However, on line 31, a determiner appears to be missing. Consider revising the sentence for clarity as follows:

- Current approach forces `distributionVersion` changes on the ControlPlane resource to represent the whole cluster’s version, which is not ideal.
+ Current approach forces the `distributionVersion` field on the ControlPlane resource to represent the entire cluster’s version, which is not ideal.
🧰 Tools
🪛 LanguageTool

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2fdac78 and a75a950.

📒 Files selected for processing (3)
  • README.md (1 hunks)
  • docs/adr/001-distribution-version.md (1 hunks)
  • docs/adr/002-distribution-version-upgrades.md (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • README.md
  • docs/adr/001-distribution-version.md
🧰 Additional context used
🪛 LanguageTool
docs/adr/002-distribution-version-upgrades.md

[uncategorized] ~31-~31: A determiner appears to be missing. Consider inserting it.
Context: ...m the standard CAPI upgrade contract. - Current approach forces distributionVersion c...

(AI_EN_LECTOR_MISSING_DETERMINER)

🔇 Additional comments (2)
docs/adr/002-distribution-version-upgrades.md (2)

1-1: Review Title Accuracy
The ADR title is clear and descriptive, immediately conveying the focus on using distributionVersion to drive upgrades.


21-27: Decision Section Appropriateness
The decision section clearly lists the proposed approaches and the rationale behind them. The bullet points are concise and relevant, effectively summarizing the path forward.

Copy link
Collaborator

@CrystalChun CrystalChun left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 26, 2025
Copy link

openshift-ci bot commented Mar 26, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CrystalChun, rccrdpccl

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

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [CrystalChun,rccrdpccl]

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

@openshift-merge-bot openshift-merge-bot bot merged commit acd2465 into openshift-assisted:master Mar 26, 2025
6 checks passed
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. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants