# Bugs and Feature Requests

You can report bugs and feature requests to the Istio team in one of three places:

- [Product Bugs and Feature Requests](https://github.com/istio/istio/issues)
- [Documentation Bugs and Feature Requests](https://github.com/istio/istio.io/issues)
- [Community and Governance Issues](https://github.com/istio/community/issues)

For security vulnerabilities, please don't report a bug (which is public) and instead follow

import (
	"bytes"
	"regexp"
	"strings"
	"testing"

	"github.com/spf13/cobra"

	"istio.io/istio/pilot/test/util"
)

type TestCase struct {
	Args []string

	// Typically use one of the three
	ExpectedOutput string         // Expected constant output
	ExpectedRegexp *regexp.Regexp // Expected regexp output
	GoldenFilename string         // Expected output stored in golden file

	WantException bool
}

	"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 TestProxyStatus(t *testing.T) {
	cases := []execTestCase{

	istioConfigs   []runtime.Object // Canned Istio configuration
	configDumps    map[string][]byte
	namespace      string
	istioNamespace string

	args []string

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

	wantException bool
}

// Tests Pilot /debug
func TestDescribe(t *testing.T) {

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

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