* fix: show resource counts for all side navigation items The side navigation looks up the count of a nav item by its name, but the counts are keyed by the K8s resource type. Many Harvester nav items are named differently than the resource they list (e.g. harvesterhci.io.volume lists persistentvolumeclaim), so no count was shown for them. Some list views also show only a subset of their resource type, so the plain count would not match the list. Override the count getter of the harvester store: - Resolve the nav item to the resource type it lists, using the same fallback to the configureType resource as schemaFor. This fixes Hosts, Alertmanager Configs, Cluster Flows, Cluster Outputs, Flows, Outputs and Secrets. - Count only the subset shown by the list for Volumes, VM Networks, VM Backups, VM Snapshots, Volume Snapshots, Cloud Configuration Templates and Storage. The matches are counted per namespace once per store list using sharedComputed. - Like the list views, do not count resources in system namespaces when "All Namespaces" is selected. Steve's counts endpoint only returns the total per resource type, so the filtered counts are computed from the store list and are only available once that list is loaded. Until then these nav items show no count, unless there are no resources of that type at all (then 0). The dashboard loads PVCs and networks, the VM list PVCs and backups, the other resources are loaded when their list is opened. Related to: https://github.com/harvester/harvester/issues/11984 Signed-off-by: Volker Theile <vtheile@suse.com> * refactor: get the side navigation counts from the server Stop loading full resource lists and filtering them in the browser to get the side navigation counts. - Nav items listing all resources of a type use the counts endpoint, through the resource type of the nav item. - VM backups, VM snapshots, volume snapshots, storage classes, cloud config templates and VM networks request their subset from /v1/harvester with a page size of 1. These requests run again when the counts endpoint reports other numbers for the type, and when the namespace filter changes. - Namespaces count the already loaded namespaces that are neither system nor Fleet managed. - Volumes have no count: the list hides volumes that are only marked by annotations, which the API cannot filter on. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * refactor: keep the side navigation count helpers in the store getters Move them out of their own file, next to the count getter that uses them. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: make the side navigation count requests more robust - Ignore a late response of the previous cluster. Resetting the request ids when loading a cluster let it overwrite the count of the new one. - Keep the watchers when a cluster left while it was loading finishes loading after the new one. - Show no count instead of 0 on Harvester v1.3, which ignores the query and sends all resources without a count. - Hide the storage network by its generated name. Networks created before Harvester v1.4 do not have the hash label, and an upgrade does not add it. - Stop refreshing after leaving the product, cancel pending refreshes when the watchers stop, and cope with the store module being unregistered when logging out. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: count only the settings the Settings page shows The nav item showed the total of all Setting resources, but the page only shows the allowed ones that exist in the cluster and are supported by its version. Move these rules into a visibleSettings getter that both the page and the count use, so that they always agree. SettingList no longer needs its feature flag check. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * test: remove a Settings page test that was committed twice Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: show the number of volumes in the side navigation The Volumes list hides golden image volumes and the temporary volumes CDI uses to populate a volume, so the total of the counts endpoint would be wrong. Golden image volumes are only marked by an annotation, which Harvester's API cannot filter on, but each one belongs to a DataVolume owned by its VM image. So request the volumes that are not owned by another volume, and the DataVolumes owned by a VM image, and show the difference. Every nav item with a list now has a number, so remove NO_COUNT. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> --------- Signed-off-by: Volker Theile <vtheile@suse.com> Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> Co-authored-by: Marcelo Fukumoto <marcelo.fukumoto@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.
Table of Contents
- Installation
- Development Setup
- Commit Message Guidelines
- Branch Structure
- Testing Guidelines
- Release
- Contributing
- License
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 v24 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
Release
The Harvester UI Extension follows the Harvester release cycle. After RC1 is cut for a new Harvester version, we usually create and work from the corresponding release branch (for example, release-harvester-v1.8). The remaining RC builds and the final official release are published from that branch.
After Harvester releases a new version, update the Harvester entry in rancher/ui-plugin-charts manifest.json. This ensures air-gapped users can pull the new Harvester UI Extension image.
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.