VKS private harbor repository fails to deploy with "Error: Conflicting resources: Package/[name] is already present but not identical (mismatch in spec.template)"

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

When attempting to deploy or synchronize a private package repository (such as a private Harbor registry) within a vSphere Kubernetes Service (VKS) or Tanzu environment, the deployment fails to complete.

When checking the status of the repository, it reports a Reconcile failed status:

tanzu package repository get standard-packages-private-repo -n vmware-system-tkg 
NAMESPACE:               vmware-system-tkg NAME:                    standard-packages-private-repo SOURCE:                  (imgpkg) <private-registry-url>/vks-standard-packages/<tag> STATUS:                  Reconcile failed: Deploying: Error (see .status.usefulErrorMessage for details) CONDITIONS:              - message: 'Deploying: Error (see .status.usefulErrorMessage for details)'

When checking the underlying kapp-controller deployment logs or the .status.usefulErrorMessage, a resource conflict is reported detailing a template mismatch:

kapp: Error: create package/cluster-autoscaler.kubernetes.vmware.com.<version> (data.packaging.carvel.dev/v1alpha1) namespace: vmware-system-tkg:Applying rebase rule to package/cluster-autoscaler.kubernetes.vmware.com.<version> (data.packaging.carvel.dev/v1alpha1) namespace: vmware-system-tkg:  Applying ytt (overlayContractV1):    Evaluating:      - fail: Error: Conflicting resources: Package/cluster-autoscaler.kubernetes.vmware.com.<version> is already present but not identical (mismatch in spec.template)

 

Environment

• VMware vSphere Kubernetes Service (VKS)
• Tanzu Kubernetes Grid (TKG)
• Tanzu Standard Packages
• Private Container Registries (Harbor)

Cause

This issue is caused by a built-in safety mechanism within Carvel's kapp-controller designed to prevent configuration drift.

The target namespace (e.g., vmware-system-tkg) contains orphaned legacy packages left over from a default or previous installation. Because these existing packages point to public Broadcom repository URLs, and your new repository is attempting to push packages that point to your internal private registry URLs, kapp detects a configuration mismatch (mismatch in spec.template). To prevent accidental overwrites, it safely aborts the deployment.

Resolution

To resolve this conflict, you must manually sweep out the orphaned packages from the namespace so the new private registry can take clean ownership.

Step 1: Verify no legacy repositories are active
Ensure there are no default repositories (such as tanzu-standard) still actively running and causing conflicts in the target namespace:

tanzu package repository list -n vmware-system-tkg

(If an old repository is present, delete it using tanzu package repository delete <name> -n vmware-system-tkg -y before proceeding).

Step 2: Delete the conflicting orphaned packages
Based on the error message in your logs, delete the specific conflicting packages blocking the deployment.

kubectl delete package #######.kubernetes.vmware.com.<version> -n vmware-system-tkg

Note: If you are absolutely certain there are no custom user-managed packages in this specific namespace that you need to preserve, you can quickly wipe the slate clean by running: kubectl delete packages --all -n vmware-system-tkg

Step 3: Verify the repository reconciliation
Once the stale packages are cleared, your private repository will automatically attempt to deploy on its next sync loop. Verify the status successfully flips to Reconcile succeeded:

tanzu package repository get standard-packages-private-repo -n vmware-system-tkg

Once the repository successfully reconciles, the new packages pointing to your private registry will be available for installation.