HYPERFLEET-404 - test: add the cluster creation testcase#9
Conversation
WalkthroughAdds end-to-end test documentation at testcases/cluster_lifecycle.md describing two scenarios: (1) creating a GCP OpenShift cluster via the Hyperfleet API with request/response shapes, expected state transitions, adapter status semantics, and validation steps; (2) verifying that adapters provision Kubernetes resources (namespace and pods) inside the cluster namespace and their statuses. Also adds testcases/templates/create_cluster_gcp.json, a JSON template defining a GCP-based cluster spec (metadata, platform, release, networking, and DNS). Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Around line 155-250: The response example under the GET
/api/hyperfleet/v1/clusters "Response example" block is a single Cluster object
but must be a ClusterList; wrap the existing cluster JSON inside a ClusterList
with fields "kind": "ClusterList", "total": 1, "size": 1, "page": 1 and move the
cluster object into an "items" array; update the example JSON in the "Response
example" section so it reflects the ClusterList structure described in the
expectations.
🧹 Nitpick comments (3)
testcases/cluster_lifecycle.md (3)
155-155: Update Step 2 title to reflect the LIST operation.The current title "Verify Cluster API response" is ambiguous. This step tests the LIST endpoint, not a single cluster retrieval. Rename to something like "List all clusters" or "Verify cluster appears in list".
574-574: Hyphenate "Landing zone" for consistency.Use "Landing-zone" instead of "Landing zone" when used as a compound modifier before a noun.
582-582: Specify language for fenced code blocks.Lines 582 and 594 contain code blocks without a language identifier. Add
bashortextto the opening fence:🔧 Example fix for line 582
- ``` + ```bash NAME STATUS AGE 2nmg1slsk2t795jdu1mi1rk2iplgf4k3 Active 5mAlso applies to: 594-594
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
testcases/cluster_lifecycle.md
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~574-~574: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
testcases/cluster_lifecycle.md
582-582: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
594-594: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
testcases/cluster_lifecycle.md (1)
1-598: Overall structure and completeness—LGTM.The test case is well-organized with clear preconditions, sequential steps, and detailed validation criteria. The use of collapsible response examples aids readability. Once the Step 2 response inconsistency is resolved, this will be a solid foundation for automated or manual testing of cluster lifecycle operations.
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
09705a5 to
8e04582
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Line 590: Add language identifiers to the two fenced code blocks missing
specifiers (the blocks showing command output around the cluster/pods examples):
change the opening triple-backtick lines at the blocks referenced (near the
cluster NAME/STATUS table and the Pods verification example) to include a
language specifier such as "output" so they become ```output, leaving the
closing ``` unchanged; ensure both occurrences (the block before the cluster
table and the block before the pods table) are updated.
- Line 582: Change the heading text "Adapter created resources:" to use a
hyphenated compound adjective by replacing it with "Adapter-created resources:"
(or alternatively rephrase to "resources created by adapters") so the compound
adjective follows English hyphenation rules.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
testcases/cluster_lifecycle.md
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~582-~582: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
testcases/cluster_lifecycle.md
590-590: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
602-602: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
testcases/cluster_lifecycle.md (1)
1-606: Comprehensive and well-structured test case document.This test case provides excellent coverage of the cluster lifecycle workflow, including creation, listing, retrieval, adapter status monitoring, and resource verification via kubectl. The document is clear, thorough, and includes realistic examples with explicit validation checks for each step.
The progression from API operations (Steps 1-5) to infrastructure verification (Step 6) is logical and well-organized. Collapsible response examples keep the document readable while providing necessary detail. The validation checklist for each step makes it easy to implement automated or manual test scenarios.
yasun1
left a comment
yasun1
left a comment
There was a problem hiding this comment.
This test case requires time waiting to get resources ready. It makes the case complex and big. I advice to separate them into pieces, etc. basic checking, adapters checking, k8s resources checking, and so on.
Yes.It is very long in markdown.We can separate it.But I am thinking, if we separate it, it will require to preapre cluster every time for every case. I prepare to put cluster API check and adapter status check via API in one case,k8s and other resource checking in a new case.WDYT? |
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
8e04582 to
49cd2ec
Compare
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Around line 136-155: The test currently asserts list pagination totals (e.g.,
total=1,size=1) against the /api/hyperfleet/v1/clusters response which will fail
in shared environments; replace those assertions with a presence check that
filters the returned .items by the cluster identifier or name (use CLUSTER_ID or
CLUSTER_NAME) and assert that a matching .id or .name exists in the items array
(e.g., via jq select(.id == $id) or equivalent), and remove or relax any exact
total/size checks; apply the same change to the other occurrence that checks
pagination (lines 234-255).
- Around line 27-43: The document omits how to obtain the {cluster_id} after
creating the cluster; update the "Create Cluster via API" step to show capturing
and exporting the returned cluster ID (e.g., run the curl request with -s and
parse the JSON response to extract the id) and provide a concrete example
command to export it as an environment variable (for example: response=$(curl -s
-X POST ... -d @testcases/templates/create_cluster_gcp.json); export
CLUSTER_ID=$(echo "$response" | jq -r '.id')). Ensure subsequent steps refer to
${CLUSTER_ID} (or clearly state replacing {cluster_id}) and add the same
guidance to the later occurrences referenced (lines around 256-264).
- Around line 545-618: Preconditions contains a broken fragment link to the
"Create cluster will success via API" header—fix the fragment in the
Preconditions item (the anchor after "see") to exactly match the target header
id/title; also add language qualifiers to the two fenced code blocks by changing
``` to ```text for both example outputs and hyphenate the phrase "Adapter
created resources" to "Adapter-created resources" in the Test Steps/Expected
Result section so lint MD051/MD040 and hyphenation issues are resolved.
In @testcases/templates/create_cluster_gcp.json:
- Around line 3-7: The template currently hard-codes name ("hp-gcp-cluster-1")
and labels.environment ("production"), which can cause collisions and incorrect
semantics; update the template fields (name and labels.environment) to be
clearly placeholder/parameterized values (e.g., a replaceable token or
environment variable reference) and add a brief comment indicating they must be
set per deployment; ensure the placeholder enforces uniqueness (e.g., include a
project/team prefix or timestamp token) and default to a non-production
environment value in documentation or templating logic.
- Around line 19-22: The spec.release.image currently points to the CVO
component image; update spec.release.image to the OpenShift release payload
image (one that contains release-manifests and image-references) instead of the
CVO component, e.g. use a payload tag like
quay.io/openshift-release-dev/ocp-release:4.14.z-x86_64; modify the JSON entry
under "release" (the "image" value) to the proper payload registry/tag so
runtime validation of spec.release.image succeeds.
🧹 Nitpick comments (1)
testcases/cluster_lifecycle.md (1)
360-484: Make adapter assertions tolerant to extra adapters / changing counts.
Hardcoding “at least 2” andtotal=2will get brittle as MVP evolves; better to assert required adapters exist, and ignore extras.Proposed wording/check
-- `total` matches the number of deployed adapters (at least 2 in MVP: landing-zone-adapter and dummy-validation-adapter) -- `size` matches `total` +- `items` contains entries for required adapters (at minimum): `landing-zone-adapter` and `dummy-validation-adapter` +- Additional adapters may appear and should not fail the test +Example check: +```bash +curl -sS "${API_URL}/api/hyperfleet/v1/clusters/${CLUSTER_ID}/statuses" | \ + jq -e ' + (.items | map(.adapter) | index("landing-zone-adapter")) != null and + (.items | map(.adapter) | index("dummy-validation-adapter")) != null + ' >/dev/null +```
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~594-~594: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
testcases/cluster_lifecycle.md
570-570: Link fragments should be valid
(MD051, link-fragments)
602-602: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
614-614: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
testcases/templates/create_cluster_gcp.json (1)
1-18: The template is correct as-is. The official API documentation intestcases/cluster_lifecycle.mdexplicitly shows the Cluster create payload using top-levelnameandlabelsfields, not ametadatawrapper. Both the request payload and response examples confirm this flat structure is the expected schema.Likely an incorrect or invalid review comment.
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
49cd2ec to
126d68b
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Line 573: The anchor link fragment in the list item is incorrect: update the
link text from "#test-title-create-cluster-will-success-via-api" to match the
actual test title fragment "#test-title-create-cluster-will-succeed-via-api" so
the link points to the "Create cluster will succeed via API" heading; locate the
string in the list line and replace "success" with "succeed" to fix the broken
reference.
- Around line 142-143: The curl invocation in the test case mixes the -G flag
with an explicit GET token, which is invalid; either remove the extra literal
GET when using -G so the command becomes curl -G <URL> --data-urlencode
"search=..." or, if you prefer explicit method syntax, replace -G with -X GET
and drop the standalone GET token; update the line that currently starts with
"curl -G GET http://localhost:8000/api/hyperfleet/v1/clusters --data-urlencode
..." accordingly.
🧹 Nitpick comments (5)
testcases/cluster_lifecycle.md (5)
256-357: Add explicit polling/wait guidance for asynchronous cluster processing.The step title mentions "monitor its status," but only a single GET request is documented. Since the cluster processing is asynchronous (adapters update conditions over time), testers need clear guidance on:
- How frequently to poll the cluster status
- What conditions indicate processing is complete
- Maximum wait time before considering the test failed
- Whether to proceed to Step 4 immediately or wait for specific conditions
Consider adding a polling loop example or clarifying the timing expectations.
📋 Example polling guidance
Add to the Action section:
**Action:** 1. Send GET request to retrieve the specific cluster: ```bash # Poll cluster status every 30 seconds until adapters complete processing for i in {1..20}; do curl -X GET ${API_URL}/api/hyperfleet/v1/clusters/{cluster_id} | jq '.status.conditions' sleep 30 doneWait until adapter conditions show
status: "True"before proceeding to Step 4.
Maximum wait time: 10 minutes.</details> --- `461-462`: **Clarify the data type for condition status values.** Line 462 mentions status "is false at the beginning" (lowercase), but the examples throughout show string values like "True". Clarify whether the `status` field is: - A boolean type (`true`/`false`) - A string type (`"True"`/`"False"`) This distinction is important for test automation validation logic. <details> <summary>📝 Suggested clarification</summary> ```diff - - Each condition's `status` field is false at the beginning and will be "True" when that specific condition is satisfied + - Each condition's `status` field is a string that is initially "False" and becomes "True" when that specific condition is satisfied
605-610: Add language specifiers to code blocks.The code blocks at lines 605-610 and 617-620 are missing language specifiers. Adding them improves syntax highlighting and rendering in markdown viewers.
✨ Proposed fix
For lines 605-610:
- ``` + ```text NAME STATUS AGE 2nmg1slsk2t795jdu1mi1rk2iplgf4k3 Active 5m default Active 1d kube-system Active 1dFor lines 617-620: ```diff - ``` + ```text NAME READY STATUS RESTARTS AGE gcp-validator-2nmd7vphnua8m388ve9mp8oevah401up-1-99tqr 0/2 Completed 0 3h58</details> Also applies to: 617-620 --- `548-575`: **Consider the test dependency and organization structure.** The second test case has a precondition dependency on the first test case (line 573), which creates tight coupling. This aligns with the discussion in the PR comments about the test being large and complex. As you noted in the PR discussion, splitting into smaller independent tests requires preparing the cluster for each case. Your proposed compromise (combining API checks into one test, separating Kubernetes resource checks) seems reasonable. However, consider: - **For manual testing**: The current structure works well as a single end-to-end scenario - **For automation**: Independent test cases with proper setup/teardown are more maintainable and can run in parallel - **Hybrid approach**: Keep the comprehensive flow in one file for documentation, but structure it as independent test cases that can optionally skip setup if a cluster already exists The current structure is acceptable for the MVP phase, but documenting the test dependency explicitly (beyond just the precondition) would help future test implementers understand the relationship. --- `578-621`: **Add cleanup steps or clarify cluster lifecycle management.** The test creates a cluster but doesn't document cleanup steps. Consider adding: 1. A final step to delete the cluster after verification: ```bash curl -X DELETE ${API_URL}/api/hyperfleet/v1/clusters/{cluster_id}
- Or explicitly state whether:
- Clusters should be manually cleaned up after testing
- Clusters are automatically cleaned up by the system
- Test clusters persist for troubleshooting purposes
This clarification is especially important for test automation and CI/CD pipelines to prevent resource accumulation.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🚧 Files skipped from review as they are similar to previous changes (1)
- testcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~597-~597: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
testcases/cluster_lifecycle.md
573-573: Link fragments should be valid
(MD051, link-fragments)
605-605: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
617-617: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (2)
testcases/cluster_lifecycle.md (2)
34-133: LGTM! Comprehensive cluster creation test step.The cluster creation step is well-documented with clear request format, detailed payload description, expected response validation, and thorough field-by-field verification criteria.
488-545: LGTM! Clear final state verification.The final state verification step is well-defined with explicit phase transition logic and comprehensive validation criteria. The MVP limitation for phase determination is appropriately documented.
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
126d68b to
e3f3240
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Line 573: The markdown link fragment "Create cluster will success via API" is
misspelled and breaks the anchor; update the link target to match the actual
test title ("Create cluster will succeed via API") or rename the heading to use
"success" consistently so the fragment and the heading match; specifically edit
the link text/fragment that currently says "Create cluster will success via API"
to "Create cluster will succeed via API" so the internal anchor resolves.
- Around line 141-143: Replace the hardcoded host in the curl step so it uses
the same API_URL env var as other steps; update the curl command that currently
targets "http://localhost:8000/api/hyperfleet/v1/clusters" to use
"${API_URL}/api/hyperfleet/v1/clusters" and keep the existing --data-urlencode
"search=name='<cluster_name>'" argument unchanged so the test uses the
configured environment endpoint.
🧹 Nitpick comments (2)
testcases/cluster_lifecycle.md (2)
605-620: Add language specifiers to fenced code blocks.The example output code blocks are missing language specifiers. Consider using
textorplaintextfor shell output examples to satisfy markdown linting rules.Proposed fix
- Example output: - ``` + ```text NAME STATUS AGE 2nmg1slsk2t795jdu1mi1rk2iplgf4k3 Active 5m default Active 1d kube-system Active 1d```diff - Example output: - ``` + ```text NAME READY STATUS RESTARTS AGE gcp-validator-2nmd7vphnua8m388ve9mp8oevah401up-1-99tqr 0/2 Completed 0 3h58</details> --- `548-576`: **Consider the test splitting suggestion from PR comments.** Per the discussion in PR comments, this second test case ("Resources should be created after cluster creation") could potentially be split from the first test case to allow independent execution. The current precondition at line 573 creates a hard dependency on the first test case completing successfully. If you proceed with keeping them together, ensure your test automation framework can handle the sequential dependency. If you split, each test becomes independently executable but would require cluster setup in each case. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Organization UI **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 126d68b8eb27fe81f71d5b2853a54c11075a8ec6 and e3f32408f320859958f3655cccdf44a9592039ac. </details> <details> <summary>📒 Files selected for processing (2)</summary> * `testcases/cluster_lifecycle.md` * `testcases/templates/create_cluster_gcp.json` </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 LanguageTool</summary> <details> <summary>testcases/cluster_lifecycle.md</summary> [grammar] ~597-~597: Use a hyphen to join words. Context: ...} ``` **Expected Result:** - **Adapter created resources:** - **Landing zone ... (QB_NEW_EN_HYPHEN) </details> </details> <details> <summary>🪛 markdownlint-cli2 (0.18.1)</summary> <details> <summary>testcases/cluster_lifecycle.md</summary> 573-573: Link fragments should be valid (MD051, link-fragments) --- 605-605: Fenced code blocks should have a language specified (MD040, fenced-code-language) --- 617-617: Fenced code blocks should have a language specified (MD040, fenced-code-language) </details> </details> </details> <details> <summary>🔇 Additional comments (2)</summary><blockquote> <details> <summary>testcases/templates/create_cluster_gcp.json (1)</summary><blockquote> `1-36`: **LGTM!** The JSON template provides a well-structured GCP cluster configuration for testing purposes. Placeholder values (e.g., `my-gcp-project`, `example.com`) are appropriate for a test template. </blockquote></details> <details> <summary>testcases/cluster_lifecycle.md (1)</summary><blockquote> `1-21`: **Well-structured test documentation.** The test case structure with metadata table, preconditions, detailed steps, and expected results is clear and comprehensive. The use of collapsible sections for JSON examples keeps the document readable. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
e3f3240 to
4091f9b
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Around line 605-610: The fenced code block showing kubectl output is missing a
language specifier; update the triple-backtick fence in the snippet that
contains the table starting with "NAME STATUS AGE" to include a language like
text (i.e., change ``` to ```text) so the block is properly recognized as
plaintext/terminal output in cluster_lifecycle.md.
- Line 573: The internal anchor is broken because the link uses "success" while
the actual heading uses "succeed"; update the anchor in the link labeled "Create
cluster will success via API" to match the heading text (change
"#test-title-create-cluster-will-success-via-api" to
"#test-title-create-cluster-will-succeed-via-api") or alternatively rename the
heading to use "success" so both the heading and the link match.
- Around line 617-620: Add a language specifier to the fenced code block
containing the kubectl output so Markdown renders it as plain text; replace the
opening backticks "```" for the block showing the NAME/READY/STATUS output with
"```text" (or "```plaintext") to mark it as plaintext.
🧹 Nitpick comments (1)
testcases/templates/create_cluster_gcp.json (1)
1-36: Template structure looks good, but consider using test-appropriate label values.The JSON structure is well-formed and aligns with the test documentation. However, using
"environment": "production"in a test template could be misleading or accidentally used in production contexts.Consider using test-oriented values
"labels": { - "environment": "production", + "environment": "test", "team": "platform" },
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~597-~597: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
testcases/cluster_lifecycle.md
573-573: Link fragments should be valid
(MD051, link-fragments)
605-605: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
617-617: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
testcases/cluster_lifecycle.md (1)
1-30: Well-structured test documentation.The test case format is comprehensive with clear preconditions, steps, and expected results. The use of collapsible sections for verbose JSON examples keeps the document readable.
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
4091f9b to
4643829
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Around line 569-574: The Precondition in cluster_lifecycle.md currently
couples Test 2 to Test 1 by requiring a cluster created by the first test
("Create cluster will succeed via API"); make Test 2 independent by either
adding a reusable setup utility or test fixture/hook that creates (and tears
down) a cluster for Test 2, or update the precondition text to state that Test 2
may use any pre-existing cluster (not necessarily from Test 1); also consider
splitting the doc into two independent tests as you proposed—one for cluster API
+ adapter status checks and a separate one for Kubernetes resource checks—so
each can run independently.
🧹 Nitpick comments (2)
testcases/cluster_lifecycle.md (2)
597-597: Optional: Consider hyphenating compound adjective.The phrase "Adapter created resources" could be more grammatically correct as "Adapter-created resources" when used as a compound adjective before a noun.
Based on learnings, static analysis tools.
1-621: Comprehensive test documentation with clear structure.The test cases are well-documented with:
- Clear preconditions and expected results
- Detailed verification criteria for API responses and adapter states
- Good use of collapsible sections for lengthy JSON examples
- Proper tracking of metadata fields and state transitions
Your concern in the PR comments about test length is understandable. The proposed split (API/adapter checks in one case, Kubernetes resource checks in another) would improve maintainability while keeping related validations together.
Would you like me to generate a shell script to automate these test steps? It could help with:
- Sequential API calls with proper cluster ID extraction
- Automated verification of expected response fields
- Kubernetes resource checking
- Polling/waiting for adapter statuses to reach expected states
This would make the test suite more executable and reduce manual effort.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🚧 Files skipped from review as they are similar to previous changes (1)
- testcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~597-~597: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
4643829 to
911376e
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
testcases/cluster_lifecycle.md (3)
32-545: Clarify phase transition timing and add explicit polling guidance.The test steps show cluster.status.phase progressing from "NotReady" (Steps 2-4) to "Ready" (Step 5), but the documentation doesn't explicitly state:
- How long to wait between steps
- Whether to poll repeatedly until conditions are met
- Expected timeframe for phase transitions
The example timestamps suggest gradual progression over several minutes, but testers need explicit guidance on retry logic and timeout values.
📋 Suggested additions
Consider adding explicit polling guidance to Step 3 or Step 5, for example:
Step 3: Retrieve the specific cluster and monitor its status (Poll until adapters are ready)
Add a note like:
**Polling Strategy:** - Poll the cluster status every 10-15 seconds - Wait for all adapter conditions to have status: "True" - Maximum wait time: 5 minutes - If timeout is reached, fail the testAnd in Step 5, clarify:
**Step 5: Verify Cluster Final State (Poll until phase is Ready)** **Polling Strategy:** - Continue polling from Step 3 until status.phase transitions to "Ready" - Expected transition time: 30 seconds to 2 minutes after all adapter conditions are "True" - Maximum wait time: 3 minutes
462-462: Minor: Clarify status field value format.The line states status field is "false" (lowercase) at the beginning, but all JSON examples use "True" (capitalized string). For consistency, consider using "False" (capitalized) or explicitly note whether status values are booleans or strings.
Suggested rewording
- - Each condition's `status` field is false at the beginning and will be "True" when that specific condition is satisfied + - Each condition's `status` field is "False" at the beginning and will be "True" when that specific condition is satisfied (values are strings, not booleans)
599-599: Optional: Consider hyphenating compound adjective.Static analysis suggests "Adapter-created resources" (hyphenated) per standard English conventions for compound adjectives. This is purely a style suggestion and can be safely ignored.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🚧 Files skipped from review as they are similar to previous changes (1)
- testcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~599-~599: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (3)
testcases/cluster_lifecycle.md (3)
535-537: Clarify the phase transition logic.The documented logic states: "All adapters Available: True → Cluster phase: Ready", but the earlier examples (Steps 2-4) show both adapter conditions with status "True" while phase remains "NotReady".
Is there a delay between adapter conditions becoming "True" and the phase transitioning to "Ready"? Or are additional conditions required beyond adapter availability?
Clarifying this will help testers understand when to expect the phase transition and whether it requires a separate reconciliation cycle.
548-623: Well-structured resource verification test with appropriate dependency.Test 2 appropriately depends on Test 1's completion and clearly documents the additional precondition (kubectl access to the deployment cluster). The verification steps are specific and testable.
Note: Per your PR comment about splitting tests, separating the Kubernetes resource checks (Test 2) from the API checks (Test 1) is a reasonable approach since they require different access (API gateway vs kubectl). This separation is already reflected in having two distinct test titles.
1-623: Comprehensive and well-structured test documentation.This test case documentation is thorough and well-organized:
- Clear test metadata and preconditions
- Logical progression through creation, verification, and monitoring steps
- Detailed request/response examples with proper use of collapsible sections
- Specific and testable verification points
- Good use of placeholders ({cluster_id}) for reusability
The level of detail is appropriate for end-to-end cluster lifecycle validation and will serve as valuable documentation for both manual testing and future automation.
|
/lgtm |
|
/hold |
yingzhanredhat
force-pushed
the
ying-e2e
branch
from
911376e to
a776b06
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: xueli181114, yasun1, yufchang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/unhold |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @testcases/cluster_lifecycle.md:
- Around line 619-621: The example output contains a mismatched cluster ID:
replace the pod name string
"gcp-validator-2nmd7vphnua8m388ve9mp8oevah401up-1-99tqr" in the example block
with the consistent cluster ID used elsewhere
"gcp-validator-2nmg1slsk2t795jdu1mi1rk2iplgf4k3-1-99tqr" so the example output
matches other examples in the document.
- Around line 574-577: Clarify the ambiguous "kubectl is configured to access
the deployment Kubernetes cluster" precondition by specifying which cluster to
target and updating the example gcloud command: state whether the cluster is the
Hyperfleet control-plane (the cluster where Hyperfleet runs), a separate test
environment cluster, or the GCP cluster created for tests; replace the generic
gcloud example "gcloud container clusters get-credentials <cluster_name>
--zone=<zone> --project=<gcp_project_id>" with a concrete example such as using
the control-plane cluster name (e.g., hyperfleet-control-plane) and a sample
zone/project (e.g., --zone=us-central1-a --project=my-gcp-project) and add a
short note telling readers to substitute their cluster name/zone/project if they
use a different environment.
🧹 Nitpick comments (5)
testcases/cluster_lifecycle.md (5)
42-42: Clarify working directory for the curl command.The relative path
@testcases/templates/create_cluster_gcp.jsonassumes the command is executed from the repository root. Consider adding a note about the expected working directory or using an absolute path with an environment variable.📝 Suggested clarification
Add a note before the command:
**Action:** Send POST request to create a new GCP cluster using the payload from [templates/create_cluster_gcp.json](templates/create_cluster_gcp.json). > **Note:** Run this command from the repository root directory. ```bash curl -X POST ${API_URL}/api/hyperfleet/v1/clusters \ -H "Content-Type: application/json" \ -d @testcases/templates/create_cluster_gcp.json</details> --- `142-143`: **Use consistent cluster name in the example.** The placeholder `<cluster_name>` should be replaced with the actual cluster name from Step 1 (`hp-gcp-cluster-1`) for consistency with the example responses. <details> <summary>📝 Suggested fix</summary> ```diff -curl -G ${API_URL}/api/hyperfleet/v1/clusters --data-urlencode "search=name='<cluster_name>'" +curl -G ${API_URL}/api/hyperfleet/v1/clusters --data-urlencode "search=name='hp-gcp-cluster-1'"
256-263: Steps 2 and 3 appear redundant.Step 2 retrieves the cluster via list API, and Step 3 retrieves the same cluster via direct GET. The responses are nearly identical, and it's unclear what additional validation Step 3 provides. Consider consolidating these steps or clarifying the distinct purpose of each.
If Step 3 is intended to demonstrate monitoring/polling behavior, consider renaming it to make that explicit, such as "Step 3: Monitor cluster status until adapters complete."
262-262: Inconsistent placeholder syntax.The documentation uses both
<placeholder>style (line 142) and{placeholder}style (lines 262, 366, 494) for variables. Standardize on one format for clarity.Recommendation: Use
{cluster_id}consistently, and add a note at the beginning explaining that curly braces indicate values to be substituted.Also applies to: 366-366, 494-494
548-623: Add cleanup and error handling guidance.The test documentation doesn't include:
- Steps to clean up created resources after testing
- Guidance on what to do if expected resources aren't present
- How long to wait for pod completion
- Troubleshooting steps if pods fail or restart
Consider adding these sections to make the test cases more complete and practical for testers.
Example additions:
- A "Cleanup" section with DELETE API calls
- "Troubleshooting" notes for common failure scenarios
- Wait/timeout recommendations for async operations
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
testcases/cluster_lifecycle.mdtestcases/templates/create_cluster_gcp.json
🚧 Files skipped from review as they are similar to previous changes (1)
- testcases/templates/create_cluster_gcp.json
🧰 Additional context used
🪛 LanguageTool
testcases/cluster_lifecycle.md
[grammar] ~599-~599: Use a hyphen to join words.
Context: ...} ``` Expected Result: - Adapter created resources: - **Landing zone ...
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (3)
testcases/cluster_lifecycle.md (3)
195-222: Clarify the timing for phase transition.The response shows both adapter conditions with
status: "True"but the phase remains "NotReady" (line 221). However, Step 5 later shows the phase as "Ready". The documentation doesn't explain:
- What triggers the phase transition from "NotReady" to "Ready"
- How long testers should wait between checks
- Whether polling is required
This timing ambiguity was also mentioned in the PR comments as a concern about test complexity.
Consider adding guidance on:
- Expected time for phase transition
- Recommended polling interval
- Timeout thresholds
Alternatively, if the phase transition happens immediately after all adapters report success, clarify why the intermediate state shows "NotReady" in Step 2.
535-537: Clarify the phase calculation logic.The explanation states "Real available adapters number == Expected adapter number → Cluster phase: Ready" but doesn't define how the "Expected adapter number" is determined. Is this:
- Hardcoded (e.g., always 2 for MVP)?
- Configured per cluster?
- Discovered from the deployment?
Please clarify the phase transition logic or point to where this is documented in the codebase.
1-623: Consider the test organization feedback from PR comments.The PR author raised concerns about test length and complexity, suggesting splitting into:
- Basic checks + adapter status (via API)
- Kubernetes resource checks (separate case)
This would align with the two test titles already present in the document. Consider formalizing this split by:
- Making Test 1 (lines 4-545) focus purely on API validation
- Making Test 2 (lines 548-623) a truly independent test with its own complete preconditions
- Documenting the relationship/dependencies between tests
This addresses the author's concern about overhead while maintaining clear test boundaries.
The documentation structure is solid for an MVP draft. The two-test organization already reflects the split the author is considering.
openshift-merge-bot
bot
merged commit 1d4656c
into
openshift-hyperfleet:main
4 participants
HYPERFLEET-404 :
Refine the previous e2e scenario and draft cluster creation via testcase format
Summary by CodeRabbit
Tests
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.