# Updating charts and values.yaml

## Acceptable Pull Requests

Helm charts `values.yaml` represent a complex user facing API that tends to grow uncontrollably over time
due to design choices in Helm.
The underlying Kubernetes resources we configure have 1000s of fields; given enough users and bespoke use cases,
eventually someone will want to customize every one of those fields.

message ExtraValue {
  // items, if empty, will result in an empty slice

  repeated string items = 1;
}

// LocalSubjectAccessReview checks whether or not a user or group can perform an action in a given namespace.
// Having a namespace scoped resource makes it much easier to grant namespace scoped policy that includes permissions
// checking.
message LocalSubjectAccessReview {
  // Standard list metadata.

    
    # Settings related to the untaint controller
    # This controller will remove `cni.istio.io/not-ready` from nodes when the istio-cni pod becomes ready
    # It should be noted that cluster operator/owner is responsible for having the taint set by their infrastructure provider when new nodes are added to the cluster; the untaint controller does not taint nodes
    taint:
      # Controls whether or not the untaint controller is active
      enabled: false

                    type: object
                  failureThreshold:
                    description: Minimum consecutive failures for the probe to be
                      considered failed after having succeeded.
                    format: int32
                    type: integer
                  httpGet:
                    description: '`httpGet` is performed to a given endpoint and the

- [ ] Security
- [ ] Test and Release
- [ ] User Experience
- [ ] Developer Infrastructure

**Please check any characteristics that apply to this pull request.**

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).
We can then merge the profile onto the defaults, then the user settings onto that.

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).
We can then merge the profile onto the defaults, then the user settings onto that.

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).
We can then merge the profile onto the defaults, then the user settings onto that.

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).
We can then merge the profile onto the defaults, then the user settings onto that.

	"log_caller":           true,
	"log_output_level":     true,
	// istioctl also inherits support for log_rotate, log_rotate_max_age, log_rotate_max_backups,
	// log_rotate_max_size, but these are rarely appropriate for a user-facing CLI so we ignore them
}

func optionsCommand(rootCmd *cobra.Command) *cobra.Command {
	retval := &cobra.Command{
		Use:   "options",
		Short: "Displays istioctl global options",
		Args:  cobra.ExactArgs(0),
	}