//
// 	(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
//
// <decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber>
// ```
//
// No matter which of the three exponent forms is used, no quantity may represent
// a number greater than 2^63-1 in magnitude, nor may it have more than 3 decimal
// places. Numbers larger or more precise will be capped or rounded up.

// - 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:
// - no object exists with suitable topology and storage class name
// - such an object exists, but the capacity is unset

  // value automatically if one of them is empty and the other is non-empty.
  // When namespace is specified in dataSourceRef,
  // dataSource isn't set to the same value and must be empty.
  // There are three important differences between dataSource and dataSourceRef:
  // * While dataSource only allows two specific types of objects, dataSourceRef
  //   allows any non-core object, as well as PersistentVolumeClaim objects.

{{/*
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).

WARNING: DO NOT EDIT, THIS FILE IS A PROBABLY COPY.
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)

WARNING: DO NOT EDIT, THIS FILE IS A PROBABLY COPY.
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)

	"istio.io/istio/pkg/kube"
	"istio.io/istio/pkg/test/util/assert"
)

type execTestCase struct {
	args     []string
	revision string
	noIstiod bool

	// Typically use one of the three
	expectedOutput string // Expected constant output
	expectedString string // String output is expected to contain

	wantException bool
}

func TestInternalDebug(t *testing.T) {
	cases := []execTestCase{

		})
	}
}

type addObject interface {
	Add(obj runtime.Object)
}

type execTestCase struct {
	execClientConfig map[string][]byte
	args             []string

	// Typically use one of the three
	expectedOutput string // Expected constant output

	wantException bool
}

func verifyExecTestOutput(t *testing.T, cmd *cobra.Command, c execTestCase) {
	if c.wantException {

in-cluster CR is updated and the controller acts upon it to generate a new manifest to apply to the cluster. Note that
both the charts and configuration profiles can come from three different sources: compiled-in, local filesystem.
The source may be selected independently for the charts and profiles. The different steps in creating the manifest are
as follows: