Enhance cluster type selection page

[eva-vashkevich]

We should re-visit our current cluster creation workflow and enhance cluster type selection page.
As part of it, we should also decide how we want to determine when to show CAPI clusters. For example, if we want to notify users that it is available but not installed or if some installation steps were missing.

cc @edenhernandez-suse

[github-actions]

🎯 Agentic Issue Triage

Summary: This is an enhancement request to revisit and improve the cluster type selection page in the cluster creation workflow. The current page (screenshot attached in the issue) likely needs UX/UI improvements for better usability and discoverability of cluster types.

📋 Issue Analysis

• Type: Feature enhancement / UX improvement
• Milestone: v2.16.0
• Affected Area: Cluster provisioning / cluster creation workflow
• Components likely involved:
  • shell/pages/ — cluster creation pages
  • shell/components/ — cluster type selection components
  • Possibly pkg/ extensions for RKE2/K3s provisioning

The issue is intentionally brief ("we should re-visit") and will likely need design input and further scoping before implementation begins.

🔍 Debugging / Investigation Strategies

• Review the current cluster type selection page implementation:
  • Search for the cluster driver/type selection component: grep -r "cluster-type\|clusterType\|driverName" shell/components/ shell/pages/
  • Key files to look at: shell/pages/c/_cluster/provisioning/ or similar provisioning routes
• Compare with similar UX patterns in the codebase (e.g., app/chart selection pages)
• Check if there are existing issues/RFDs linked to cluster provisioning UX improvements (see [EPIC] Support CAPI Providers in Provisioning v2 #16001, Create and Manage clusters via CAPA CAPI Provider #16540 referenced in related issues)

💡 Ideas & Nudges

• Consider grouping cluster types by category (e.g., hosted, infrastructure, custom)
• Improve search/filter functionality if many cluster types are shown
• Add descriptions or icons for each cluster type to aid user decision-making
• Consider progressive disclosure — show basic options first, advanced second
• Align with Rancher design system for consistency
• May benefit from a design mockup/wireframe before implementation

✅ Suggested Sub-tasks

• Gather design requirements / mockups for the new cluster type selection UI
• Audit the current implementation and identify specific pain points
• Review accessibility of the current page (area/accessibility)
• Implement UI changes per approved design
• Update/add unit tests for affected components
• Add or update E2E tests (already tagged QA/dev-automation)
• Verify across supported Rancher versions

🔗 Potentially Relevant Resources

• [Rancher UI Internal Docs]((extensions.rancher.io/redacted)
• Related provisioning issues: [EPIC] Support CAPI Providers in Provisioning v2 #16001, Create and Manage clusters via CAPA CAPI Provider #16540
• [Vue.js Composition API]((vuejs.org/redacted) — preferred for new components

Generated by Agentic Triage for issue #17662 · ● 169.6K · ◷

[github-actions]

🤖 Issue grooming questions

Thanks for raising this! The screenshot gives a good visual starting point. A few things are needed before this can be triaged for development:

1. Missing: Clear Problem Statement

The current description is quite open-ended ("re-visit and enhance"). Could you clarify:

• What specific problems or pain points does the current cluster type selection page have? (e.g. discoverability of CAPI, confusing layout, missing information)
• What is the intended outcome of this work — a redesign, additional options, new guidance copy, or something else?

2. Missing: Acceptance Criteria

Please add a concrete, testable checklist of what "done" looks like. For example:

• The cluster type selection page clearly communicates whether CAPI is installed or available.
• Users who attempt to use CAPI when it is not installed see an informational message / install guidance.
• (any other confirmed changes)

3. Missing: User Flow / Story

A brief description of the intended user experience would help scope this work — e.g. "As a user arriving at the cluster creation page, I should be able to see at a glance which providers are available and which require additional setup, so that I do not start a creation flow that will fail."

This comment was generated automatically to help gather the information needed to groom this issue.

Generated by Daily Issue Grooming · ● 370.5K · ◷