Add helm-unittest tests for revisionHistoryLimit:
- Default value (3) verification
- Custom values support (0, 1, 5, 100)
- Ability to disable revision history
Add NOTES.txt with revisionHistoryLimit information:
- Show configured revision history limit
- Warning when disabled (0)
- Note for minimal history (1)
- Rollback command example for normal values
This parameter controls how many old ReplicaSets are retained
for rollback purposes, reducing etcd storage usage.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add revisionHistoryLimit parameter to control how many old ReplicaSets are
retained for rollback purposes, reducing etcd storage usage compared to
Kubernetes default of 10.
Changes:
- Add revisionHistoryLimit parameter in values.yaml (default: 3)
- Add revisionHistoryLimit to deployment.yaml spec
- Provide comprehensive documentation with recommendations
- Bump chart version 2.5.0 -> 2.5.1 (patch - minor enhancement)
- Add changelog annotation for Artifact Hub
Benefits:
- Reduce etcd storage usage (especially important in large clusters)
- Maintain reasonable rollback capability (3 previous versions)
- Allow customization based on deployment needs
- Can be set to null to use Kubernetes default (10)
Default rationale:
- 3 revisions provides sufficient rollback capability for most use cases
- Reduces cluster resource usage (etcd storage, API server load)
- Follows best practices from production Kubernetes deployments
- Users can override if they need more history
Example usage:
# Use default (3 revisions)
revisionHistoryLimit: 3
# Increase for critical deployments
revisionHistoryLimit: 10
# Use Kubernetes default (10)
revisionHistoryLimit: null
# Disable history (not recommended)
revisionHistoryLimit: 0
See: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Regenerate README.md from README.md.gotmpl template using helm-docs.
This adds the complete NetworkPolicy documentation section and updates
the values table with all networkPolicy configuration parameters.
The generated documentation includes:
- Updated version badge (2.6.0)
- Complete networkPolicy values table with descriptions
- Network Security section with examples and troubleshooting
- All parameters from values.yaml with auto-generated descriptions
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Bump chart version from 2.5.0 to 2.6.0 (minor version) for new feature.
Added artifacthub.io/changes annotations:
- NetworkPolicy support for network isolation and security hardening
- NOTES.txt with deployment status and configuration summary
This is a backward-compatible change:
- NetworkPolicy is disabled by default
- Existing installations will not be affected
- Users can opt-in to NetworkPolicy by setting networkPolicy.enabled=true
The NetworkPolicy feature provides enterprise-grade network security
controls for Jellyfin deployments in Kubernetes environments with
CNI plugin support.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add NOTES.txt template that displays helpful information after deployment:
- How to access Jellyfin (via Ingress or port-forward)
- NetworkPolicy status and configuration summary when enabled
- Ingress policy details (allowExternal, selectors, Prometheus)
- Egress policy details (DNS, internet access, restrictions)
- Warnings for misconfigurations (no selectors, DNS disabled)
- Compatibility note about CNI requirements
- Warning if NetworkPolicy + hostNetwork are both enabled
The NOTES provide immediate visibility into the deployment configuration
and help users quickly identify and troubleshoot network access issues.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add networkPolicy section to values.yaml with comprehensive configuration options:
- enabled: boolean flag to enable/disable NetworkPolicy (default: false)
- policyTypes: configure Ingress and/or Egress policies
- ingress: control which pods/namespaces can access Jellyfin
- allowExternal: permit access from any namespace (default: true)
- podSelector/namespaceSelector: restrict access to specific pods/namespaces
- customRules: advanced ingress rules for complex scenarios
- egress: control outbound connections from Jellyfin
- allowDNS: permit DNS resolution (default: true, required)
- allowAllEgress: permit all internet access (default: true)
- restrictedEgress: high-security mode with HTTPS-only metadata access
- customRules: advanced egress rules
- metrics: automatic Prometheus integration configuration
All parameters include detailed documentation explaining:
- Purpose and usage
- Default values and recommended settings
- Examples for common scenarios
- Security implications
The configuration supports use cases from simple deployments to
zero-trust environments while maintaining sensible defaults.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add comprehensive NetworkPolicy support for Jellyfin pod with:
- Ingress rules: configurable external access or namespace/pod selectors
- Egress rules: DNS resolution, metadata providers, custom rules
- Automatic Prometheus integration when metrics are enabled
- DLNA/hostNetwork detection with fail-safe error message
- Support for restrictedEgress mode for high-security environments
The NetworkPolicy is disabled by default to maintain backward compatibility.
When enabled, it provides fine-grained control over network traffic:
- Who can access Jellyfin (ingress)
- What external connections Jellyfin can make (egress)
NetworkPolicy requires CNI plugin support (Calico, Cilium, etc.) and
cannot be used with hostNetwork mode (DLNA). The template includes
validation to prevent misconfiguration.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>