PRD: Configuration wizard for cluster and VM resources - #57
Conversation
Assisted-by: Claude Code <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughA new PRD document is added defining a five-step configuration wizard (Catalog → Access → Configuration → Networking → Review) for ComputeInstance and Cluster resources. It specifies static wizard fields, catalog ChangesConfiguration Wizard PRD
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 10 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (10 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Assisted-by: Claude Code <noreply@anthropic.com>
![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
🤖 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 `@enhancements/configuration-wizard-OSAC-1421/prd.md`:
- Around line 25-79: The Review step requirements (FR-11 and FR-12) create a
contradiction with the Basics step requirements (FR-5 through FR-7). FR-11 and
FR-12 state that Review displays only entries from field_definitions, but Basics
fields (metadata.name, SSH key, and pull secret when applicable) are collected
in step 2 and are not part of field_definitions — they are hardcoded wizard
fields. This means users cannot review the values they entered in Basics before
submitting. Update FR-11 to clarify that the Review step must display both the
Basics fields collected in step 2 (per FR-5, FR-6, and FR-7) and all entries
from field_definitions, so users can confirm all their inputs before submission.
Ensure FR-12 is understood to apply only to field_definitions entries, not to
the fixed Basics fields.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: b64dfe07-dd2f-4b56-be4e-ff8352aecea6
📒 Files selected for processing (1)
enhancements/configuration-wizard-OSAC-1421/prd.md
…item Assisted-by: Claude Code <noreply@anthropic.com>
Assisted-by: Claude Code <noreply@anthropic.com>
|
@coderabbitai help |
ChatThere are 3 ways to chat with CodeRabbit:
CodeRabbit commands
Other keywords and placeholders
Status, support, documentation and community
|
| #### Basics (step 2) | ||
|
|
||
| - **FR-5:** Step 2 (Basics) must always collect `metadata.name`. | ||
| - **FR-6:** Step 2 must collect SSH credentials per resource type: cluster — `spec.ssh_public_key`; VM — `spec.ssh_key`. |
There was a problem hiding this comment.
Unrelated to the PRD: @ygalblum let's align VMs to ssh_public_key
There was a problem hiding this comment.
same for BareMetalInstance
There was a problem hiding this comment.
Let's finalize the PRD for VM and cluster, we will have a separate one for baremetal
| The following are explicitly out of scope and **will not be supported**: | ||
|
|
||
| - Dynamic Template parameters | ||
| - Fetching select or list options from separate fulfillment list APIs (`virtual_networks`, `subnets`, etc.) when not defined in the catalog item's `field_definitions` |
There was a problem hiding this comment.
This is fine for now but sounds really useful for a future version
There was a problem hiding this comment.
not sure why this is a non goal. We should give the user the ability to choose a virtual_network, subnet and security_groups.
There was a problem hiding this comment.
OK I'll change the PRD to include this, we need the API for each of these fields
|
|
||
| ## 6. Open Questions | ||
|
|
||
| ### 6.1 How should required fields be specified? |
There was a problem hiding this comment.
I think adding "required" to the schema makes sense - please be in touch with whoever is responsible for it on the backend
Co-authored-by: Avishay Traeger <avishayt@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
enhancements/configuration-wizard-OSAC-1421/prd.md (2)
102-115:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSection 6.1 is an implementation-blocking open question — elevate resolution priority.
The required-field semantics question is correctly identified as open with assigned ownership (API / catalog authoring). However, its resolution is a critical blocker for implementation start:
- Security/data-quality risk: If this is unresolved at code-review time, the wizard will either silently accept incomplete Configuration fields (data integrity risk) or impose validation logic that contradicts the actual FieldDefinition schema (correctness bug).
- Current state: Three options are presented (implicit required, schema constraints only, explicit flag), but none is chosen. The wizard implementation cannot proceed without knowing which rule applies.
High severity — functional correctness; implementation blocker. Recommend:
- Document which option is chosen (lines 112 needs a decision, not a question).
- Ensure API ownership completes the FieldDefinition schema change (if option 3 is selected) before the wizard code review.
- Add an acceptance criterion that validates the chosen validation behavior end-to-end.
🤖 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 `@enhancements/configuration-wizard-OSAC-1421/prd.md` around lines 102 - 115, Section 6.1 currently presents three unresolved options for how required fields should be handled in the wizard, which blocks implementation. Replace the open question at the end of the section (the "Still open:" paragraph) with a clear decision on which approach will be used: either (1) treat all shown Configuration fields as required by default, (2) rely solely on per-value schema constraints like minLength to enforce non-emptiness, or (3) add an explicit required flag to the FieldDefinition API. Document the chosen option explicitly, ensure any needed API/schema changes are captured in the ownership section with clear dependencies, and add an acceptance criterion that specifies how the chosen validation behavior will be tested end-to-end to prevent silent acceptance of incomplete fields or validation contradictions.
56-57:⚠️ Potential issue | 🟠 Major | ⚡ Quick winClarify default value handling for non-editable fields.
FR-9 states that non-editable fields' defaults "must be included silently in the create payload" (line 56), and FR-16 requires "default values for all non-editable
field_definitions" (line 73). However, FR-9 does not specify what happens if a non-editable field has nodefaultvalue defined. This creates a data-integrity risk: the payload construction logic could fail or silently omit fields if defaults are missing.Medium severity — data integrity before create. If a catalog item defines a non-editable field without a default, the wizard cannot safely construct the create request.
Recommend clarifying:
- Are non-editable fields required to have a
defaultvalue in the catalog item'sfield_definitions?- If not, what should the wizard do (skip the field, use empty string, reject the catalog item, etc.)?
🤖 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 `@enhancements/configuration-wizard-OSAC-1421/prd.md` around lines 56 - 57, The PRD contains an ambiguity regarding non-editable fields without default values: FR-9 and FR-16 require that non-editable field defaults be included in the create payload, but neither requirement explicitly states whether a non-editable field is allowed to lack a default value or what the expected behavior should be in such cases. Update the PRD to clarify two critical points: (1) state whether non-editable fields are required to have a default value defined in the catalog item's field_definitions, and (2) if not required, specify the exact behavior the wizard must implement (such as skipping the field, rejecting the catalog item, or using a fallback value). This clarification should be added near FR-9 or as a new functional requirement to eliminate the data-integrity risk described in the review comment.
🤖 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 `@enhancements/configuration-wizard-OSAC-1421/prd.md`:
- Line 85: The acceptance criterion at line 85 in prd.md incorrectly lists
"submit" as a separate step when describing the wizard flow, conflicting with
the flowchart (lines 32-38) and FR-2 requirement (line 42) which clearly show
four steps with submit as an action triggered from the Review step, not a step
itself. At line 85, reword the criterion to clearly state the four steps are
"catalog selection → Basics → Configuration → Review" and clarify that submit is
an action performed from the Review step. Apply the same clarification to line
42 in FR-2 to ensure consistency across the document.
---
Outside diff comments:
In `@enhancements/configuration-wizard-OSAC-1421/prd.md`:
- Around line 102-115: Section 6.1 currently presents three unresolved options
for how required fields should be handled in the wizard, which blocks
implementation. Replace the open question at the end of the section (the "Still
open:" paragraph) with a clear decision on which approach will be used: either
(1) treat all shown Configuration fields as required by default, (2) rely solely
on per-value schema constraints like minLength to enforce non-emptiness, or (3)
add an explicit required flag to the FieldDefinition API. Document the chosen
option explicitly, ensure any needed API/schema changes are captured in the
ownership section with clear dependencies, and add an acceptance criterion that
specifies how the chosen validation behavior will be tested end-to-end to
prevent silent acceptance of incomplete fields or validation contradictions.
- Around line 56-57: The PRD contains an ambiguity regarding non-editable fields
without default values: FR-9 and FR-16 require that non-editable field defaults
be included in the create payload, but neither requirement explicitly states
whether a non-editable field is allowed to lack a default value or what the
expected behavior should be in such cases. Update the PRD to clarify two
critical points: (1) state whether non-editable fields are required to have a
default value defined in the catalog item's field_definitions, and (2) if not
required, specify the exact behavior the wizard must implement (such as skipping
the field, rejecting the catalog item, or using a fallback value). This
clarification should be added near FR-9 or as a new functional requirement to
eliminate the data-integrity risk described in the review comment.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 0b04c7c5-9881-4b49-b803-dc377ce6812c
📒 Files selected for processing (1)
enhancements/configuration-wizard-OSAC-1421/prd.md
|
@coderabbitai autofix |
|
This command requires write access to the repository. Only users with write or admin permissions can trigger CodeRabbit to commit or create pull requests. |
|
Should this PRD cover BaaS as well? |
| ### 2.1 Goals | ||
|
|
||
| - Tenant users provision VMs and clusters by selecting a catalog offering, completing a short guided wizard, and submitting — without seeing the full resource spec. | ||
| - All configurable fields and select options are driven by the selected catalog item's `field_definitions`; the wizard adds no resource-specific form fields beyond the fixed Basics step. |
There was a problem hiding this comment.
The fields should be derived from both the ComputeInstance spec (what called here "basic") and the template parameter fields defined in the catalog item.
For fields that come from the ComputeInstance spec, the corresponding catalog item field, when defined, can provide:
- A default value
- Whether the field is editable
- A validation pattern
If no matching field definition exists in the catalog item, the ComputeInstance "basic" spec field should still be displayed and should remain editable.
There was a problem hiding this comment.
@AlonaKaplan Regarding the UI implementation: we should avoid exposing all API fields directly to the user. Some fields are intended for internal use only. For instance, instead of showing network_attachments in its raw format, we should provide a more intuitive workflow - such as selecting a virtual network, subnet, security group, and IP - to keep the user experience clean and manageable.
There was a problem hiding this comment.
I agree with @AlonaKaplan and @danmanor here. The wizard should derive fields from multiple sources, not just field_definitions:
- Resource spec — core fields like
cores,memory_gib,ssh_key,network_attachments(per resource type, as @danmanor suggested) - Catalog item
field_definitions— overrides for editability, defaults, andvalidation_schema - Template parameters — the catalog item has a
templatereference, and the UI can callTemplates.Getto fetch the template'sParameterDefinitionarray, which already carriesrequired,type, anddefaultfor each Ansible/AAP parameter
This also addresses the open question in §6.1 about required-field semantics — the template parameter definitions already have a required flag, so the wizard doesn't need to invent its own mechanism. Where a field_definition exists for a given path, it provides additional constraints (editability, validation_schema, display_name); where it doesn't, the resource spec field should still be shown and remain editable (as @AlonaKaplan noted).
The PRD should be updated to reflect this three-source model instead of the current pure field_definitions-driven approach.
| The following are explicitly out of scope and **will not be supported**: | ||
|
|
||
| - Dynamic Template parameters | ||
| - Fetching select or list options from separate fulfillment list APIs (`virtual_networks`, `subnets`, etc.) when not defined in the catalog item's `field_definitions` |
There was a problem hiding this comment.
not sure why this is a non goal. We should give the user the ability to choose a virtual_network, subnet and security_groups.
|
|
||
| - **FR-5:** Step 2 (Basics) must always collect `metadata.name`. | ||
| - **FR-6:** Step 2 must collect SSH credentials per resource type: cluster — `spec.ssh_public_key`; VM — `spec.ssh_key`. | ||
| - **FR-7:** Step 2 must collect `spec.pull_secret` for cluster catalog items; pull secret must be omitted for VM catalog items where not applicable. |
|
|
||
| #### Configuration (step 3) | ||
|
|
||
| - **FR-8:** Step 3 must render every **editable** entry in the selected catalog item's `field_definitions` array in array order, excluding fields already collected in Basics (`metadata.name`, SSH key, pull secret when shown). |
There was a problem hiding this comment.
IMO the basic list should contain more fields/all ComputeInstance required fields - cores, memoryGiB , bootDisk, image , runStrategy , networkAttachments. @ygalblum @avishayt wdyt? Currently the template hard code most of those values.
@danmanor why networkAttachments is not defined as required in ComputeInstance?
There was a problem hiding this comment.
I think each type - (computeInstance, BaremetalInstance, cluster) should have a set of fields that are rendered in the UI regardless of the catalog item, and also there should be few fields that are shared across all types (name, network, etc.)
There was a problem hiding this comment.
@danmanor why networkAttachments is not defined as required in ComputeInstance?
@AlonaKaplan Where do you mean ? in the catalog item ? API ?
| #### Configuration (step 3) | ||
|
|
||
| - **FR-8:** Step 3 must render every **editable** entry in the selected catalog item's `field_definitions` array in array order, excluding fields already collected in Basics (`metadata.name`, SSH key, pull secret when shown). | ||
| - **FR-9:** Step 3 must not render **non-editable** `field_definitions`; their `default` values must be included silently in the create payload. |
There was a problem hiding this comment.
Where the tenant user ill have a chance to see those values?
|
|
||
| #### Review (step 4) | ||
|
|
||
| - **FR-11:** Step 4 (Review) must always display the Basics fields collected in step 2 with the values the user entered: `metadata.name`, SSH key (`spec.ssh_public_key` for cluster; `spec.ssh_key` for VM), and `spec.pull_secret` for cluster catalog items (pull secret omitted for VM when not applicable). |
There was a problem hiding this comment.
I"m not sure I understand, when a pull_secret should be omitted?
| #### Field rendering | ||
|
|
||
| - **FR-14:** For each editable field in Configuration, the wizard must derive the input widget from the field's `validation_schema` (JSON Schema draft 2020-12): `type: integer` → number input; `enum` present → select; all other types → plain text input. | ||
| - **FR-15:** Select and list options for every select field must come from the `enum` values in that field's `validation_schema` within `field_definitions`. The wizard must not call separate fulfillment list APIs to populate options. |
There was a problem hiding this comment.
That's not accurate for the networkAttachments fields. A separate API will need to be invoked to determine the options.
|
|
||
| - **FR-8:** Step 3 must render every **editable** entry in the selected catalog item's `field_definitions` array in array order, excluding fields already collected in Basics (`metadata.name`, SSH key, pull secret when shown). | ||
| - **FR-9:** Step 3 must not render **non-editable** `field_definitions`; their `default` values must be included silently in the create payload. | ||
| - **FR-10:** The Configuration step must include only fields defined in the selected catalog item's `field_definitions`. |
|
@danmanor @avishayt @AlonaKaplan In addition, please provide for each select field the API to use to fetch the dropdown options. Let's leave out of this PRD the following 2 features:
|
Replace catalog-driven field discovery with a fixed per-resource-type field set. Catalog field_definitions override display, editability, defaults, required, and validation for matching paths. Add ComputeInstance networking pickers (virtual network, subnet, security groups) and resolve required-field semantics. Template parameters and BareMetal remain out of scope. Assisted-by: Claude Code <noreply@anthropic.com>
…view Assisted-by: Claude Code <noreply@anthropic.com>
Streamline wizard requirements, document VM networking list APIs, read-only catalog overlay fields, field defaults, and shortened open-decision section for requiredness and additional disks. Assisted-by: Claude Code <noreply@anthropic.com>
Assisted-by: Claude Code <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@enhancements/configuration-wizard-OSAC-1421/prd.md`:
- Around line 115-140: When the virtual network selection changes, reset and
clear the currently selected subnet and security group values before loading the
new filtered subnet and security group lists. This ensures that stale subnet or
security group selections cannot persist and produce invalid network_attachments
in the payload. Update the load order documentation to clarify that virtual
network selection triggers a clear of dependent subnet/security group
selections, followed by loading the filtered lists and auto-selecting when
exactly one item is available.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: a60977e8-d84f-40df-ac2c-fbbe6dc0cb88
📒 Files selected for processing (1)
enhancements/configuration-wizard-OSAC-1421/prd.md
|
@avishayt @AlonaKaplan @danmanor @ygalblum |
| | Label | `display_name` or wizard default | Wizard default | | ||
| | Editable | `editable: false` → read-only on wizard step (requires `default`; see [§3.2](#32-wizard-behavior)) | `true` | | ||
| | Default | Catalog `default` if set; else blank | Blank | | ||
| | Validation | `validation_schema` | API/wizard validation | |
There was a problem hiding this comment.
Will it also affect the options the user is shown? Not sure I have an example here. But, let's say a field is an enum of 3 values but the validation allows only for 2 of them. Will the user be able to pick the third value (which will lead to failure on submit)?
There was a problem hiding this comment.
If the validation_schema contains an enum with three values, we will show the 3 values, if in addition there's a regex that contradict those enum values, that's a defective schema and I'm not sure the UI needs to handle that
Regarding the network attachement fields - I'm not sure what we want to do if the field_definitions contain validation schemas for subnet and security groups because the UI takes the dropdown values from the API. I think for 0.1 we can accept this as a gap
There was a problem hiding this comment.
Example - release image can have an enum defined with three different release images user can choose from
There was a problem hiding this comment.
If the validation_schema contains an enum with three values, we will show the 3 values, if in addition there's a regex that contradict those enum values, that's a defective schema and I'm not sure the UI needs to handle that
That's not what I meant. So, I'll try to clarify with an example.
Let's say the field in the API itself is an ENUM with 3 options. Just for example let's call it color and the enum is red, green, blue. But, the validation scheme is an enum of red and green. That is the user can choose between red and green, but they cannot chose blue. Will the UI show blue in the drop-down menu and show an error upon selection, or not show it at all? I would hope for the latter.
As for the network attachement fields, there will be additional fields with similar behaviour - in v1 that's InstanceType, in the future also ComputeImage
There was a problem hiding this comment.
yes that is one of the open questions
I'm not sure what is the correct approach, we should just choose something simple and see later
The most simple solution is to ignore the catalogitem field_definitions for the backend driven dropdowns and disable defining these in the catalogitem API
This approach will make the catalogitem pretty meaningless, because there'll be barely anything else to configure... Which brings up the question of the catalogitem usecase
There was a problem hiding this comment.
make the catalogitem pretty meaningless
Not at all. First, keep in mind that we're talking about whether the UI is going to validate the input or not. The backend will have to validate the value against the validation schema. The reason, the UI may chose not to, is thae fact that the backend has to run the validation because the UI is not the only way to call the API. Second, the UI, even in this stage, will still get the default values whether the fields are editable.
Move the PRD to cluster-and-vm-provisioning-wizard, add YAML frontmatter, renumber sections from §1, adopt Access/Configuration steps with image on Configuration, and ignore catalog field_definitions for network_attachments. Assisted-by: Claude Code <noreply@anthropic.com>
Add VM instance type picker and OS family fields, open decisions for catalog overlay and cluster node_sets, Review mirroring wizard fields, Access step exempt from field_definitions, and validate-on-Next step navigation. Assisted-by: Claude Code <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Assisted-by: Claude Code <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@enhancements/cluster-and-vm-provisioning-wizard/prd.md`:
- Line 219: Remove the trailing whitespace (space character) that appears at the
end of the line containing "Resolve before implementation." in the prd.md file.
Locate the text "Resolve before implementation." and ensure there are no spaces
after the period at the end of that line.
- Around line 109-110: The "Instance type (VM)" row in the markdown table on
line 109 contains an extra empty cell marker at the end, creating an unintended
third column when the table only has two columns. Remove the trailing pipe and
spaces after the description text in the "Instance type (VM)" row to align with
the 2-column structure, making it consistent with the "Networking pickers" row
below it which has the correct format.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 26da277d-f2f1-4474-a914-024a0cfd2a71
📒 Files selected for processing (1)
enhancements/cluster-and-vm-provisioning-wizard/prd.md
Assisted-by: Claude Code <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
@ygalblum |
Assisted-by: Claude Code <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
| | Step | Path | Label | Widget | Required | | ||
| | --------------- | ------------------------- | ---------------------------------------- | -------------------------------------- | -------- | | ||
| | Access | `metadata.name` | Name | Text | Required | | ||
| | Access | `spec.ssh_key` | SSH public key | Text (multiline) | ? | | ||
| | Configuration | `spec.image.source_ref` | VM image (OCI reference) | Text | Required | | ||
| | Configuration | `spec.is_windows` | OS family | Radio (`Linux`, `Windows`) | Required | | ||
| | Configuration | `spec.instance_type` | Instance type | Picker ([§2.1.5](#215-vm-instance-type-picker-api)) | Required | | ||
| | Configuration | `spec.user_data` | User data (cloud-init / Ignition) | Text (multiline) | Optional | | ||
| | Configuration | `spec.boot_disk.size_gib` | Boot disk size (GiB) | Number | ? | | ||
| | Configuration | `spec.run_strategy` | Run strategy | Select (`Always`, `Halted`) | Required | | ||
| | Networking | `spec.network_attachments` | Virtual network, subnet, security groups | Pickers ([§2.1.4](#214-vm-networking-picker-apis)) | Required | |
There was a problem hiding this comment.
I dont think first step should be called Access and specifying resource name should be part of it.
All (?) resources that we will be creating, will require a name - should the first step then be called something like General info ? (We use that in Flight Control).
We should allow adding labels in this step too.
Maybe like this ?
| | Step | Path | Label | Widget | Required | | |
| | --------------- | ------------------------- | ---------------------------------------- | -------------------------------------- | -------- | | |
| | Access | `metadata.name` | Name | Text | Required | | |
| | Access | `spec.ssh_key` | SSH public key | Text (multiline) | ? | | |
| | Configuration | `spec.image.source_ref` | VM image (OCI reference) | Text | Required | | |
| | Configuration | `spec.is_windows` | OS family | Radio (`Linux`, `Windows`) | Required | | |
| | Configuration | `spec.instance_type` | Instance type | Picker ([§2.1.5](#215-vm-instance-type-picker-api)) | Required | | |
| | Configuration | `spec.user_data` | User data (cloud-init / Ignition) | Text (multiline) | Optional | | |
| | Configuration | `spec.boot_disk.size_gib` | Boot disk size (GiB) | Number | ? | | |
| | Configuration | `spec.run_strategy` | Run strategy | Select (`Always`, `Halted`) | Required | | |
| | Networking | `spec.network_attachments` | Virtual network, subnet, security groups | Pickers ([§2.1.4](#214-vm-networking-picker-apis)) | Required | | |
| | Step | Path | Label | Widget | Required | | |
| | --------------- | ------------------------- | ---------------------------------------- | -------------------------------------- | -------- | | |
| | General info | `metadata.name` | Name | Text | Required | | |
| | General info | `metadata.labels` | Labels | Text array | Optional | | |
| | Configuration | `spec.ssh_key` | SSH public key | Text (multiline) | ? | | |
| | Configuration | `spec.image.source_ref` | VM image (OCI reference) | Text | Required | | |
| | Configuration | `spec.is_windows` | OS family | Radio (`Linux`, `Windows`) | Required | | |
| | Configuration | `spec.instance_type` | Instance type | Picker ([§2.1.5](#215-vm-instance-type-picker-api)) | Required | | |
| | Configuration | `spec.user_data` | User data (cloud-init / Ignition) | Text (multiline) | Optional | | |
| | Configuration | `spec.boot_disk.size_gib` | Boot disk size (GiB) | Number | ? | | |
| | Configuration | `spec.run_strategy` | Run strategy | Select (`Always`, `Halted`) | Required | | |
| | Networking | `spec.network_attachments` | Virtual network, subnet, security groups | Pickers ([§2.1.4](#214-vm-networking-picker-apis)) | Required | |
There was a problem hiding this comment.
Proposal: reorder the five steps to:
Catalog Item → Configuration → Networking → Access → Review and Submit
Configuration (resource shape + identity):
metadata.name first (required for all resources)
Then the fields that are Configuration in the PRD today:
VM: spec.image.source_ref, spec.is_windows, spec.instance_type, spec.user_data, spec.boot_disk.size_gib, spec.run_strategy
Cluster: spec.release_image, spec.node_sets
Networking — unchanged from the PRD (spec.network_attachments for VM; spec.network.pod_cidr / spec.network.service_cidr for cluster).
Access — credentials only, after the user has chosen catalog, sizing/platform, and networking:
VM: spec.ssh_key
Cluster: spec.ssh_public_key, spec.pull_secret
Review and Submit — unchanged.
There was a problem hiding this comment.
what about the metadata.labels ? Are we completely ignoring them in the UI for now ? IMO we should expose them for every resource, same as metadata.name.
Im still more inclined to have name/labels in a separate step from the rest of the configuration. We wouldnt want to have too many fields in one step.
There was a problem hiding this comment.
Good point about labels
Should we have:
Catalog Item → Identity -> Configuration → Networking → Access → Review and Submit
Identity: metadata.name and metadata.labels (we can also add annotations later)
Configuration
VM: spec.image.source_ref, spec.is_windows, spec.instance_type, spec.user_data, spec.boot_disk.size_gib, spec.run_strategy
Cluster: spec.release_image, spec.node_sets
Networking — unchanged from the PRD (spec.network_attachments for VM; spec.network.pod_cidr / spec.network.service_cidr for cluster).
Access — sshkey and pull secret
VM: spec.ssh_key
Cluster: spec.ssh_public_key, spec.pull_secret
Review and Submit — unchanged.
There was a problem hiding this comment.
Or do you prefer just renaming Access to General?
There was a problem hiding this comment.
Catalog Item → Identity (or General) -> Configuration → Networking → Access → Review and Submit
sounds good to me
There was a problem hiding this comment.
Because I won't be adding the labels for 0.1 and don't want a step with just one field - name, I'm reverting back to Catalog Item -> General -> Configuration -> Networking -> Review and Submit
We can move the credentials to access step in later release when we have more fields for the first step
Assisted-by: Claude Code <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
7 participants
PRD: Configuration wizard for cluster and VM resources
Jira: https://redhat.atlassian.net/browse/OSAC-1421
Summary
This PRD defines the provisioning wizard in the OSAC UI for ComputeInstance and Cluster resources. Tenant users select a published catalog offering, complete five guided steps (catalog selection -> General -> Compute -> Networking -> Review), and submit a create request shaped by the configured fields.
Requesting Review On
How to Review
Summary by CodeRabbit