versions:
  - additionalPrinterColumns:
    - description: 'CreationTimestamp is a timestamp representing the server time
        when this object was created. It is not guaranteed to be set in happens-before
        order across separate operations. Clients may not set this value. It is represented
        in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for

  // when replacing pods on nodes, or when scaling down. The default policy is
  // `OrderedReady`, where pods are created in increasing order (pod-0, then
  // pod-1, etc) and the controller will wait until each pod is ready before
  // continuing. When scaling down, the pods are removed in the opposite order.
  // The alternative policy is `Parallel` which will create pods in parallel

    # Kubernetes >=v1.11.0 will create two PriorityClass, including system-cluster-critical and
    # system-node-critical, it is better to configure this in order to make sure your Istio pods
    # will not be killed because of low priority class.
    # Refer to https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass
    # for more detail.

	tests := []struct {
		name    string
		input   map[string]*discovery.DiscoveryResponse
		want    string
		wantErr bool
	}{
		{
			name: "prints multiple istiod inputs to buffer in alphabetical order by pod name",
			input: map[string]*discovery.DiscoveryResponse{
				"istiod1": xdsResponseInput("istiod1", []clientConfigInput{
					{
						proxyID:        "proxy1",
						clusterID:      "cluster1",

      name: Status
      type: string
    - description: 'CreationTimestamp is a timestamp representing the server time
        when this object was created. It is not guaranteed to be set in happens-before
        order across separate operations. Clients may not set this value. It is represented
        in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for

The original version of this file is located at /manifests directory.
If you want to make a change in this file, edit the original one and run "make gen".

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).

  optional WebhookClientConfig clientConfig = 2;

  // Rules describes what operations on what resources/subresources the webhook cares about.
  // The webhook cares about an operation if it matches _any_ Rule.
  // However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks
  // from putting the cluster in a state which cannot be recovered from without completely

# See the License for the specific language governing permissions and
# limitations under the License.
#
# Compare 2 multi document kubernetes yaml files
# It ensures that order does not matter
#
from __future__ import print_function
import argparse
import datadiff
import sys
import yaml  # pyyaml

# returns fully qualified resource name of the k8s resource

  // +optional
  optional k8s.io.apimachinery.pkg.apis.meta.v1.Time startTime = 2;

  // Represents time when the job was completed. It is not guaranteed to
  // be set in happens-before order across separate operations.
  // It is represented in RFC3339 form and is in UTC.
  // The completion time is only set when the job finishes successfully.
  // +optional

This offered performance benefits that were too large to leave on the table, as well as opportunities to tune to our specific needs.

## Configuration protocol

Ztunnel, of course, needs to be dynamically configured in order to make decisions on how it should handle traffic.
For this purpose, we chose to use xDS transport protocol due to our expertise and existing infrastructure, and because the protocol is well suited to our needs.