[PoC] feat: add targetRef field to ZTunnel CRD #1259

dgn · 2025-10-07T08:57:31Z

This adds a targetRef field to the ZTunnel CRD, allowing users to keep their ZTunnel config in sync with what they already defined in the Istio or IstioRevision CRD.

codecov · 2025-10-07T09:01:40Z

Codecov Report

❌ Patch coverage is 49.38272% with 41 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.10%. Comparing base (eb2b8c1) to head (926dd12).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
controllers/ztunnel/ztunnel_controller.go	35.71%	34 Missing and 2 partials ⚠️
pkg/revision/references.go	78.26%	4 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1259       +/-   ##
===========================================
+ Coverage   65.19%   77.10%   +11.90%     
===========================================
  Files          39       44        +5     
  Lines        2497     2878      +381     
===========================================
+ Hits         1628     2219      +591     
+ Misses        721      548      -173     
+ Partials      148      111       -37

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

dgn · 2025-10-07T09:53:25Z

This should support most use cases including RevisionBased update strategies already. Another thing we could add is making the IstioRevisionController aware of the link - currently, users have to configure the ZTunnel namespace on their Istio/IstioRevision:

spec:
  values:
    pilot:
      trustedZtunnelNamespace: ztunnel

This could be inferred at install time by looking for a ZTunnel resource that has a targetRef pointing to this IstioRevision and then pulling the spec.namespace value from that ZTunnel.

FilipB · 2025-10-07T12:58:45Z

controllers/ztunnel/ztunnel_controller.go

 		return fmt.Errorf("failed to apply profile: %w", err)
 	}

+	// Apply values from referenced IstioRevision first


Maybe it would make sense to warn users when setting the same config in both ztunnel and Istio to different values?

I don't think we need to warn users - their settings will always take precedence. By default, they should only configure the version and targetRef

Yeah, a warning might imply that something is wrong. Can we add a log message saying that user setting from ztunnel are used?

hmm. as we're just merging the fields I don't think we have the ability to give that sort of granular feedback. or rather, we'd have to add a bunch of logic in order to do that. maybe just documenting the behavior is enough?

Sure, works for me.

FilipB · 2025-10-07T13:00:15Z

tests/e2e/ambient/ambient_test.go

 					BeforeAll(func() {
 						common.CreateIstio(k, version.Name, `
 values:
+  global:


Should this be added to samples?

I'm not sure about the global setting. I will add the targetRef to the sample though

tests/e2e/ambient/ambient_test.go

sridhargaddam

Thanks @dgn.

sridhargaddam · 2025-10-09T09:41:52Z

api/v1alpha1/ztunnel_types.go

 	State ZTunnelConditionReason `json:"state,omitempty"`
+
+	// IstioRevision stores the name of the referenced IstioRevision
+	IstioRevision string `json:"istioRevision"`


Do we have to use omitempty here (if users does not specify targetRef in spec)?

good point, will add

sridhargaddam · 2025-10-09T09:45:40Z

controllers/ztunnel/ztunnel_controller.go

 		return fmt.Errorf("failed to apply profile: %w", err)
 	}

+	// Apply values from referenced IstioRevision first


Yeah, a warning might imply that something is wrong. Can we add a log message saying that user setting from ztunnel are used?

sridhargaddam · 2025-10-09T10:17:18Z

pkg/revision/references.go

 	return podAnnotations[constants.IstioRevLabel]
 }
+
+func GetIstioRevisionFromTargetReference(ctx context.Context, client client.Client, ref v1.TargetReference) (*v1.IstioRevision, error) {


It would be good to include unit tests for this API.

sridhargaddam · 2025-10-09T10:20:23Z

pkg/revision/references.go

+	var revisionName string
+	switch ref.Kind {
+	case v1.IstioRevisionKind:
+		revisionName = ref.Name


Should we add input validation for targetReference?

sridhargaddam · 2025-10-09T10:33:57Z

controllers/ztunnel/ztunnel_controller.go

+	ztunnels := v1alpha1.ZTunnelList{}
+	err := r.Client.List(ctx, &ztunnels, &client.ListOptions{})
+	if err != nil {
+		return nil


Shall we add a log message here when err != nil?

sridhargaddam · 2025-10-09T10:36:26Z

tests/e2e/ambient/ambient_test.go

  version: %s
  namespace: %s
+  targetRef:
+    kind: Istio


Do you think we will require a test case without the targetRef?

sridhargaddam · 2025-10-09T10:40:09Z

This should support most use cases including RevisionBased update strategies already. Another thing we could add is making the IstioRevisionController aware of the link - currently, users have to configure the ZTunnel namespace on their Istio/IstioRevision:
spec:
  values:
    pilot:
      trustedZtunnelNamespace: ztunnel
This could be inferred at install time by looking for a ZTunnel resource that has a targetRef pointing to this IstioRevision and then pulling the spec.namespace value from that ZTunnel.

This is a good idea.

sridhargaddam · 2025-10-09T10:42:04Z

api/v1alpha1/ztunnel_types.go

+
+	// The Istio control plane that this ZTunnel instance is associated with. Valid references are Istio and IstioRevision resources, Istio resources are always resolved to their current active revision.
+	// Values relevant for ZTunnel will be copied from the referenced IstioRevision resource, these are `spec.values.global`, `spec.values.meshConfig`, `spec.values.revision`.
+	TargetRef *v1.TargetReference `json:"targetRef,omitempty"`


Probably we should add a comment here saying that if users specify targetRef along with additional config, the user values will take precedence.

zmiklank · 2025-10-15T07:27:34Z

Hi @dgn, do you think it could be useful to add info about this API change into ZTunnel CRD docs too?

This adds a `targetRef` field to the ZTunnel CRD, allowing users to keep their ZTunnel config in sync with what they already defined in the `Istio` or `IstioRevision` CRD. Signed-off-by: Daniel Grimm <[email protected]>

dgn requested a review from a team as a code owner October 7, 2025 08:57

dgn added the do-not-merge/work-in-progress label Oct 7, 2025

istio-testing added the size/L label Oct 7, 2025

dgn force-pushed the ztunnel-targetref branch 5 times, most recently from bcd9f0d to b655b0e Compare October 7, 2025 09:50

FilipB reviewed Oct 7, 2025

View reviewed changes

dgn force-pushed the ztunnel-targetref branch from b655b0e to 88ed7f4 Compare October 8, 2025 15:32

sridhargaddam reviewed Oct 9, 2025

View reviewed changes

feat: add targetRef field to ZTunnel CRD

926dd12

This adds a `targetRef` field to the ZTunnel CRD, allowing users to keep their ZTunnel config in sync with what they already defined in the `Istio` or `IstioRevision` CRD. Signed-off-by: Daniel Grimm <[email protected]>

dgn force-pushed the ztunnel-targetref branch from 88ed7f4 to 926dd12 Compare October 21, 2025 14:59

[PoC] feat: add targetRef field to ZTunnel CRD #1259

Are you sure you want to change the base?

[PoC] feat: add targetRef field to ZTunnel CRD #1259

Uh oh!

Conversation

dgn commented Oct 7, 2025

Uh oh!

codecov bot commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

dgn commented Oct 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sridhargaddam left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sridhargaddam commented Oct 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zmiklank commented Oct 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov bot commented Oct 7, 2025 •

edited

Loading