Without explicit ephemeral-storage resources on the VirtualMachine spec,
virt-launcher pods inherit default limits from the namespace LimitRange,
which can be much lower than the emptyDisk capacity. This causes kubelet
to evict the pod when the VM's containerd unpacks images exceeding the
limit.
Set domain.resources with ephemeral-storage calculated via cozy-lib
allocation ratio based on the configured ephemeralStorage value.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
## What this PR does
Renames the misleading `subnets` field to `networks` in VMInstance. The
old field
name implied the VM was creating subnets, when in reality it attaches
the VM to
existing VPC network attachments (NetworkAttachmentDefinitions). This
change:
- Adds a new `networks` field as the primary way to attach VMs to VPC
networks
- Keeps `subnets` as deprecated with backward-compatible fallback via
Helm `default`
- Fails with a clear error if both `networks` and `subnets` are set
simultaneously
- Adds an API-backed dropdown selector for `networks[].name` listing
available
NetworkAttachmentDefinitions in the namespace
- Hides the deprecated `subnets` field from the dashboard UI
### Release note
```release-note
[vm-instance] Rename `subnets` field to `networks` in VMInstance for clarity.
The old `subnets` field is deprecated but still supported for backward compatibility.
A dropdown selector for available networks has been added to the dashboard.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added native networks field for VM attachments and a UI dropdown to
select network attachments; UI hides deprecated subnet fields for VM
instances.
* **Deprecations**
* subnets is deprecated; use networks moving forward (subnets retained
for backward compatibility).
* **Chores / Migration**
* Added a migration to copy existing subnets into networks and bumped
platform migration target version.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Enables replication unconditionally in the MariaDB CR, regardless of
replica count.
Previously, single-replica MariaDB instances created a general service
(`mariadb-<name>`) without `-primary`/`-secondary` suffixes. This
caused:
- Dashboard not displaying the service (both dashboard-resourcemap RBAC
and the ApplicationDefinition expect `-primary`/`-secondary`)
- Backup CronJob referencing non-existent `<name>-secondary` service
Also removes a duplicate `template` key in the backup-cronjob YAML that
was silently ignored by the parser.
**BREAKING CHANGE:** Single-replica MariaDB instances will now expose
services as `<name>-primary` and `<name>-secondary` instead of the bare
`<name>`. Applications connecting via the old service DNS name must
update their connection strings.
### Release note
```release-note
[mariadb] BREAKING: MariaDB now always enables replication, creating -primary/-secondary services even for single-replica instances. This fixes dashboard visibility and backup functionality for single-replica setups. Existing single-replica users must update connection strings from `<name>` to `<name>-primary`.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Removed a redundant backup job restart policy that could cause
conflicting behavior.
* Ensured replication is consistently enabled across all deployment
sizes.
* Made external service LoadBalancer settings apply more predictably for
external deployments.
* Adjusted database host selection so single-replica deployments target
the primary instance, improving connection correctness.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
After migration 36 copies subnets to networks, both fields are populated.
The fail guard would break Helm reconciliation. Instead, networks simply
takes priority via the existing default fallback.
Also handle missing VMInstance CRD gracefully in migration 36.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
Add fail validation when both 'networks' and 'subnets' are set to
prevent silent data loss during migration. Compute $networks variable
once at template top level to eliminate DRY violation. Regenerate CRD
via make generate instead of manual editing.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
Rename the misleading 'subnets' field to 'networks' in VMInstance to
better reflect that it attaches the VM to VPC network attachments, not
creates subnets. The old 'subnets' field is kept as deprecated with
fallback logic for backward compatibility.
Add an API-backed dropdown (listInput) for networks[].name that lists
available NetworkAttachmentDefinitions in the namespace, and hide the
deprecated subnets field from the dashboard UI.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
## What this PR does
Previously, removing a database from `values.databases` had no effect —
the database and its associated roles (`<db>_admin`, `<db>_readonly`)
persisted in PostgreSQL indefinitely. This made it impossible to
declaratively manage database lifecycle via Helm values.
Added two cleanup stages to the init script, mirroring the existing user
deletion logic:
- **Delete databases** that have the `database managed by helm` comment
but are no longer listed in `values.databases` — active connections are
terminated before dropping
- **Delete orphaned roles** (`<db>_admin`, `<db>_readonly`) with proper
membership revocation (`REVOKE ... FROM`) before `REASSIGN OWNED` /
`DROP OWNED` / `DROP ROLE`
This also fixes the reported issue where creating a database, removing
it, and creating it again would silently retain stale data from the
first instance.
### Release note
```release-note
[postgres] Databases removed from `values.databases` are now properly dropped along with their associated roles. Previously removed databases and roles would persist indefinitely.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Enhanced database initialization to automatically remove databases and
roles that were removed from your Helm configuration, avoiding orphaned
resources.
* Now force-terminates active sessions, reassigns owned objects, and
cleans up role memberships to ensure reliable removals.
* Improves consistency of database state during upgrades and
configuration changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
When replicas=1, the secondary service has no endpoints because the
only pod is the primary. Route backups to the primary service in this
case to ensure they work correctly.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
Enable replication unconditionally regardless of replica count.
Previously, single-replica instances created a general service
without -primary/-secondary suffixes, causing dashboard and
backup-cronjob to reference non-existent services.
Also fix duplicate YAML key in backup-cronjob template.
BREAKING CHANGE: Single-replica MariaDB instances will now have
service names with -primary/-secondary suffixes instead of the
bare instance name. Applications connecting via the old service
DNS name need to be updated.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
Replace separate pg_terminate_backend + DROP DATABASE calls with a
single DROP DATABASE ... WITH (FORCE) statement. This eliminates the
race window where new sessions could reconnect between termination
and drop. Available since PostgreSQL 13.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
## Summary
- Add bilateral VPC peering using Kube-OVN's native `vpcPeerings`
mechanism
- Auto-allocate link-local peering IPs (`169.254.0.0/16`)
deterministically from sorted VPC pair hash
- Add static routes support (`staticRoutes`) for fine-grained inter-VPC
routing
- Enrich ConfigMap with peer discovery info
- Add JSON Schema validation with `^tenant-` namespace pattern
enforcement
Closes#2151
## How it works
Each tenant independently declares peers in their VPC spec. The template
computes the remote VPC's internal ID using the same deterministic hash
formula, and derives complementary peering IPs from a sorted pair key.
Kube-OVN only activates the peering tunnel when **both sides** declare
each other — no custom controller needed.
Example (Tenant A):
```yaml
spec:
subnets:
- name: web
cidr: "172.16.0.0/24"
peers:
- vpcName: "backend-vpc"
tenantNamespace: "tenant-beta"
```
## Test plan
- [ ] `helm template` without peers → no `vpcPeerings` in output
(backward compatible)
- [ ] `helm template` with peers → correct `vpcPeerings` with
auto-allocated IPs
- [ ] Reciprocal peering: both sides reference each other with
complementary IPs in same /30
- [ ] Schema rejects `tenantNamespace` not matching `^tenant-`
- [ ] Deploy two VPCs with reciprocal peering on a live cluster →
Kube-OVN activates tunnel
- [ ] Remove one side → peering deactivated
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* VPC Peering: declare peer VPCs (tenant + name) to enable conditional
peering and automatic per-peer connection entries.
* Per-peer metadata: subnet/config outputs include peer-specific
connection details (remote VPC ID and local connect IP).
* Static Routes: optionally add custom CIDR routes with next-hop IPs for
a VPC.
* Values/schema: configuration and schema now accept peers and routes
arrays.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Previously, removing a database from values.databases had no effect —
the database and its associated roles persisted in PostgreSQL. This
made it impossible to cleanly delete databases via Helm.
Add two cleanup stages to the init script:
- Delete databases that have the 'database managed by helm' comment
but are no longer listed in values.databases
- Delete orphaned roles (db_admin, db_readonly) with proper membership
revocation before dropping
This mirrors the existing user deletion logic and completes the
declarative lifecycle for databases.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
ReadDir and Rename errors during migration are now hard failures
instead of warnings, preventing user data from becoming invisible
behind the /data subpath mount. Tolerate os.IsNotExist on Rename
for concurrent publish calls that already moved the file.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
- Use os.MkdirTemp instead of predictable path (fixes race condition/TOCTOU)
- Use defer for cleanup (unmount + remove temp dir)
- Handle os.ReadDir and os.Rename errors with klog warnings
- Log unmount failures instead of ignoring them
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Mount the /data subdirectory of the NFS export instead of the root,
so pods no longer see internal LINSTOR/CDI artifacts (disk.img,
lost+found). On first mount after upgrade, any existing user files
at the NFS root are automatically migrated into /data.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
## What this PR does
Adds infrastructure support for restricting tenant workloads to specific
data centers (or node groups) via SchedulingClass CRs.
- Adds `schedulingClass` parameter to the Tenant model, inherited by
child
tenants (children cannot override parent's scheduling constraints)
- Adds `scheduling.cozystack.io/class` label to tenant namespaces
- Adds SchedulingClass dropdown to the Tenant creation form in the
dashboard
- Extends lineage-controller-webhook to inject `schedulerName:
cozystack-scheduler`
and `scheduler.cozystack.io/scheduling-class` annotation into all Pods
in
namespaces with the scheduling label
- Webhook verifies the referenced SchedulingClass CR exists before
injection;
if missing (scheduler not installed), pods are left untouched
### Operators without native schedulerName support
The following operators do not support `schedulerName` in their CRDs,
but are still covered by the webhook-based approach since it mutates
pods directly:
- etcd-operator
- redis-operator (spotahome)
- mariadb-operator
- clickhouse-operator (altinity)
### Release note
```release-note
[scheduler] Add SchedulingClass support for tenant workloads.
Administrators can assign a SchedulingClass to a tenant, restricting
where its workloads are scheduled. The lineage-controller-webhook
injects the custom scheduler into all pods in the tenant namespace.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a schedulingClass parameter for tenant configuration; it can be
set in values, appears in schema/docs, inherits to namespaces, and is
included in exported tenant manifests.
* When present, the schedulingClass is propagated to namespace metadata
and applied to workloads so scheduler selection and scheduling
annotations reflect the setting.
* **Bug Fixes**
* Improved owner-resolution and labeling so resources and scheduling are
associated more accurately.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Import SchedulingClassAnnotation, SchedulingClassLabel, SchedulerName,
and GVR components from the cozystack-scheduler/pkg/apis sub-module
instead of defining them locally. This ensures the webhook and scheduler
stay in sync on label/annotation keys.
Also standardize the namespace label from scheduling.cozystack.io/class
to scheduler.cozystack.io/scheduling-class for consistency with the
scheduler, and resolve scheduling class from the owner Application CR
(via a new SchedulingClass() stub method) before falling back to the
namespace label.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
The required fields in schema are auto-generated by cozyvalues-gen
and must be kept in sync.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Matthieu <matthieu@hidora.com>
Remove sysctl DaemonSet in favor of operator's built-in setVMMaxMapCount
init container, fix schema conflicts with required+empty default, fix
update-versions.sh YAML output format, and use $(MAKE) in Makefile.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Matthieu <matthieu@hidora.com>
When an NFS-backed RWX volume is published to multiple VMs, the
CiliumNetworkPolicy egress rule only allowed traffic from the first VM.
The endpointSelector.matchLabels was set once on creation and never
broadened, causing NFS mounts to hang on all nodes except the first.
Switch from matchLabels to matchExpressions (operator: In) so the
selector can list multiple VM names. Rebuild the selector whenever
ownerReferences are added or removed.
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Fix versions.yaml to use unquoted keys for valid YAML mapping, and
use release-based naming for sysctl DaemonSet to avoid conflicts.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Matthieu <matthieu@hidora.com>
The label is read by the lineage-controller-webhook to inject
schedulerName and scheduling-class annotation into all pods
in the tenant namespace.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
Allow administrators to assign a SchedulingClass CR to a tenant.
The schedulingClass is inherited by child tenants and cannot be
overridden once set by a parent.
Assisted-By: Claude AI
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
<!-- 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
This PR adds version specific ubuntu base images to fix errors when base
image has new deb packages of kubeadm and kubelet installed, but at
runtime it was downgraded by replacing just binaries. Now update by
replacing binaries works as intended - latest patch version of minor
version used.
Core issue was in kubeadm<1.32 expecting conntrack binary in its
preflight checks but it was not found. It happened because kubelet deb
package dropped conntrack dependency since 1.32 (actually it absent in
1.31.14 too).
So now status of supported tenant k8s versions is:
- 1.30 - works because kubelet package provided conntrack, also
conntrack preflight check ignored (see 1.31).
- 1.31 - works because conntrack preflight check ignored (for some
reason kubelet 1.31.14 did't provide conntrack dependency, unlike
1.31.13 did).
- \>=1.32 - works because conntrack preflight check removed from
`kubeadm init` entirely.
Conntrack preflight check ignoring is legit for tenant kubernetes
clusters because until 1.32 it was used in kube-proxy but cozystack k8s
approach doesn't use kube-proxy (replaced with cilium).
Issue with conntrack may be mitigated with only `ignorePreflightErrors`,
but I think proper base image build will help to avoid similar bugs in
future.
### 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] Fixed tenant k8s older than 1.32 creation by adding version specific ubuntu base images
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added multi-version Kubernetes support with version-specific container
images.
* Enhanced compatibility with newer Kubernetes releases, including
version 1.31.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Migrates VictoriaLogs from the deprecated single-node `VLogs` CR to
`VLCluster` (cluster mode) with vlinsert/vlselect/vlstorage components
for reliability and horizontal scalability.
**Operator upgrade:**
- Upgrades victoria-metrics-operator from v0.55.0 to v0.68.1 to add
VLCluster CRD support
**VLCluster deployment:**
- Replaces `VLogs` (v1beta1) with `VLCluster` (v1) — 2 replicas per
component, consistent with VMCluster
- Adds VPA for all VLCluster components (vlinsert, vlselect, vlstorage)
- Updates WorkloadMonitors for the three-component architecture
**Endpoint updates:**
- Fluent-bit outputs: `vlogs-generic:9428` → `vlinsert-generic:9481`
- Grafana datasource: `vlogs-{name}:9428` → `vlselect-{name}:9471`
- ExternalName service: `vlogs-generic` → `vlinsert-generic`
**Migration (35 → 36):**
- Adds `helm.sh/resource-policy: keep` annotation to existing VLogs
resources so they are preserved during upgrade
- Users need to verify the new VLCluster is working, then optionally
migrate historical data and manually delete old VLogs resources
### Release note
```release-note
[monitoring] Migrate VictoriaLogs from single-node VLogs to VLCluster (cluster mode). Old VLogs resources are preserved with `helm.sh/resource-policy: keep` annotation. After upgrade, verify the new cluster is working, then optionally migrate historical data and delete old VLogs resources manually.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* CRD upgrade workflow with configurable hooks, Job, and ServiceAccount
support
* Monitoring storage split into vlinsert / vlselect / vlstorage with
corresponding VPAs
* Service traffic distribution option and optional shareProcessNamespace
toggle
* **Updates**
* VictoriaMetrics Operator bumped to v0.68.1
* Fluent Bit and Grafana endpoints/ports updated to new monitoring
targets
* Global extra-labels support for resources
* Migration target advanced to version 36
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- Add CiliumClusterwideNetworkPolicy for vmagent egress to virt-handler
- Restrict endpointSelector to vmagent pods only via app.kubernetes.io/name label
Signed-off-by: Mattia Eleuteri <mattia.eleuteri@hidora.io>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Implement bilateral VPC peering using Kube-OVN's native vpcPeerings
mechanism. Each VPC can declare peers by specifying the remote VPC name
and tenant namespace. Peering is only activated by Kube-OVN when both
sides declare each other, ensuring mutual consent.
Key features:
- Deterministic remote VPC ID resolution via sha256 hash
- Auto-allocated link-local peering IPs (169.254.0.0/16) derived from
sorted pair hash, eliminating manual IP coordination
- Static routes support for fine-grained inter-VPC routing
- ConfigMap enrichment with peer discovery info
- Schema validation enforcing tenant- namespace prefix pattern
Signed-off-by: Mattia Eleuteri <mattia.eleuteri@hidora.io>
Signed-off-by: mattia-eleuteri <mattia@hidora.io>
Kube-OVN reads MAC address exclusively from the pod annotation
ovn.kubernetes.io/mac_address, not from the IP resource spec.macAddress.
Without pod-level annotations, migrated VMs receive a new random MAC,
breaking OS-level network config that matches by MAC (e.g. netplan).
Add a Helm lookup for the Kube-OVN IP resource in the vm-instance chart
template. When the IP resource exists, its macAddress and ipAddress are
automatically injected as pod annotations. This removes the need for
fragile Flux postRenderers on the HelmRelease — the chart itself handles
MAC/IP preservation based on actual cluster state.
Remove the postRenderers approach from migration 29 since the chart now
handles this natively.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
<!-- 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
[docs] Fixed docs for managed apps
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
* Updated FoundationDB README title to "Managed FoundationDB Service"
* Improved Harbor README text formatting for consistency
* Corrected spelling and terminology errors in MariaDB README
* Enhanced MariaDB recovery documentation with additional command
example
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Replace deprecated single-node VLogs CR with VLCluster (cluster mode)
for reliability and horizontal scalability.
Changes:
- Replace VLogs (v1beta1) with VLCluster (v1) using vlinsert/vlselect/vlstorage
- Update fluent-bit outputs to vlinsert-generic:9481
- Update Grafana datasource to vlselect:9471
- Update ExternalName service from vlogs-generic to vlinsert-generic
- Add VPA for all VLCluster components
- Update WorkloadMonitors for three-component architecture
- Add migration 35 to preserve old VLogs resources with keep annotation
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Kirill Ilin <stitch14@yandex.ru>
## What this PR does
Combines and unifies COSI enhancements across seaweedfs and bucket
charts:
**SeaweedFS (extra + system charts):**
- Rename storage pool BucketClass suffix from `-worm` to `-lock`
- Rename parameter `disk` to `diskType` for consistency with COSI driver
- Reduce default object lock retention from 36500 to 365 days
- Add `-lock` BucketClass (COMPLIANCE mode, 365 days) for client and
system topologies
- Add `-readonly` BucketAccessClass with explicit `accessPolicy` for all
topologies
- Add explicit `accessPolicy: readwrite` on default BucketAccessClass
- Update pool name validation to reject `-lock` suffix (was `-worm`)
**Bucket app:**
- Add `locking` parameter: provisions from `-lock` BucketClass
- Add `storagePool` parameter: selects pool-specific BucketClass
- Replace hardcoded BucketAccess with `users` map — each entry creates a
BucketAccess with optional `readonly` flag
- Update dashboard RBAC to dynamically list user credential secrets
- Update ApplicationDefinition schema with new properties
**Breaking change:** empty `users: {}` (default) produces zero
BucketAccess resources. Existing buckets that relied on the implicit
default BucketAccess will need to define users explicitly.
### Release note
```release-note
[apps] Add locking, storagePool, and users configuration to bucket app; rename COSI BucketClass suffix from -worm to -lock
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Bucket locking with a shorter retention option, storage-pool
selectable bucket classes, and per-user access (per-user BucketAccess
and readonly controls)
* S3 Manager login mode: user login/logout, per-session credentials, and
new login UI
* **Behavior Changes**
* Credential handling changed to per-user secrets/label selection;
previously generated secrets removed; Ingress basic auth annotations
removed
* **Documentation**
* Added parameters: locking, storagePool, users (including per-user
readonly)
* **Updates**
* Updated COSI driver and S3 manager images
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Show only per-user credential secrets in the dashboard instead of
both the internal UI secret and per-user secrets.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Cilium's MTU auto-detection does not account for VXLAN overhead when
running inside KubeVirt VMs. The VM interface inherits MTU 1400 from
the parent OVN/Geneve overlay, and Cilium sets all interfaces
(cilium_vxlan, lxc*, cilium_host/net) to 1400 without subtracting
the 50-byte VXLAN encapsulation overhead.
This causes intermittent packet drops for large packets (TLS
handshakes, HTTP responses with data), resulting in timeouts and
499 errors for services running in tenant clusters.
Set MTU to 1350 (1400 - 50 VXLAN overhead) explicitly in the default
Cilium values for tenant Kubernetes clusters.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Remove the yq strip of properties from Makefile that was clearing
the schema, and run make generate to sync all generated files.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Create labeled secrets in the -system chart using lookup to copy
credentials from COSI-created secrets. The ApplicationDefinition
matchLabels selector exposes them in the dashboard.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
