- Sort Score
- Result 10 results
- Languages All
Results 1 - 10 of 148 for describe (0.35 sec)
-
istioctl/pkg/describe/describe.go
cmd := &cobra.Command{ Use: "pod <pod>", Aliases: []string{"po"}, Short: "Describe pods and their Istio configuration [kube-only]", Long: `Analyzes pod, its Services, DestinationRules, and VirtualServices and reports the configuration objects that affect that pod.`, Example: ` istioctl experimental describe pod productpage-v1-c7765c886-7zzd4`, RunE: func(cmd *cobra.Command, args []string) error {
Go - Registered: Wed Mar 27 22:53:09 GMT 2024 - Last Modified: Tue Mar 12 18:49:10 GMT 2024 - 46.2K bytes - Viewed (0) -
istioctl/pkg/describe/describe_test.go
func TestDescribe(t *testing.T) { productPageConfigPath := "testdata/describe/http_config.json" config, err := os.ReadFile(productPageConfigPath) if err != nil { t.Fatalf("failed to read %s: %v", productPageConfigPath, err) } cases := []execAndK8sConfigTestCase{ { // case 0 args: []string{}, expectedString: "Describe resource and related Istio configuration", }, { // case 2 no pod
Go - Registered: Wed Mar 27 22:53:09 GMT 2024 - Last Modified: Fri Mar 15 08:28:50 GMT 2024 - 22.5K bytes - Viewed (0) -
.github/ISSUE_TEMPLATE/feature_request.md
name: Feature request about: Suggest an idea to improve Istio --- (This is used to request new product features, please visit <https://github.com/istio/istio/discussions> for questions on using Istio) **Describe the feature request** **Describe alternatives you've considered** **Affected product area (please put an X in all that apply)** [ ] Ambient [ ] Docs [ ] Dual Stack [ ] Installation [ ] Networking
Plain Text - Registered: Wed Mar 27 22:53:09 GMT 2024 - Last Modified: Mon Feb 12 19:42:48 GMT 2024 - 707 bytes - Viewed (0) -
architecture/standards/0002-avoid-using-java-serialization.md
Java serialization does not enforce type safety as strictly as some alternatives, potentially leading to runtime errors. ## Decision We do not use Java serialization. Instead, we use custom serialization where we explicitly describe how data objects should be serialized and deserialized. For internal purposes, we use binary formats for their brevity. We use the `Serializer` abstraction to separate the actual implementation of serialization from its uses.
Plain Text - Registered: Wed Mar 27 11:36:08 GMT 2024 - Last Modified: Thu Feb 29 22:32:18 GMT 2024 - 2.3K bytes - Viewed (0) -
.github/ISSUE_TEMPLATE/40_contributor_documentation.yml
- Typo (please open a PR instead) validations: required: true - type: textarea id: description attributes: label: Problem description description: | Please describe the problem as concisely as possible. validations: required: true - type: textarea id: context attributes: label: Context (optional) description: |
Others - Registered: Wed Mar 27 11:36:08 GMT 2024 - Last Modified: Mon Jan 15 10:01:01 GMT 2024 - 1.6K bytes - Viewed (0) -
architecture-standards/0002-avoid-using-java-serialization.md
## Decision We do not use Java serialization. Instead, we use custom serialization where we explicitly describe how data objects should be serialized and deserialized. For internal purposes, we use binary formats for their brevity. We use the `Serializer` abstraction to separate the actual implementation of serialization from its uses.
Plain Text - Registered: Wed Feb 14 11:36:15 GMT 2024 - Last Modified: Thu Feb 08 21:48:27 GMT 2024 - 1.9K bytes - Viewed (0) -
architecture-standards/0001-use-architectural-decision-records.md
## Decision The *Build Tool Team* has decided to use Architectural Decision Records (aka ADR) to track decisions we want to follow. The main logic with ADRs is to describe (architectural) decisions made: * To provide best practices and solutions we (as *build tool* team) want to promote. * To avoid asking the same thing multiple times during code review.
Plain Text - Registered: Wed Feb 14 11:36:15 GMT 2024 - Last Modified: Wed Feb 07 00:43:19 GMT 2024 - 2.8K bytes - Viewed (0) -
architecture/standards/0001-use-architectural-decision-records.md
## Decision The *Build Tool Team* has decided to use Architectural Decision Records (aka ADR) to track decisions we want to follow. The main logic with ADRs is to describe (architectural) decisions made: * To provide best practices and solutions we (as the *build tool* team) want to promote. * To avoid asking the same thing multiple times during code review.
Plain Text - Registered: Wed Mar 27 11:36:08 GMT 2024 - Last Modified: Sat Mar 02 21:54:40 GMT 2024 - 2.8K bytes - Viewed (0) -
docs/es/docs/advanced/response-headers.md
## Retornar una `Response` directamente Adicionalmente, puedes añadir headers cuando se retorne una `Response` directamente. Crea un response tal como se describe en [Retornar una respuesta directamente](response-directly.md){.internal-link target=_blank} y pasa los headers como un parámetro adicional: ```Python hl_lines="10-12" {!../../../docs_src/response_headers/tutorial001.py!} ```
Plain Text - Registered: Sun Mar 24 07:19:08 GMT 2024 - Last Modified: Wed Feb 07 12:51:12 GMT 2024 - 2.5K bytes - Viewed (0) -
Makefile
sed 's#RELEASE\.\([0-9]\+\)-\([0-9]\+\)-\([0-9]\+\)T\([0-9]\+\)-\([0-9]\+\)-\([0-9]\+\)Z#\1-\2-\3T\4:\5:\6Z#'))) $(eval VERSION := $(shell git describe --tags --abbrev=0).hotfix.$(shell git rev-parse --short HEAD)) hotfix: hotfix-vars clean install ## builds minio binary with hotfix tags
Plain Text - Registered: Sun Mar 24 19:28:08 GMT 2024 - Last Modified: Thu Mar 21 17:21:35 GMT 2024 - 9.4K bytes - Viewed (1)