Volker Theile
5406c08f76
* perf: speed up the VM list with many VMs The VM list scanned whole store lists for every row and re-evaluated the same values per row on every render and sort. With several hundred VMs this blocked the browser on sorting and on every VM update. Performance: - look up launcher pods and migrations through shared indexes (namespace/name -> resource) instead of scanning per row; the indexes are computed per store list, so they stay in sync with in-place store updates - use the same migration lookup (getLatestMigration) in the VM model and on the VM detail page - look up PVCs, PVs, VMIs and restore backups by id - merge VMs and VMIs with a Set - evaluate the VM state once when sorting by state - check the unschedulable condition before the pod based state checks - cache feature flag results and per-schema/per-setting values that are the same for every row Bug fixes: - the launcher pod map was never rebuilt, because the store keeps the same array - pods, volumes and migrations of a VM with the same name in another namespace could be picked up The order of the volumes of a VM (vm.volumes) now follows the VM spec instead of the store order. Nothing depends on it. Measured in a synthetic setup, 100 rows per page, sorting by state (Chrome, dev build): - ~490 VMs, ~500 PVCs/PVs: 1.9 s -> 1.0 s - ~490 VMs, 600 PVs, 200 migrations: 6.0 s -> 0.7 s, main thread blocked during VM updates 78% -> 32% With few volumes the gain is much smaller (8-20%). Related to: https://github.com/harvester/harvester/issues/9513 Signed-off-by: Volker Theile <vtheile@suse.com> * fix: read VM data from the store of the resource instead of a fixed one The migrations of a VMI and the migration badge of the state column were read from the hardcoded `harvester` store. In the Rancher explorer (embedded and standalone) the data is loaded into the `cluster` store, so a running migration was shown neither in the VM state nor as badge. The VM model remembered the store of the current product in a module variable on first use and never updated it. The same model is used in the Harvester product (`harvester` store) and in the Rancher explorer (`cluster` store), and Rancher keeps the page loaded when going from the explorer of a Harvester cluster to Virtualization Management and into the Harvester product. The VM list then read the VMIs, launcher pods, volumes and restores from the wrong store, and running VMs were shown as Starting until the page was reloaded. Read the data from the store the resource lives in (`this.$getters`, in the formatter the store of the current product). In the Harvester product this is still the `harvester` store, so nothing changes there. Not covered: volume details like the lock icon of encrypted volumes. The explorer uses the generic Rancher PVC model, which does not know them, and settings based checks (feature flags, backup target) are not loaded there either. Related to: https://github.com/harvester/harvester/issues/11882 Signed-off-by: Volker Theile <vtheile@suse.com> --------- Signed-off-by: Volker Theile <vtheile@suse.com>
harvester-ui-extension
The Harvester UI Extension is a Rancher extension that provides the user interface for Harvester within the Rancher Dashboard.
Note: This extension is available starting from Rancher 2.10.0. Ensure your Rancher version is 2.10.0 or later to access Harvester integration.
Installation
For Harvester UI extension installation instructions, please refer to the page Rancher Integration -> Harvester UI Extension in official Harvester documentation.
Development Setup
Ensure Node.js v20 or later is installed for development and debugging.
Standalone Mode
Run the extension standalone with hot reload at https://localhost:8005.
# Install dependencies
yarn install
# Start the development server
RANCHER_ENV=harvester API=https://your-harvester-ip yarn dev
# Example with specific server version
RANCHER_ENV=harvester VUE_APP_SERVER_VERSION=v1.5.0 API=https://192.168.1.123 yarn dev
You may also define environment variables in a .env file:
RANCHER_ENV=harvester
VUE_APP_SERVER_VERSION=v1.5.0
API=https://192.168.1.123
Rancher Integration Mode
To run as a Rancher extension, follow the Rancher UI Extension Guide.
API=https://your-rancher-ip yarn dev
Commit Message Guidelines
This project uses commit-lint with Conventional Commits to ensure consistent and meaningful commit messages.
Commit Message Format
All commit messages must follow the conventional commit format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Supported Types
- feat: New features
- fix: Bug fixes
- docs: Documentation changes
- style: Code style changes (formatting, missing semicolons, etc.)
- refactor: Code refactoring
- perf: Performance improvements
- test: Adding or updating tests
- build: Build system or external dependencies
- ci: CI/CD changes
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
- wip: Work in progress
- deps: Dependency updates
- security: Security fixes
Examples
# Feature
git commit -m "feat: add new virtual machine creation wizard"
# Bug fix
git commit -m "fix: resolve memory leak in VM console"
# Documentation
git commit -m "docs: update installation instructions"
# Breaking change
git commit -m "feat!: change API endpoint structure
BREAKING CHANGE: The /api/v1/vms endpoint has been replaced with /api/v2/vms"
Git Hooks
The project uses Husky to automatically validate commit messages and run linting before commits:
- pre-commit: Runs ESLint to ensure code quality
- commit-msg: Validates commit message format using commit-lint
These hooks are automatically installed when you run yarn install.
Manual Validation
You can manually validate commit messages:
# Validate the last commit
yarn commitlint
# Validate a specific commit
npx commitlint --from <commit-hash>
# Validate a range of commits
npx commitlint --from <start-hash> --to <end-hash>
Branch Structure
main– Main development branchrelease-harvester-vX.Y– Stable release branches per version seriesvX.Y-head– Testing branches for ongoing changes to extension builds in each release series
Note: The
vX.Y-headbranches are auto-generated and kept in sync with release branches. Use these for testing the latest changes in each version series.
Testing Guidelines
UI Extension Testing
To validate changes in a release series, switch to the appropriate vX.Y-head branch. For main branch testing, use main-head.
- Examples:
- Test
1.0.xseries →v1.0-head - Test
1.5.xseries →v1.5-head
- Test
Steps:
- Navigate to Rancher UI → Local → App → Repositories
- Refresh the Harvester repository using the target
vX.Y-headbranch - Go to the Extensions page and install the desired version
Standalone Mode Testing
To test the standalone UI, configure Harvester to load the UI from an external source.
- Examples of
ui-index:- Main branch →
https://releases.rancher.com/harvester-ui/dashboard/latest/index.html - Release series
1.5.x→https://releases.rancher.com/harvester-ui/dashboard/release-harvester-v1.5/index.html
- Main branch →
Steps:
- Go to Harvester UI → Advanced → Settings → UI
- Set ui-source to
External - Set ui-index to the desired URL
Contributing
If you want to contribute, start by reading this document, then visit our Getting Started guide to learn how to develop and submit changes.
License
Copyright (c) 2014-2026 SUSE, LLC.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.