PodAdded(ctx context.Context, pod *v1.Pod, netns Netns) error
	Close() error
}

/*
To clean up stale ztunnels

	we may need to ztunnel to send its (uid, bootid / boot time) to us
	so that we can remove stale entries when the ztunnel pod is deleted
	or when the ztunnel pod is restarted in the same pod (remove old entries when the same uid connects again, but with different boot id?)

// instantiate new PersistentVolumes.
//
// For example this can express things like:
// - StorageClass "standard" has "1234 GiB" available in "topology.kubernetes.io/zone=us-east1"
// - StorageClass "localssd" has "10 GiB" available in "kubernetes.io/hostname=knode-abc123"
//
// The following three cases all imply that no capacity is available for
// a certain combination:

	uid := fixture.uid

	m, fds := readRequest(t, ztunClient)
	// we got am essage from ztun, so it should have observed us being connected
	mt.Assert(ztunnelConnected.Name(), nil, monitortest.Exactly(1))

	// we should get the fd to dev null. note that we can't assert the fd number
	// as the kernel may have given us a different number that refers to the same file.
	assert.Equal(t, len(fds), 1)

name: Bug report
description: Report a bug to help us improve Istio
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: checkboxes
    id: security-check
    attributes:
      label: Is this the right place to submit this?
      description: |-
        This is used to report product bugs:

{{/*
Complex logic ahead...
We have three sets of values, in order of precedence (last wins):
1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).

{{/*
Complex logic ahead...
We have three sets of values, in order of precedence (last wins):
1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).

**Please provide a description of this PR:**



**To help us figure out who should review this PR, please put an X in all the areas that this PR affects.**

- [ ] Ambient
- [ ] Configuration Infrastructure
- [ ] Docs
- [ ] Dual Stack
- [ ] Installation
- [ ] Networking
- [ ] Performance and Scalability
- [ ] Policies and Telemetry
- [ ] Security
- [ ] Test and Release
- [ ] User Experience
- [ ] Developer Infrastructure

Complex logic ahead...
We have three sets of values, in order of precedence (last wins):
1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).

Complex logic ahead...
We have three sets of values, in order of precedence (last wins):
1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).

Complex logic ahead...
We have three sets of values, in order of precedence (last wins):
1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).