Refactor RKE 2 provisioning into more isolated components

[eva-vashkevich]

Is your feature request related to a problem? Please describe.

We should refactor rke2 provisioning into more isolated components and improve test coverage.
Currently, that part of the provisioning journey is very fragile and it is easy to introduce regressions.

Describe the solution you'd like

We should :

• Break it into smaller components ie separate logic that handles machine pools, separate logic that handles add ons. AI can be used to come up with a plan and some of the implementation
• Add more unit test and E2E test coverage. One possibility is to add E2E test with mocks to be run as part of the PR review while having a second set of tests with unmocked data for overnight Jenkins jobs.

Describe alternatives you've considered

Additional context

[github-actions]

🎯 Agentic Issue Triage

Summary: This is a refactoring and test-coverage improvement task for the RKE2 provisioning UI. The goal is to break the provisioning journey into smaller, more isolated components (machine pools, add-ons, etc.) and add both unit and E2E test coverage to reduce regression risk. Already has milestone v2.16.0 and labels area/clusterprovisioningv2, kind/enhancement, QA/dev-automation.

---

📐 Proposed Breakdown / Checklist

• Audit current RKE2 provisioning components to map responsibilities and identify coupling
• Extract machine pool logic into a dedicated component (e.g., MachinePool.vue / composable)
• Extract add-ons/config logic into its own component/composable
• Refactor shared state out of monolithic forms into clearly-owned composables or stores
• Write unit tests for each extracted component/composable (happy path + edge cases)
• Add E2E tests with mocked responses suitable for PR-level CI (fast feedback)
• Add a second suite of full (unmocked) E2E tests for nightly Jenkins runs
• Validate no regressions on existing provisioning flows (create / edit / delete RKE2 cluster)

🔍 Relevant Code Areas

Key files/paths to investigate:

• shell/pages/c/_cluster/provisioning/ — provisioning page entry points
• shell/components/cluster/ — existing cluster-related components
• shell/edit/provisioning.cattle.io.cluster/ — main cluster edit/create forms
• shell/mixins/ or composables related to provisioning
• cypress/e2e/tests/ — existing E2E tests to use as a reference

A prior related (closed) issue for context: #5512 – Refactor and add tests for brittle code in cluster edit/create forms

🧪 Testing Strategy

Unit tests (Jest):

• Use shallowMount to isolate each new component
• Cover: prop validation, emitted events, conditional rendering (e.g., machine pool count, add-on toggles)
• Use it.each for table-driven edge cases (empty config, max pool count, etc.)

E2E tests (Cypress) — PR-level (mocked):

• Mock the provisioning API responses via cy.intercept
• Assert that form fields render, machine pool rows are added/removed, and the submit payload is correct

E2E tests — nightly (unmocked):

• Full create → verify → delete RKE2 cluster flow
• Tag with a label/grep tag (e.g., @overnight) so they can be filtered out of PR runs

💡 Implementation Nudges

• AI-assisted planning: As mentioned in the issue, AI tooling can help generate a component decomposition plan; feed the current file to the model with a prompt like "identify responsibilities and propose a component split."
• Composition API: New components should use the Vue 3 Composition API (composables) to make logic more testable in isolation without mounting the full component.
• Avoid prop drilling: Use provide/inject or a scoped Pinia store for provisioning state shared across many child components.
• Incremental refactor: Prefer extracting one concern at a time (e.g., machine pools first) so each PR is reviewable and testable on its own.

Generated by Agentic Triage for issue #17825 · ● 171.7K · ◷

[github-actions]

🤖 Issue grooming questions

Thanks for filing this! The problem statement and technical direction are clear, but a couple of things are needed before this is ready for triage:

Missing: Concrete acceptance criteria (Criterion 2)

The solution section describes an approach (break into smaller components, add tests), but there's no clear definition of "done." Without it, it's difficult to scope, estimate, or verify the work.

1. What specific acceptance criteria would define this refactoring as complete?
   For example:

   • Which concrete components should be extracted (e.g., machine-pool logic → MachinePoolConfig.vue, add-on logic → AddOnConfig.vue)?
   • Is there a minimum unit/E2E test coverage threshold you have in mind?
   • Should the refactoring be done in one milestone or phased across multiple?

2. Which specific files or areas of the codebase are the primary focus for the first iteration?
   A pointer to the key files (e.g., under shell/ or pkg/) would help scope the initial effort.

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

Generated by Daily Issue Grooming · ● 688.2K · ◷