// otherwise identical (parallel requests, requests when earlier requests did not modify etc)
  // The UID is meant to track the round trip (request/response) between the KAS and the WebHook, not the user request.
  // It is suitable for correlating log entries between the webhook and apiserver, for either auditing or debugging.
  optional string uid = 1;

	// once the pod restarts (in CrashLoopBackoff), which can take some time.
	// We don't want to constantly try to apply the iptables rules, which is unneeded and will fail.
	// Instead, we track which UIDs we repaired and skip them if already repaired.
	//
	// An alternative would be to write something to the Pod (status, annotation, etc).
	// However, this requires elevated privileges we want to avoid

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "fake.docker.io/google-samples/hello-go-gke:1.0"
          ports:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  strategy: {}
  template:
    metadata:
      annotations:
        prometheus.io/path: /stats/prometheus
        prometheus.io/port: "15020"
        prometheus.io/scrape: "true"

- [istio/ztunnel](https://github.com/istio/ztunnel). The repository contains the Rust implementation of the ztunnel
component of Ambient mesh.

## Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

- **Epic**. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things.

Running the controller actually starts processing things.
Normally, this just means running the queue.
All informers created by `kube.Client` are kept track in the client, and started in one go with `RunAndWait` in one centralized call.
As a result, each individual controllers should simply wait until informers have synced, then run the queue to start processing things.

}

// Prime loads the config dump into the writer ready for printing
func (c *ConfigWriter) Prime(b []byte) error {
	cd := ZtunnelDump{}
	// TODO(fisherxu): migrate this to jsonpb when issue fixed in golang
	// Issue to track -> https://github.com/golang/protobuf/issues/632
	err := json.Unmarshal(b, &cd)
	if err != nil {
		return fmt.Errorf("error unmarshalling config dump response from ztunnel: %v", err)
	}
	c.ztunnelDump = &cd
	return nil

  // +listType=map
  // +listMapKey=name
  // +optional
  repeated ResourceClaimSchedulingStatus resourceClaims = 1;
}

// ResourceClaim describes which resources are needed by a resource consumer.
// Its status tracks whether the resource has been allocated and what the
// resulting attributes are.
//
// This is an alpha type and requires enabling the DynamicResourceAllocation
// feature gate.
message ResourceClaim {

  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  template:
    metadata:
      annotations:
        proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  name: hello
spec:
  replicas: 7
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  strategy: {}
  template:
    metadata:
      annotations:
        prometheus.io/path: /stats/prometheus
        prometheus.io/port: "15020"
        prometheus.io/scrape: "true"