}

// PrintWorkloadDump prints the relevant workloads in the config dump to the ConfigWriter stdout
func (c *ConfigWriter) PrintWorkloadDump(filter WorkloadFilter, outputFormat string) error {
	zDump := c.ztunnelDump
	filteredWorkloads := []*ZtunnelWorkload{}
	for _, workload := range zDump.Workloads {
		if filter.Verify(workload) {
			filteredWorkloads = append(filteredWorkloads, workload)
		}
	}

	cmd := &cobra.Command{
		Use:   "workload [<type>/]<name>[.<namespace>]",
		Short: "Retrieves workload configuration for the specified Ztunnel pod.",
		Long:  `Retrieve information about workload configuration for the Ztunnel instance.`,
		Example: `  # Retrieve summary about workload configuration for a randomly chosen ztunnel.
  istioctl ztunnel-config workload

  # Retrieve summary of workloads on node XXXX for a given Ztunnel instance.

	d := c.ztunnelDump
	workloads := maps.Values(d.WorkloadState)
	workloads = slices.SortFunc(workloads, func(a, b WorkloadState) int {
		if r := cmp.Compare(a.Info.Namespace, b.Info.Namespace); r != 0 {
			return r
		}
		return cmp.Compare(a.Info.Namespace, b.Info.Namespace)
	})
	workloads = slices.FilterInPlace(workloads, func(state WorkloadState) bool {

However, one interesting aspect is how these policies associate with workloads.
Istio's AuthorizationPolicy has label selectors.
However, we intentionally do not send those as part of the Workload API, in order to keep the size low.

The obvious solution to this is to put the list of selected workloads into the policy itself.
However, this means anytime a workload changes (often), we need to update the policy.

			if cw.ztunnelDump == nil {
				if tt.wantConfigs != 0 {
					t.Errorf("wanted some configs loaded but config dump was nil")
				}
			} else if len(cw.ztunnelDump.Workloads) != tt.wantConfigs {
				t.Errorf("wanted %v configs loaded in got %v", tt.wantConfigs, len(cw.ztunnelDump.Workloads))
			}
			if tt.wantErr {
				assert.Error(t, err)
			} else {
				assert.NoError(t, err)
			}
		})
	}
}

# This shows an example local config for ztunnel that adds a workload for localhost.
# This allows local testing by sending requests through the local ztunnel to other servers running on localhost.
workloads:
- uid: cluster1//v1/Pod/default/local
  name: local
  namespace: default
  serviceAccount: default
  workloadIps: ["127.0.0.1"]
  protocol: HBONE
  node: local
  network: ""
  services:
    "default/example.com":
      80: 8080

	Namespace string         `json:"namespace"`
	Hostname  string         `json:"hostname"`
	Addresses []string       `json:"addresses"`
	Ports     map[string]int `json:"ports"`
}

type ZtunnelDump struct {
	Workloads    map[string]*ZtunnelWorkload `json:"by_addr"`
	Services     map[string]*ZtunnelService  `json:"by_vip"`
	Certificates []*CertsDump                `json:"certificates"`
}

type CertsDump struct {

	Scope     string             `json:"scope"`
	Action    string             `json:"action"`
	Rules     [][][]*PolicyMatch `json:"rules"`
}

type ZtunnelDump struct {
	Workloads     map[string]*ZtunnelWorkload `json:"workloads"`
	Services      map[string]*ZtunnelService  `json:"services"`
	Policies      map[string]*ZtunnelPolicy   `json:"policies"`
	Certificates  []*CertsDump                `json:"certificates"`

  // More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector
  // +optional
  optional bool manualSelector = 5;

  // Describes the pod that will be created when executing a job.
  // The only allowed template.spec.restartPolicy values are "Never" or "OnFailure".
  // More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

The install is organized in 'environments' - each environment consists of a set of components
in different namespaces that are configured to work together. Regardless of 'environment',
workloads can talk with each other and obey the Istio configuration resources, but each environment
can use different Istio versions and different configuration defaults.