<!-- Thank you for making a contribution! Here are some tips for you: - Use Conventional Commits for the PR title: `type(scope): description` - Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore - Scopes are not an exhaustive list — pick the most specific scope for the change and extend the list when a genuinely new area appears. Examples: - System components: dashboard, platform, operator, cilium, kube-ovn, linstor, fluxcd, cluster-api - Managed apps: postgres, mariadb, redis, kafka, clickhouse, virtual-machine, kubernetes - Development and maintenance: api, hack, tests, ci, docs, maintenance - Breaking changes: append `!` after type/scope (`feat(api)!: ...`) or add a `BREAKING CHANGE:` footer - 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 Harbor's app chart renders a nested HelmRelease that owns the whole workload: the Deployments, the inline RedisFailover and its volume. It had no install strategy, so it got Flux's default, and install remediation is an uninstall in every case Flux offers. A first install that misses its budget gets torn down, and the next one provisions the redis volume and runs the master election again from scratch. That happens on a loaded runner. harbor-core waits on redis, redis waits on its volume and the master election, and the nginx Deployment hits the default `progressDeadlineSeconds` of 600s. Flux reads that as a stalled resource and fails the install early. The e2e wait budget is 10m, the same as the deadline, so after a teardown the second attempt has less time than a first install needs. `RetryOnFailure` keeps the manifests applied and retries as an upgrade. Nothing is deleted, so the volume, the elected master and harbor-core's startup all survive, and the retry costs 30s instead of a full install. A Deployment clears `ProgressDeadlineExceeded` by itself once its pods go ready, so the retry lands as soon as the stack converges. This drops the teardown, not the deadline. The suite applies the release in one step and waits for it in later ones, so part of the budget is still left when the fail-early hits. That leftover is useless to a fresh install and usable to a retry that resumes. Whether the deadline or the budget also needs moving is a separate question, and an early deadline only becomes safe once a failed install stops being torn down. In production the win holds without any of that: a slow first install no longer deletes the Redis volume and the database. Both actions carry the strategy. The controller runs the retry of a failed install as an upgrade, so with install alone the retry's own failure falls through to upgrade remediation. The remediation blocks stay: an absent release consults install, an out-of-sync one consults upgrade, both by retry count rather than by strategy. It goes on the nested release, not the parent. The parent is built from the Application by the apiserver, which already stamps this strategy on both actions. The nested one owns the workload and the volume a remediation deletes. Same shape as the tenant CNI and CSI releases in #3552 and #3581, and the unit test follows theirs. Relates to #3445. ### Screenshots <!-- REQUIRED for UI changes: attach screenshots or screen recordings demonstrating the visual impact of your changes. PRs with UI changes without screenshots will not be merged. --> ### Downstream repositories <!-- Cozystack is upstream for repositories that are NOT kept in sync with it automatically, and nothing in CI compares the two sides, so a change here can break them silently. Which change forces what, and which file to touch, is the trigger map in docs/agents/contributing.md under "Downstream Repositories". Walk it before you tick anything. IF YOU ARE AN AI AGENT OR AN LLM, THIS IS PART OF THE TASK, NOT A FORM TO FILL IN: 1. Walk the trigger map against the actual diff of this PR, file by file. Do not decide from the PR title or from your memory of what you changed. 2. For every repository you tick, open the follow-up PR there and link it on the same line. A ticked box with no link claims work that does not exist, which is worse than an empty box. Search that repository for an open PR or issue covering it first, and link that instead of filing a duplicate. 3. When the follow-up is out of scope, or needs a decision that is not yours to make, open an issue in that repository instead, link that, and say so in the PR body. Do not push a speculative PR into another repository just to fill a line here. 4. Do not tick "No downstream repository is affected" to make the checklist go away. If you are unsure, leave every box empty and say so in the PR body, so a human decides. --> - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note <!-- Write a release note: - Explain what has changed internally and for users. - Start with the same `type(scope):` prefix as in the PR title - Follow the guidelines at https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md. --> ```release-note fix(harbor): retry a failed Harbor install instead of uninstalling the release, so a slow first install no longer deletes the Redis volume and starts over ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Harbor installations and upgrades now automatically retry every 30 seconds when failures occur. * Existing unlimited remediation retries remain available for both operations. * **Tests** * Added automated coverage to verify Harbor retry behavior and remediation settings. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Managed Harbor Container Registry
Harbor is an open-source trusted cloud-native registry project that stores, signs, and scans content.
Prerequisites
The Cozystack Harbor app stores its registry data exclusively in S3-compatible object storage: the chart pins the registry backend to S3 and exposes no filesystem option. That bucket is provisioned through COSI (objectstorage.k8s.io) from a SeaweedFS deployment, so before deploying Harbor the tenant must have SeaweedFS available — enabled on the same tenant or inherited from a parent tenant (the resolved class is propagated down the tenant tree, surfaced as the namespace.cozystack.io/seaweedfs namespace label).
Enable it by setting seaweedfs: true on the tenant (or a parent tenant):
seaweedfs: true
Without object storage in the tenant chain, Harbor cannot provision its registry bucket: the <release>-registry BucketClaim/BucketAccess never produces the <release>-registry-bucket credentials secret, so the Harbor HelmRelease stays unreconciled, waiting on BucketInfo.
storageClassis annotated as immutable in the chart schema — seedocs/storage-immutability.mdfor the contract and which consumers enforce it.
Parameters
Common parameters
| Name | Description | Type | Value |
|---|---|---|---|
host |
Hostname for external access to Harbor (defaults to 'harbor' subdomain for the tenant host). | string |
"" |
storageClass |
StorageClass used to store the data. | string |
"" |
Component configuration
| Name | Description | Type | Value |
|---|---|---|---|
core |
Core API server configuration. | object |
{} |
core.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
core.resources.cpu |
Number of CPU cores allocated. | quantity |
"" |
core.resources.memory |
Amount of memory allocated. | quantity |
"" |
core.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.small |
registry |
Container image registry configuration. | object |
{} |
registry.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
registry.resources.cpu |
Number of CPU cores allocated. | quantity |
"" |
registry.resources.memory |
Amount of memory allocated. | quantity |
"" |
registry.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.small |
jobservice |
Background job service configuration. | object |
{} |
jobservice.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
jobservice.resources.cpu |
Number of CPU cores allocated. | quantity |
"" |
jobservice.resources.memory |
Amount of memory allocated. | quantity |
"" |
jobservice.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.nano |
trivy |
Trivy vulnerability scanner configuration. | object |
{} |
trivy.enabled |
Enable or disable the vulnerability scanner. | bool |
true |
trivy.size |
Persistent Volume size for vulnerability database cache. | quantity |
5Gi |
trivy.resources |
Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. |
object |
{} |
trivy.resources.cpu |
Number of CPU cores allocated. | quantity |
"" |
trivy.resources.memory |
Amount of memory allocated. | quantity |
"" |
trivy.resourcesPreset |
Default sizing preset used when resources is omitted. |
string |
t1.nano |
database |
PostgreSQL database configuration. | object |
{} |
database.size |
Persistent Volume size for database storage. | quantity |
5Gi |
database.replicas |
Number of database instances. | int |
2 |
redis |
Redis cache configuration. | object |
{} |
redis.size |
Persistent Volume size for cache storage. | quantity |
1Gi |
redis.replicas |
Number of Redis replicas. | int |
2 |