* 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>
* 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>
When editing a Virtual Machine's volumes, if the user selects 'No media' for the Image, the 'harvesterhci.io/os' label is incorrectly removed from the VM's metadata.
Related to: https://github.com/harvester/harvester/issues/10947
Signed-off-by: Volker Theile <vtheile@suse.com>
Volker TheileandMarcelo Fukumoto