WorkloadMonitor resources are only needed when extra/monitoring is
deployed. Move them from system/monitoring to extra/monitoring package.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
- Replace hardcoded tenant-root with {{ .Release.Namespace }} in vmagent
and fluent-bit configs
- Add ExternalName services in cozystack-basics to redirect monitoring
traffic from cozy-monitoring to tenant-root when engine is deployed
- Add missing components to monitoring PackageSource
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Add dashboards.list that defines which Grafana dashboards to create.
Without this file, no GrafanaDashboard resources were being generated.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Remove components that are already defined in separate PackageSources
to avoid race conditions and HelmRelease conflicts:
- vertical-pod-autoscaler
- postgres-operator
- grafana-operator
- victoria-metrics-operator
- prometheus-operator-crds
These components should be installed via their dedicated PackageSources.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
The monitoring package depends on cozystack.cozystack-controller which
is only installed as part of cozystack-engine. This prevents monitoring
from becoming ready when cozystack-engine is not enabled.
Remove this dependency to allow monitoring to work independently.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
## Summary
- Fix invalid PromQL expression in `CNPGClusterOffline` alert rule that
causes vmalert pods to crash
- Fix PromQL logic so the alert fires correctly when cluster is offline
## Problem
The `CNPGClusterOffline` alert in
`packages/system/postgres-operator/alerts/cnpg-default-alerts.yaml` had
two issues:
1. **Syntax error** - Extra closing parenthesis causing vmalert pods to
crash:
```promql
sum by (namespace, pod) (cnpg_collector_up)) OR on() vector(0) == 0
^^-- extra )
```
2. **Logic error** - After removing the extra parenthesis, the
expression still had incorrect logic:
```promql
sum by (namespace, pod) (cnpg_collector_up) OR on() vector(0) == 0
```
This evaluates as `cnpg_collector_up OR (vector(0) == 0)` which fires
when the cluster is **online** (wrong behavior).
## Solution
Fix both issues by properly wrapping the OR expression in parentheses:
```promql
(sum by (namespace, pod) (cnpg_collector_up) OR on() vector(0)) == 0
```
This correctly fires when `cnpg_collector_up` is 0 or absent (cluster
actually offline).
## Test plan
- [ ] Verify vmalert pods start successfully after applying the fix
- [ ] Verify the alert rule is properly loaded
- [ ] Verify alert only fires when CNPG cluster is actually offline
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What this PR does
When OIDC is disabled, the dashboard's token-proxy now properly
validates bearer tokens against the k8s API's JWKS url.
### Release note
```release-note
[dashboard] Verify bearer tokens against the issuer's JWKS url.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Implemented JWKS-based JWT token verification for enhanced security.
* Added conditional role-based access control for non-OIDC deployments.
* **Chores**
* Updated authentication dependencies and modernized token validation.
* Removed legacy external token validation mechanism.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
When OIDC is disabled, the dashboard's token-proxy now properly
validates bearer tokens against the k8s API's JWKS url.
### Release note
```release-note
[dashboard] Verify bearer tokens against the issuer's JWKS url.
```
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Remove extra closing parenthesis in the CNPGClusterOffline alert expression
that causes vmalert pods to crash with "bad prometheus expr" error.
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
- Add monitoring as a system chart
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Introduced comprehensive monitoring stack with Grafana, Victoria
Metrics operators, Prometheus operator, and vertical pod autoscaler for
enhanced system observability and performance metrics.
* **Chores**
* System upgraded to version 27 with automatic monitoring resource
reorganization for improved infrastructure management.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Add migration 26 that re-labels monitoring resources to be owned by
monitoring-system HelmRelease instead of monitoring. This allows
seamless transition from direct resource management in extra/monitoring
to delegated management via system/monitoring chart.
Migration steps:
- Find all monitoring HelmReleases in tenant namespaces
- Suspend HelmRelease to prevent reconciliation
- Delete helm secrets to orphan resources
- Relabel all resources to monitoring-system
- Delete suspended HelmRelease
Also updates:
- monitoring-application.yaml: add monitoring-system component
- helmrelease.yaml: reference monitoring-system ExternalArtifact
- values.yaml: bump targetVersion to 25
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
## Summary
- Configure CoreDNS chart to create `kube-dns` ServiceAccount matching
Kubernetes bootstrap ClusterRoleBinding
- Fixes RBAC errors (`Failed to watch`) when CoreDNS pods restart
## Problem
Kubernetes bootstrap creates a `ClusterRoleBinding: system:kube-dns`
that references `ServiceAccount: kube-dns` in `kube-system`. However,
the coredns chart was using the `default` ServiceAccount because
`serviceAccount.create` was not enabled.
This caused CoreDNS pods to fail with `[ERROR] plugin/kubernetes: Failed
to watch` errors after restarts, as they lacked RBAC permissions to
watch the Kubernetes API. Old pods worked due to cached data, but new
pods failed after rollout.
## Solution
Add ServiceAccount configuration to
`packages/system/coredns/values.yaml`:
```yaml
serviceAccount:
create: true
name: kube-dns
```
## Test plan
- [x] Verify ServiceAccount `kube-dns` is created: `kubectl get sa -n
kube-system kube-dns`
- [x] Verify deployment uses correct ServiceAccount: `kubectl get
deployment -n kube-system coredns -o
jsonpath='{.spec.template.spec.serviceAccountName}'` → `kube-dns`
- [x] Restart CoreDNS pods and verify all pods are Ready
- [x] Check logs show no RBAC errors
- [x] Test DNS resolution works
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated DNS service configuration with service account settings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Add migration 25 for v1.0 upgrade cleanup:
- Remove legacy `cozystack` installer deployment
- Remove legacy `cozystack-assets` statefulset
- Remove `bootbox` and `bootbox-rd` HelmReleases (will be recreated by
new platform chart if enabled)
- Revert migration 23 to original state (only removes
cozystack-resource-definition-crd)
- Update targetVersion from 24 to 26
- Fix jq syntax error in `hack/migrate-to-version-1.0.sh`
Migration 23 was already executed on existing clusters at version 23+,
so adding cleanup there would never run. The new migration 25 ensures
proper cleanup during v1.0 upgrade.
## Test plan
- [ ] Upgrade from v0.4x to v1.0
- [ ] Verify old `cozystack` deployment is deleted
- [ ] Verify old `cozystack-assets` statefulset is deleted
- [ ] Verify old `bootbox` and `bootbox-rd` HelmReleases are deleted
- [ ] Verify platform installs successfully after migration
- [ ] Run `./hack/migrate-to-version-1.0.sh` without jq errors
Migration 23 was already executed on existing clusters, so the legacy
installer removal never ran. This moves the cleanup to a new migration 25
which will execute during upgrade.
Changes:
- Revert migration 23 to original state (only removes cozystack-resource-definition-crd)
- Add migration 25 for v1.0 upgrade cleanup:
- Remove legacy cozystack installer deployment
- Remove legacy cozystack-assets statefulset
- Remove bootbox and bootbox-rd HelmReleases
- Update targetVersion from 24 to 26
- Fix jq syntax error in migrate-to-version-1.0.sh
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
## Summary
- Remove duplicate `bootbox-system` component from `bootbox-application`
PackageSource (was duplicating system/bootbox installation)
- Auto-create `cozystack.bootbox-application` Package when bootbox is
enabled in `bundles.enabledPackages`
- This ensures `bootbox-rd` (ApplicationDefinition) is properly
installed as a dependency before `cozystack.bootbox`
## Test plan
- [ ] Enable bootbox in `bundles.enabledPackages`
- [ ] Verify both `cozystack.bootbox-application` and
`cozystack.bootbox` Packages are created
- [ ] Verify `bootbox-rd` (ApplicationDefinition) is installed
- Fix docker build context for migrations image
- Fix yq flags for compatibility with Mike Farah's yq v4
- Add platform image to main build target
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Add cleanup of old installer components during migration:
- Delete cozystack deployment
- Delete cozystack-assets statefulset
This ensures no conflict between old installer and new operator
when upgrading to v1.0 architecture.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
- Remove duplicate bootbox-system component from bootbox-application
PackageSource (was duplicating system/bootbox installation)
- Auto-create cozystack.bootbox-application Package when bootbox is
enabled in bundles.enabledPackages
- This ensures bootbox-rd (ApplicationDefinition) is properly installed
as a dependency before cozystack.bootbox
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
- Removes `hostNetwork` for Ingress NGINX Controller for Managed
kubernetes cluster
- Adds Service of type NodePort for load balancing
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
[kubernetes] use NodePort service instead of hostNetwork for ingress-nginx
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Configuration**
* Updated ingress-nginx controller to use NodePort exposure method
(ports 30000 for HTTP, 30001 for HTTPS) when configured as "Proxied."
* Removed unnecessary hostNetwork configuration for the controller.
* Service port mappings updated to align with new NodePort settings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Adds separate values to keycloak branding.
### Release note
```release-note
Added separate values to keycloak branding
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Enhanced branding configuration application with improved conditional
logic to ensure branding is only applied when appropriate configuration
values are present.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Aligns MongoDB configuration with postgres and mysql patterns by
introducing a separate `databases` section.
**Before:**
```yaml
users:
myuser:
db: mydb
roles:
- name: readWrite
db: mydb
- name: dbAdmin
db: mydb
```
**After:**
```yaml
users:
myuser: {}
databases:
mydb:
roles:
admin:
- myuser
readonly:
- reader
```
Changes:
- Add separate `databases` section with `roles.admin` and
`roles.readonly`
- Simplify `users` to only contain optional password field
- All users authenticate via `admin` database (MongoDB production best
practice)
- `admin` role maps to `readWrite` + `dbAdmin` permissions
- `readonly` role maps to `read` permission
## Migration
Includes migration script (`migrations/24`) that automatically converts
existing MongoDB HelmReleases:
- Detects old format users (with `db` and `roles` fields)
- Converts `readWrite`/`dbAdmin` roles → `databases.{db}.roles.admin`
- Converts `read` role → `databases.{db}.roles.readonly`
- Preserves user passwords in new `users` format
- Skips HelmReleases that don't have old format
### Release note
```release-note
[mongodb] Unified users and databases configuration to match postgres and mysql patterns. Users now defined separately from databases, with role assignments in the databases section. Includes automatic migration for existing deployments.
```
This PR prepares the release `v1.0.0-beta.2`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated multiple system component images from alpha to beta releases
(v1.0.0-beta.2)
* Updated container image digests across various services for
consistency and stability
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Service will be recreated
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
Allow changing field `external` after creation.
Service will be deleted and then created with correct type.
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
[vm] recreate service on `external` change to allow changing this field after creation
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Detects Service type changes during virtual machine updates and
automatically recreates the Service as needed; update workflow now runs
a job to remove and recreate Services before reconciliation.
* **Chores**
* Updated RBAC to grant the update workflow permissions to manage
(delete) the targeted Service.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The Kubernetes bootstrap creates a ClusterRoleBinding 'system:kube-dns'
that references ServiceAccount 'kube-dns' in 'kube-system'. However,
the coredns chart was using the 'default' ServiceAccount because
serviceAccount.create was not enabled.
This caused CoreDNS pods to fail with 'Failed to watch' errors after
restarts, as they lacked RBAC permissions to watch the Kubernetes API.
Configure the chart to create the 'kube-dns' ServiceAccount, which
matches the expected binding from Kubernetes bootstrap.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Add instance profile metadata to workload monitor
Currently getWorkloadMetadata only extracts the
kubevirt.io/cluster-instancetype-name annotation from VMI objects. This
misses the instance profile information
(kubevirt.io/cluster-preference-name), which is needed to track
workload sizing/configuration alongside the instance type.
This change adds extraction of the cluster instance profile annotation
and exposes it as the
workloads.cozystack.io/kubevirt-vmi-instance-profile label on collected
metrics.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Workload monitoring now detects kubevirt instance profile annotations
and adds a matching workload label
(workloads.cozystack.io/kubevirt-vmi-instance-profile) when present.
* Enriched workload metadata for virtualized workloads.
* No other behavior or control-flow changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
[]
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Configured cluster for high availability with multiple replicas
* Implemented rolling update strategy to ensure safer deployments
* Enhanced health constraints to maintain cluster stability during
updates
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
Enable Cozystack deployment on generic Kubernetes clusters (kubeadm,
k3s, RKE2, etc.) by making Talos-specific configurations conditional and
adding a new `isp-full-generic` bundle variant.
## Problem 1: Cilium uses hardcoded Talos API endpoint
**Issue**: Cilium is configured to connect to Kubernetes API at
`localhost:7445` (Talos KubePrism). On non-Talos clusters, the API
server runs on standard `<node-ip>:6443`.
**Solution**: Add `networking.apiServer.host` and
`networking.apiServer.port` to platform values, passed to Cilium via
bundle template.
**Why this approach**: Allows per-deployment configuration while keeping
Talos defaults for backwards compatibility.
## Problem 2: Cilium cgroup automount disabled
**Issue**: `values-talos.yaml` sets `cgroup.autoMount.enabled: false`
because Talos mounts cgroups. On Ubuntu/Debian, Cilium needs to mount
cgroups itself.
**Solution**: Add `networking.cilium.cgroup.autoMount` configuration and
create `cilium-generic` / `kubeovn-cilium-generic` networking variants
without `values-talos.yaml`.
**Why this approach**: Separate variants avoid complex conditional logic
in templates and make the difference explicit.
## Problem 3: KubeOVN helm lookup fails on fresh clusters
**Issue**: KubeOVN chart uses `lookup` to find control-plane nodes.
During initial deployment, lookup returns empty results causing
installation failure.
**Solution**: Add `networking.kubeovn.MASTER_NODES` parameter to
explicitly pass node IPs when needed.
**Why this approach**: Helm lookup is unreliable during initial
deployment; explicit configuration is more predictable.
## Problem 4: LinstorSatelliteConfiguration breaks non-Talos nodes
**Issue**: `cozystack-talos` LinstorSatelliteConfiguration removes DRBD
init containers (`drbd-module-loader`, `drbd-shutdown-guard`). These are
required on Ubuntu/Debian where DRBD modules aren't pre-loaded.
**Solution**: Add `talos.enabled` value (default: true) and wrap the
configuration in `{{- if .Values.talos.enabled }}`.
**Why this approach**: Conditional rendering is cleaner than node
selectors (Talos has no unique default label) and maintains backwards
compatibility.
## Problem 5: linstor-scheduler image tag invalid for k3s
**Issue**: k3s reports version as `v1.35.0+k3s1`. The `+` character is
invalid in Docker image tags, causing `InvalidImageName` error for
kube-scheduler.
**Solution**: Strip distribution suffix using `regexReplaceAll "\\+.*$"`
in the helper template.
**Why this approach**: k3s version `v1.35.0+k3s1` is based on upstream
`v1.35.0`, so stripping the suffix produces the correct upstream image
tag. This is automatic and doesn't require manual version specification.
## Problem 6: No bundle for non-Talos deployments
**Issue**: `isp-full` bundle always uses Talos-specific networking and
doesn't pass `talos.enabled=false` to linstor.
**Solution**: Add `isp-full-generic` bundle variant that uses
`kubeovn-cilium-generic` networking and passes `talos.enabled=false` to
linstor.
**Why this approach**: Dedicated bundle variant makes deployment
straightforward — users just set `bundle-name: isp-full-generic` without
needing post-install patches.
## Files Changed
| Path | Change |
|------|--------|
| `packages/core/platform/values.yaml` | Add apiServer, cilium.cgroup,
kubeovn.MASTER_NODES config |
| `packages/core/platform/sources/networking.yaml` | Add generic
variants |
| `packages/core/platform/templates/bundles/system.yaml` | Add
isp-full-generic bundle |
| `packages/system/linstor/values.yaml` | Add talos.enabled |
| `packages/system/linstor/templates/satellites-talos.yaml` |
Conditional rendering |
| `packages/system/linstor-scheduler/.../templates/_helpers.tpl` | Strip
version suffix |
| `packages/system/linstor-scheduler/.../templates/deployment.yaml` |
Use helper for image tag |
## Testing
Tested on k3s v1.35.0+k3s1 with Ubuntu 24.04 LTS. All HelmReleases
deploy successfully without post-install patches.
## Breaking Changes
None. Existing Talos deployments continue to work unchanged with default
values.
---
Closes#1933
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added support for generic (non-Talos) Kubernetes clusters with new
isp-full-generic platform bundle
* Introduced generic and hosted deployment variants for
cozystack-operator
* Added generic networking variants with Cilium and KubeOVN support
* Expanded IAAS, PAAS, and NAAS bundle support for generic deployments
* Improved backup retention configuration
* **Bug Fixes**
* Fixed Kubernetes version handling to work with distribution-specific
suffixes
* **Chores**
* Made LINSTOR Talos satellite support optional
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
Add external ips (LoadBalancer services with assigned IP address) count
to the Tenant details page
<img width="2560" height="1330" alt="external ip count on tenant details
page"
src="https://github.com/user-attachments/assets/f2256629-3815-4892-b80d-e150d0fd3908"
/>
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
[dashboard] add external ips count (count of services of type LoadBalancer with assigned ip) to the Tenant details page
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* External IPs count now shown in the Tenant application Details tab — a
left-column item displays the number of external IPs for LoadBalancer
services.
* Application status now exposes an External IPs Count metric for Tenant
applications, so UI and APIs can surface the number of LoadBalancer
external IPs without changing other behaviors.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Thank you for making a contribution! Here are some tips for you:
- Start the PR title with the [label] of Cozystack component:
- For system components: [platform], [system], [linstor], [cilium],
[kube-ovn], [dashboard], [cluster-api], etc.
- For managed apps: [apps], [tenant], [kubernetes], [postgres],
[virtual-machine] etc.
- For development and maintenance: [tests], [ci], [docs], [maintenance].
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats,
even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported
to a previous version.
-->
## What this PR does
- Fix `Used` column to show correct data
- Removes table from `Info` page
- Add patch to let flatMap work with jsonpath
<img width="1800" height="940" alt="resource quota table example"
src="https://github.com/user-attachments/assets/421d1d32-fdc8-4269-838f-b02db0ed6712"
/>
### Release note
<!-- Write a release note:
- Explain what has changed internally and for users.
- Start with the same [label] as in the PR title
- Follow the guidelines at
https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->
```release-note
[dashboard] fix resource quota table on tenant details page
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed resource quota data fetching for tenant resources to use correct
namespace references from status fields.
* **Refactor**
* Refined dashboard layout for resource quota displays and improved
custom field resolution with enhanced dynamic key mapping for complex
data structures.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Removed reference to .Values.networking.apiServer which was removed
from values.yaml. Use empty defaults and let ConfigMap or
apiServerEndpoint parsing override them.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Extract common system packages shared between isp-full and isp-full-generic
into a helper template `cozystack.platform.system.common-packages`.
Packages moved to helper:
- kubeovn-webhook, kubeovn-plunger, cozy-proxy
- multus, metallb, reloader
- linstor-scheduler, snapshot-controller
Packages NOT in helper (differ between variants):
- networking (variant differs: kubeovn-cilium vs kubeovn-cilium-generic)
- linstor (talos.enabled differs)
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Per review feedback, create separate manifest files for different
deployment targets instead of using templated values:
- cozystack-operator.yaml (Talos): hardcoded localhost:7445 (KubePrism)
- cozystack-operator-generic.yaml: reads from cozystack-operator-config
ConfigMap (user must create before applying)
- cozystack-operator-hosted.yaml: no env override (uses in-cluster SA)
This keeps installation flow clean - users apply the manifest matching
their deployment target without needing to modify original files.
Build system updated to generate all three variants.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
- Remove apiServer and cilium.cgroup from user-facing values.yaml
- Hardcode Talos-specific values (localhost:7445, cgroup autoMount: false)
directly in isp-full bundle template
- isp-full-generic already hardcodes its own values
- Improve MASTER_NODES comment explaining helm lookup behavior
This hides implementation details from users as requested in review.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
