Use Kubernetes Service DNS instead of Cluster IP for Extension Catalog imports

[rak-phillip]

When importing an Extension Catalog, Rancher Dashboard configures the catalog to point directly to the Kubernetes Service Cluster IP.

Relying on the static IP address makes the configuration prone to failure because Cluster IPs can be ephemeral; they might change if a service is recreated or modified.

Proposed Solution

Update the extension URL to use the internal Kubernetes DNS name instead of the clusterIP.

Using the DNS entry (service.namespace.svc) follows Kubernetes best practices and ensures that traffic is correctly routed to the service regardless of changes to the underlying Cluster IP.

Acceptance Criteria

• Extension Catalog imports use the SVC DNS name instead of the Cluster IP
• The generated URL follows the standard K8s format: http://<service-name>.<namespace>.svc:<port>
• Verified that the catalog remains accessible after import using the DNS-based URL

Additional details

📝 Note for testing:

I was able to confirm this change using ghcr.io/kubewarden/kubewarden-ui:1.1.0. After importing the extension catalog:

• Navigate to local cluster => Service Discovery => Services, filter by namespace cattle-ui-plugin-system. You should see a service named kubewarden-ui-svc
• Navigate to local cluster => Apps => Repositories and open kubewarden-ui-charts. Its URL should be http://kubewarden-ui-svc.cattle-ui-plugin-system.svc:8080. Previously, it would be an ip address

[github-actions]

🎯 Agentic Issue Triage

Summary: This task requests replacing the hardcoded clusterIP in the Extension Catalog import URL with a stable Kubernetes internal DNS name (<service>.<namespace>.svc:<port>), following K8s best practices for service discovery.

📍 Code Location

The bug is isolated to a single line in:

shell/dialog/ExtensionCatalogInstallDialog.vue, line 305

// Current (fragile):
this.extensionUrl = `(redacted) this.extensionSvc.spec.clusterIP }:${ this.extensionSvc.spec.ports[0].port }`;

// Proposed fix:
this.extensionUrl = `(redacted) serviceResource.metadata.name }.${ UI_PLUGIN_NAMESPACE }.svc:${ this.extensionSvc.spec.ports[0].port }`;

The serviceResource.metadata.name is already available in that scope (used just above on line 298–302 to fetch the service). UI_PLUGIN_NAMESPACE is already imported/used in the same file.

🔍 Analysis

• Type: Enhancement / reliability improvement
• Affected component: ExtensionCatalogInstallDialog.vue — the dialog used during "Import Extension Catalog" flows
• Risk: Low. The DNS format is equivalent and more stable. The clusterIP is ephemeral (e.g., service deletion/recreation resets it), whereas the DNS entry is stable as long as the service name and namespace remain the same.
• Kubernetes DNS format: `(redacted) — this resolves within the cluster via CoreDNS to the current ClusterIP automatically.

✅ Acceptance Criteria Checklist

• Replace this.extensionSvc.spec.clusterIP with the K8s DNS name in ExtensionCatalogInstallDialog.vue
• URL follows `(redacted) format
• Manually verify that an Extension Catalog import completes successfully and the catalog remains accessible after import
• Add/update unit tests in shell/dialog/__tests__/ (if they exist) or create them to cover URL generation logic
• Confirm behavior when the service has multiple ports (ensure correct port is still selected)

🧪 Testing Strategy

1. Manual: Import an Extension Catalog, then delete and recreate the backing service (causing a new clusterIP to be assigned). Verify the catalog URL (DNS-based) still resolves correctly — this would have broken with the old IP-based URL.
2. Unit test: Mock extensionSvc with a known name/namespace/port and assert that extensionUrl equals the expected DNS string.
3. Integration/E2E: Covered by QA/dev-automation label — confirm existing E2E coverage includes Extension Catalog import flow.

📚 Resources

• [Kubernetes DNS for Services and Pods]((kubernetes.io/redacted)
• [Rancher UI Extensions docs]((extensions.rancher.io/redacted)

Generated by Agentic Triage for issue #17171 · ◷

[github-actions]

🤖 Issue grooming analysis

This issue is well-groomed and ready for triage. Here's a summary:

• Problem: Extension Catalog imports use ephemeral Kubernetes Cluster IPs instead of stable Service DNS names, making extension configurations fragile if services are recreated.
• Proposed Solution: Update the URL generation logic to use the K8s DNS format (service).(namespace).svc:(port) instead of the raw Cluster IP.
• Acceptance Criteria: All three criteria are concrete and testable — use SVC DNS name, follow the correct K8s URL format, and verify catalog accessibility after import.
• Technical Context: Sufficient detail provided — the correct DNS format is specified, a real-world example (kubewarden-ui-svc.cattle-ui-plugin-system.svc:8080) is given, and a clear verification path via Apps > Repositories is described.
• Reproducibility: Clear verification steps are provided in the Additional Details section using ghcr.io/kubewarden/kubewarden-ui:1.1.0.

All four primary grooming criteria are satisfied. ✅

This analysis was generated automatically based on the repository's grooming checklist.

Generated by Daily Issue Grooming · ◷

[aalves08]

@rak-phillip this is on the Done col, but it's not closed... Also could there be the possibility that this could be related with #14453?