vmwaresaas.jfrog.io Decommissioning for Non-Airgap Environment

Products

VMware Telco Cloud Automation VMware Telco Cloud Platform

Issue/Introduction

Non-Airgap VMware Telco Cloud Automation (TCA) environments running versions 3.2 and earlier are impacted by the decommissioning of the legacy repository.

While the Data Plane (running CNFs/CaaS) will remain stable, the Management Plane is impacted.

Any task requiring external repository access will fail.

Symptoms include:

Lifecycle Management Failure: All Day-2 operations including Scaling, Upgrading, and Healing fail as the required initialization scripts and metadata cannot be retrieved.
Troubleshooting Failure: Integrated tools (Pod Debugger, Open Terminal) fail to launch with ImagePullBackOff errors because sidecar images are inaccessible.
Deployment Block: Attempts to deploy net-new clusters or resources fail during the provisioning phase.

Note: Running production services (CNFs/CaaS) are not down, but they are effectively frozen and cannot be modified until the platform is upgraded.

Environment

TCA: 2.3, 3.0, 3.1, 3.1.1, 3.2, 3.3, 3.4 (Non-Airgap)

Cause

The legacy repository (vmwaresaas.jfrog.io) is planned to be decommissioned on February 6th 2026.

Dependency Failure: Non-Airgap environments rely on real-time execution of scripts from the upstream repository during every lifecycle operation.
Hardcoded Configuration: TCA versions 3.2 and earlier contain hardcoded references to the retired JFrog URL.
Orchestration Failure: When a Scale, Upgrade, or Heal operation is triggered, the orchestration engine attempts to reach the defunct URL. It receives a 404 Not Found or Connection Refused error, causing the entire workflow to fail.
Repository Migration: All software artifacts have been migrated to packages.broadcom.com to implement enhanced security measures for sensitive repository data

Resolution

To restore repository connectivity and Day-2 management capabilities, perform the following steps in order:

Prerequisites:
- K8s Version Check: Workload clusters must be at 1.24.10 or higher prior to the TCA 3.3 migration.
Platform Upgrade:
- Upgrade TCA: Upgrade TCA Management and Control Plane appliances to version 3.3 or higher. This updates the TCA to point to the new Broadcom repository.
  - See: Upgrading Telco Cloud Automation
Infrastructure & Management Cluster Updates:
- Upgrade Management Add-ons: Post-upgrade, you must update the Management Cluster add-ons to ensure compatibility with the new repo structure.
  - See: Upgrade Mgmt Cluster K8s Version
- Upgrade Harbor: Upgrade Harbor instances to version 2.10 or 2.13. These versions must be sourced from the new Broadcom repository to maintain trust and image availability.
  - See: Upgrading an Offline/Standalone Harbor Registry on vSphere
Workload Cluster Remediation:
- Update BYOI Templates: All TKG Workload clusters must be updated with the latest BYOI (Bring Your Own Image) templates referencing the new repository. BYOI Template download is available in the Drivers & Tools section at VMware Telco Cloud Automation 3.3
  - Note: This process triggers a rolling redeployment of all workload cluster nodes.
  - Note: Single Node Clusters will experience a total service outage during this redeployment.

Note: From TCA 3.4 and onward Non-Airgap Environments are no longer a supported deployment type.

Additional Information

FAQ (Non-Airgap Environment)

Question	Answer
What is the immediate impact of the JFrog decommissioning?	Scaling, upgrading, and deploying net-new resources will fail because the system cannot pull required metadata and scripts.
What if I upgraded to TCA 3.3/3.4 prior to this notice?	The platform upgrade alone is insufficient. You must manually execute the BYOI Template Update across all clusters to complete the fix and repoint them to the Broadcom repository. (See: Step 4 above.)
What operations will fail if I don't upgrade?	Day-2 lifecycle tasks (scaling, upgrading, deploying new resources) and integrated troubleshooting utilities will fail.
Why did my Pod Debugger stop working?	These features pull sidecar images hardcoded to the JFrog path and will fail with an`ImagePullBackOff`error.
Will current production services go down?	No. Running services are stable but they cannot be scaled, upgraded, or healed until the platform is updated with the new repository.
Can I fix this without a full platform upgrade?	No. TCA 3.2 and below have the old URL hardcoded. An upgrade to TCA 3.3 or higher is the only supported path to repoint the orchestration engine to the new Broadcom repository. This process will also require the BYOI template rolling upgrade across all TKG clusters.
Can I edit the cluster YAML to fix the repo?	No. Pointers are embedded in core services and node configurations. A platform upgrade to 3.3 or higher is the only supported fix.
Does this affect my Harbor registry?	Yes. Existing Harbor registries (2.8 or below) do not support Broadcom's OCI-compliant artifacts. Upgrading to Harbor 2.10 or 2.13 is mandatory.
Are there Kubernetes version prerequisites for this upgrade?	Yes. Upgrade all TKG clusters to at least 1.24.10 (1.27+ recommended) before moving to TCA 3.3 to avoid migration failures. See: Upgrade Telco Cloud Automation from 2.3 to 3.3
Will my workload clusters be rebooted during this process?	Yes. Updating the BYOI templates triggers a rolling redeployment of all worker and control plane nodes.
What is the risk of the "Rolling Redeploy"?	Updating BYOI templates replaces every node. Ensure workloads have Pod Disruption Budgets configured to prevent service outages.
How do I handle Single Node Clusters (SNC)?	SNCs do not support rolling updates. Updating the BYOI template on an SNC will result in a temporary total outage while the node is replaced.
What happens to custom TKG Add-ons?	You must verify Add-on metadata is updated to the Broadcom repository; otherwise, they will fail to start after the next node reboot.