From edf5d9d76916d5b0199517322e06ae756348e094 Mon Sep 17 00:00:00 2001 From: Karolina Zydek Date: Tue, 13 Apr 2021 08:26:09 +0200 Subject: [PATCH] Change excluding terms into inclusive alternatives (#11084) --- .github/pull-request-template.md | 2 +- CODE_OF_CONDUCT.md | 2 +- CONTRIBUTING.md | 6 +-- README.md | 24 +++++------ common/makefiles/docs/generic-make-go.md | 2 +- components/README.md | 2 +- components/application-broker/README.md | 2 +- .../cmd/poc-events/findings.md | 2 +- .../binding/docs/03-binding-pipelines.md | 8 ++-- .../console-backend-service/CONTRIBUTING.md | 2 +- .../console-backend-service/docs/security.md | 4 +- components/eventing-controller/README.md | 10 ++--- components/permission-controller/README.md | 4 +- .../README.md | 4 +- .../examples/README.md | 2 +- docs/README.md | 8 ++-- docs/api-gateway/03-02-whitelisted-domains.md | 8 ++-- .../api-gateway/03-03-blacklisted-services.md | 6 +-- docs/api-gateway/08-02-exposesecure.md | 2 +- .../02-01-application-connector.md | 2 +- .../02-04-application-broker.md | 4 +- .../02-01-application-connector.md | 2 +- docs/console/03-04-rafter-in-console.md | 2 +- docs/getting-started/01-overview.md | 4 +- .../getting-started/03-deploy-microservice.md | 10 ++--- docs/getting-started/10-create-function.md | 4 +- docs/helm-broker/01-01-helm-broker.md | 4 +- docs/helm-broker/02-01-helm-broker.md | 2 +- docs/helm-broker/03-04-create-addons-repo.md | 2 +- docs/helm-broker/03-05-registration-rules.md | 2 +- docs/kiali/05-01-kiali.md | 2 +- docs/kyma/04-01-overview.md | 2 +- docs/kyma/04-03-cluster-installation.md | 8 ++-- docs/kyma/04-04-use-your-own-domain.md | 2 +- docs/kyma/04-05-use-your-own-image.md | 4 +- docs/kyma/04-07-upgrade.md | 2 +- docs/kyma/04-08-update.md | 2 +- .../05-02-custom-component-installation.md | 10 ++--- docs/kyma/05-03-overrides.md | 2 +- docs/kyma/16-01-try-out-kyma.md | 12 +++--- docs/monitoring/03-01-alertmanager.md | 2 +- docs/monitoring/08-01-overview.md | 2 +- .../08-02-observe-application-metrics.md | 6 +-- ...-create-and-configure-grafana-dashboard.md | 2 +- docs/monitoring/08-05-send-notifications.md | 2 +- docs/rafter/05-01-rafter.md | 4 +- docs/rafter/06-05-clusterassetgroup.md | 2 +- .../runtime-agent/04-01-installation-modes.md | 2 +- docs/security/03-01-authentication-in-kyma.md | 8 ++-- docs/security/03-02-authorization-in-kyma.md | 12 +++--- docs/security/03-03-accessing-kyma.md | 14 +++---- docs/security/03-04-ingress-egress-traffic.md | 40 +++++++++---------- docs/security/03-05-graphql.md | 2 +- docs/security/05-07-permission-controller.md | 4 +- docs/security/08-04-add-connector.md | 2 +- docs/serverless/08-05-create-git-function.md | 8 ++-- .../08-07-sync-function-with-gitops.md | 10 ++--- .../06-01-service-binding-usage.md | 2 +- docs/service-catalog/06-02-usage-kind.md | 2 +- .../15-04-specifications-in-console-ui.md | 8 ++-- docs/service-mesh/10-03-connection-refused.md | 6 +-- resources/README.md | 4 +- resources/helm-broker/README.md | 4 +- resources/monitoring/README.md | 2 +- resources/monitoring/charts/grafana/README.md | 2 +- .../ory/charts/gcloud-sqlproxy/README.md | 2 +- resources/ory/charts/postgresql/README.md | 10 ++--- resources/permission-controller/README.md | 4 +- resources/serverless/charts/webhook/README.md | 2 +- resources/service-catalog-addons/README.md | 4 +- .../README.md | 2 +- tests/README.md | 6 +-- tests/end-to-end/upgrade/README.md | 10 ++--- tests/function-controller/README.md | 6 +-- tests/perf/README.md | 4 +- tests/rafter/README.md | 2 +- tools/README.md | 2 +- 77 files changed, 195 insertions(+), 195 deletions(-) diff --git a/.github/pull-request-template.md b/.github/pull-request-template.md index f8ad731d06a0..67d9fb141ae0 100644 --- a/.github/pull-request-template.md +++ b/.github/pull-request-template.md @@ -1,6 +1,6 @@ diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index de028b1f6a8e..a3055bd241fc 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,3 +1,3 @@ # Code of conduct -Each contributor and maintainer of this project agrees to follow the [community Code of Conduct](https://github.com/kyma-project/community/blob/master/CODE_OF_CONDUCT.md) that relies on the CNCF Code of Conduct. Read it to learn about the agreed standards of behavior, shared values that govern our community, and details on how to report any suspected Code of Conduct violations. +Each contributor and maintainer of this project agrees to follow the [community Code of Conduct](https://github.com/kyma-project/community/blob/main/CODE_OF_CONDUCT.md) that relies on the CNCF Code of Conduct. Read it to learn about the agreed standards of behavior, shared values that govern our community, and details on how to report any suspected Code of Conduct violations. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8448cb8c3929..1e2eaa6a2c64 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,14 +1,14 @@ ## Overview -To contribute to this project, follow the rules from the general [CONTRIBUTING.md](https://github.com/kyma-project/community/blob/master/CONTRIBUTING.md) document in the `community` repository. +To contribute to this project, follow the rules from the general [CONTRIBUTING.md](https://github.com/kyma-project/community/blob/main/CONTRIBUTING.md) document in the `community` repository. ## Documentation types These are the main types of documents used in the project: -* `NOTES.txt`- This document type is an integral part of Helm charts. Its content displays in the terminal window after installing the chart. It is not mandatory to include `NOTES.txt` documents for sub-charts because the system ignores these documents. Provide `NOTES.txt` documents for the Core components. Use the [template](https://github.com/kyma-project/community/blob/master/guidelines/templates/resources/NOTES.txt) to create `NOTES.txt` documents. +* `NOTES.txt`- This document type is an integral part of Helm charts. Its content displays in the terminal window after installing the chart. It is not mandatory to include `NOTES.txt` documents for sub-charts because the system ignores these documents. Provide `NOTES.txt` documents for the Core components. Use the [template](https://github.com/kyma-project/community/blob/main/guidelines/templates/resources/NOTES.txt) to create `NOTES.txt` documents. -* `README.md` - This document type contains information about other files in the directory. Each main directory in this repository, such as `cluster` or `resources`, requires a `README.md` document. Additionally, each chart and sub-chart needs such a document. Add a `README.md` document when you create a new directory or chart. Use the [template](https://github.com/kyma-project/community//blob/master/guidelines/templates/resources/chart_README.md) to create `README.md` documents. +* `README.md` - This document type contains information about other files in the directory. Each main directory in this repository, such as `cluster` or `resources`, requires a `README.md` document. Additionally, each chart and sub-chart needs such a document. Add a `README.md` document when you create a new directory or chart. Use the [template](https://github.com/kyma-project/community//blob/main/guidelines/templates/resources/chart_README.md) to create `README.md` documents. > **NOTE:** `README.md` documents imported to Kyma with external charts don't have to follow the template. diff --git a/README.md b/README.md index 438212a4545b..e99c9ec16d80 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@

- +

[![Go Report Card](https://goreportcard.com/badge/github.com/kyma-project/kyma)](https://goreportcard.com/report/github.com/kyma-project/kyma) @@ -11,7 +11,7 @@ **Kyma** `/kee-ma/` is a platform for extending applications with microservices and [serverless](https://kyma-project.io/docs/components/serverless/#overview-overview) Functions. It provides CLI and UI through which you can connect your application to a Kubernetes cluster. You can also expose the application's API or events securely thanks to the built-in [Application Connector](https://kyma-project.io/docs/components/application-connector/#overview-overview). You can then implement the business logic you require by creating microservices or serverless Functions. Trigger them to react to particular events or calls to your application's API. -To limit the time spent on coding, use the built-in cloud services from [Service Catalog](https://kyma-project.io/docs/master/components/service-catalog/#overview-service-catalog), exposed by [Service Brokers](https://kyma-project.io/docs/master/components/service-catalog/#overview-service-brokers) from such cloud providers as GCP, Azure, and AWS. +To limit the time spent on coding, use the built-in cloud services from [Service Catalog](https://kyma-project.io/docs/components/service-catalog/#overview-service-catalog), exposed by [Service Brokers](https://kyma-project.io/docs/components/service-catalog/#overview-service-brokers) from such cloud providers as GCP, Azure, and AWS.

@@ -75,18 +75,18 @@ Follow these steps: [Read](https://kyma-project.io/#used-by) how these companies use Kyma:

- SAP - Accenture - NETCONOMY - neteleven + SAP + Accenture + NETCONOMY + neteleven

- ARITHNEA - Digital Lights - FAIR - FAIR + ARITHNEA + Digital Lights + FAIR + FAIR

- Arineo - dotSource + Arineo + dotSource

diff --git a/common/makefiles/docs/generic-make-go.md b/common/makefiles/docs/generic-make-go.md index 948c2310cb49..2176ba409e65 100644 --- a/common/makefiles/docs/generic-make-go.md +++ b/common/makefiles/docs/generic-make-go.md @@ -23,7 +23,7 @@ BUILDPACK = {BUILDPACK IMAGE} SCRIPTS_DIR = {GENERIC MAKEFILE PATH} include $(SCRIPTS_DIR)/generic-make-go.mk ``` -Find the list of available buildpack images [here](https://github.com/kyma-project/test-infra/blob/master/templates/config.yaml). +Find the list of available buildpack images [here](https://github.com/kyma-project/test-infra/blob/main/templates/config.yaml). ## Usage This is the basic syntax used in Makefiles: diff --git a/components/README.md b/components/README.md index ac3b1f976faa..7cfa6efb87c6 100644 --- a/components/README.md +++ b/components/README.md @@ -26,4 +26,4 @@ This table lists the available types: ## Development -Follow [this](https://github.com/kyma-project/kyma/blob/master/resources/README.md) development guide when you add a new component to the `kyma` repository. +Follow [this](https://github.com/kyma-project/kyma/blob/main/resources/README.md) development guide when you add a new component to the `kyma` repository. diff --git a/components/application-broker/README.md b/components/application-broker/README.md index 99a2ebce33da..b262954cbe5d 100755 --- a/components/application-broker/README.md +++ b/components/application-broker/README.md @@ -21,7 +21,7 @@ To set up the project, download these tools: * [Dep](https://github.com/golang/dep) v0.5.0 * [Docker](https://www.docker.com/) -These Go and Dep versions are compliant with the `buildpack` used by Prow. For more details read [this](https://github.com/kyma-project/test-infra/blob/master/prow/images/buildpack-golang/README.md) document. +These Go and Dep versions are compliant with the `buildpack` used by Prow. For more details read [this](https://github.com/kyma-project/test-infra/blob/main/prow/images/buildpack-golang/README.md) document. ## Development diff --git a/components/application-broker/cmd/poc-events/findings.md b/components/application-broker/cmd/poc-events/findings.md index 9752d708cdc7..67ecb3fa7333 100644 --- a/components/application-broker/cmd/poc-events/findings.md +++ b/components/application-broker/cmd/poc-events/findings.md @@ -20,7 +20,7 @@ Currently changing status of custom resource does not work. Probably will be rel #### Detailed description Currently changing status of custom resource does not work, but [proposal](https://github.com/kubernetes/community/pull/913) is already accepted. -Implementation is also merged to master and tagged with version: "v1.10.0-beta.4". See [Add subresources for custom resources](https://github.com/kubernetes/kubernetes/pull/55168/commits/6fbe8157e39f6bd7ad885a8a6f8614e2fe45dc5e) +Implementation is also merged to the `master` branch and tagged with version: "v1.10.0-beta.4". See [Add subresources for custom resources](https://github.com/kubernetes/kubernetes/pull/55168/commits/6fbe8157e39f6bd7ad885a8a6f8614e2fe45dc5e) So currently we get following error when calling UpdateStatus method. ```text diff --git a/components/binding/docs/03-binding-pipelines.md b/components/binding/docs/03-binding-pipelines.md index ae20db4a2b5d..5d4da89f8978 100644 --- a/components/binding/docs/03-binding-pipelines.md +++ b/components/binding/docs/03-binding-pipelines.md @@ -2,10 +2,10 @@ Kyma Binding pipelines are based on GitHub Actions and use k3s that provides [the best infrastructure](https://github.com/kyma-incubator/local-kyma#i-see-k3s-k3d-kind-and-minikube---what-should-i-use) to run the CI on. The script to run k3s is based on [this script](https://github.com/kyma-incubator/local-kyma/blob/main/create-cluster-k3s.sh). As GitHub doesn't propagate the secrets created on the main repository to pull requests opened from forked repositories and the workflow in Kyma is based on using forks, we had to create a workaround based on [this solution](https://github.com/imjohnbo/ok-to-test). For this purpose, the following jobs were developed: -- [`Is trusted dev`](https://github.com/kyma-project/kyma/blob/master/.github/workflows/trusted-dev.yaml) -- [`Ok to test`](https://github.com/kyma-project/kyma/blob/master/.github/workflows/ok-to-test.yaml) -- [`Pre-master binding k3s`](https://github.com/kyma-project/kyma/blob/master/.github/workflows/pre-master-binding-k3s.yml) -- [`Post-master binding k3s`](https://github.com/kyma-project/kyma/blob/master/.github/workflows/post-master-binding-k3s.yml) +- [`Is trusted dev`](https://github.com/kyma-project/kyma/blob/main/.github/workflows/trusted-dev.yaml) +- [`Ok to test`](https://github.com/kyma-project/kyma/blob/main/.github/workflows/ok-to-test.yaml) +- [`Pre-master binding k3s`](https://github.com/kyma-project/kyma/blob/main/.github/workflows/pre-master-binding-k3s.yml) +- [`Post-master binding k3s`](https://github.com/kyma-project/kyma/blob/main/.github/workflows/post-master-binding-k3s.yml) ## `Is trusted dev` job diff --git a/components/console-backend-service/CONTRIBUTING.md b/components/console-backend-service/CONTRIBUTING.md index 2fbd08645018..8a34ab0d99a6 100644 --- a/components/console-backend-service/CONTRIBUTING.md +++ b/components/console-backend-service/CONTRIBUTING.md @@ -1,5 +1,5 @@ # Overview -To contribute to this project, follow the rules from the general [CONTRIBUTING.md](https://github.com/kyma-project/community/blob/master/CONTRIBUTING.md) document in the `community` repository. +To contribute to this project, follow the rules from the general [CONTRIBUTING.md](https://github.com/kyma-project/community/blob/main/CONTRIBUTING.md) document in the `community` repository. For additional, project-specific guidelines, see the respective sections of this document. ## Contribution rules diff --git a/components/console-backend-service/docs/security.md b/components/console-backend-service/docs/security.md index 0190b2bb2710..cfb209485003 100644 --- a/components/console-backend-service/docs/security.md +++ b/components/console-backend-service/docs/security.md @@ -6,7 +6,7 @@ The application checks if the Authorization token passed by the user is signed b ## Overview -The Console Backend Service uses a GraphQL implementation for authorization. Read [this](https://kyma-project.io/docs/master/components/security#details-graph-ql)) document for more details. +The Console Backend Service uses a GraphQL implementation for authorization. Read [this](https://kyma-project.io/docs/components/security/#details-graph-ql) document for more details. ## How to secure a GraphQL action @@ -28,7 +28,7 @@ Reference this table for details on the elements that make up a defined and secu | `: [LimitRange!]!` | Defines the type of object returned by the query. In this case, it's a list of LimitRanges resources. | | `@HasAccess(attributes:` | Defines the GraphQL directive that secures access to the resource. | | `resource: "limitranges"` | Defines the type of secured Kubernetes resource, in this case all `limitranges` resources. | -| `verb: "list"` | Defines the secured interaction type. It is related to action type, which in this case is "query". Use the the table from [this paragraph](https://kyma-project.io/docs/master/components/security#details-graph-ql) to choose the right verb. | +| `verb: "list"` | Defines the secured interaction type. It is related to action type, which in this case is "query". Use the the table from [this paragraph](https://kyma-project.io/docs/components/security/#details-graph-ql) to choose the right verb. | | `apiGroup: ""` | Defines the apiGroup to which the user must have access to get the result of this query. In this case it is empty because limitRanges is the resource built into Kubernetes, not some Custom Resource created by us. | | `apiVersion: "v1alpha1"` | Specifies the apiVersion of the query subject. | | `namespaceArg: "namespace"` | Specifies the name of the argument or field in the parent object from which the resource namespace is fetched. | diff --git a/components/eventing-controller/README.md b/components/eventing-controller/README.md index 1893c4e79ceb..bcf1c94ba232 100644 --- a/components/eventing-controller/README.md +++ b/components/eventing-controller/README.md @@ -3,8 +3,8 @@ ## Overview This component contains controllers for various CustomResourceDefinitions related to eventing in Kyma. The following controllers come with this container: -- [`controller`](https://github.com/kyma-project/kyma/blob/master/components/eventing-controller/cmd/eventing-controller/main.go) which lays down the eventing infrastructure in Business Event Bus (BEB). -- [`nats-controller`](https://github.com/kyma-project/kyma/blob/master/components/eventing-controller/cmd/eventing-controller-nats/main.go) which lays down the eventing infrastructure in [NATS](https://docs.nats.io/nats-concepts/intro). +- [`controller`](https://github.com/kyma-project/kyma/blob/main/components/eventing-controller/cmd/eventing-controller/main.go) which lays down the eventing infrastructure in Business Event Bus (BEB). +- [`nats-controller`](https://github.com/kyma-project/kyma/blob/main/components/eventing-controller/cmd/eventing-controller-nats/main.go) which lays down the eventing infrastructure in [NATS](https://docs.nats.io/nats-concepts/intro). ## Prerequisites - Install [ko](https://github.com/google/ko) which is used to build and deploy the controller during local development @@ -33,7 +33,7 @@ This component contains controllers for various CustomResourceDefinitions relate make deploy-eventing-controller-nats-local-dry-run ``` -## Usage +## Usage This section explains how to use the Eventing Controller. @@ -106,12 +106,12 @@ Before running the component, execute the following command once to pull softwar ```sh make test ## To download dependencies only -make resolve-local +make resolve-local ``` ### Generate code during local development -> More details on scaffolding code using kubebuilder can be found [here](https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/simplified-scaffolding.md). +> More details on scaffolding code using kubebuilder can be found [here](https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/simplified-scaffolding.md). - Add new APIs using [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) CLI followed by generating boilerplate code by executing the following script: diff --git a/components/permission-controller/README.md b/components/permission-controller/README.md index 58b727f27b3c..f1e39dca3251 100644 --- a/components/permission-controller/README.md +++ b/components/permission-controller/README.md @@ -1,7 +1,7 @@ # Permission Controller ## Overview -The Permission Controller listens for new Namespaces and creates a RoleBinding for the users of the specified group to the **kyma-admin** role within these Namespaces. The Controller uses a blacklist mechanism, which defines the Namespaces in which the users of the defined group are not assigned the **kyma-admin** role. When the Controller is deployed in a cluster, it checks all existing Namespaces and assigns the roles accordingly. +The Permission Controller listens for new Namespaces and creates a RoleBinding for the users of the specified group to the **kyma-admin** role within these Namespaces. The Controller uses a blocking mechanism which defines the Namespaces in which the users of the defined group are not assigned the **kyma-admin** role. When the Controller is deployed in a cluster, it checks all existing Namespaces and assigns the roles accordingly. Click [here](/resources/permission-controller) to access the Helm chart that defines the component's installation. @@ -34,5 +34,5 @@ Use the `run` formula to run the controller using local sources: ```bash make run EXCLUDED_NAMESPACES={EXCLUDED_NAMESPACES} SUBJECT_GROUPS={SUBJECT_GROUPS} STATIC_CONNECTOR={STATIC_CONNECTOR} ``` - + See [this file](/resources/permission-controller/README.md#configuration) to learn how to use the environment variables. diff --git a/components/service-binding-usage-controller/README.md b/components/service-binding-usage-controller/README.md index d771c712f589..12432becdc4e 100644 --- a/components/service-binding-usage-controller/README.md +++ b/components/service-binding-usage-controller/README.md @@ -4,7 +4,7 @@ ServiceBindingUsage Controller injects **ServiceBindings** into a given application using the **ServiceBindingUsage** custom resource, which allows for binding this application to a given ServiceInstance. The ServiceBindingUsage is a Kubernetes custom resource which is Namespace-scoped. -For the custom resource definition, see the [ServiceBindingUsage CRD file](../../resources/cluster-essentials/files/servicebindingusages.servicecatalog.crd.yaml). For more information on the ServiceBindingUsage Controller, see the [docs](./docs) folder in this repository. You can also refer to the corresponding [ServiceBindngUsage documentation](https://kyma-project.io/docs/master/components/service-catalog/#custom-resource-service-binding-usage) on the website. +For the custom resource definition, see the [ServiceBindingUsage CRD file](../../resources/cluster-essentials/files/servicebindingusages.servicecatalog.crd.yaml). For more information on the ServiceBindingUsage Controller, see the [docs](./docs) folder in this repository. You can also refer to the corresponding [ServiceBindngUsage documentation](https://kyma-project.io/docs/components/service-catalog#custom-resource-service-binding-usage) on the website. ## Prerequisites @@ -14,7 +14,7 @@ To set up the project, download these tools: * [Dep](https://github.com/golang/dep) v0.5.0 * [Docker](https://www.docker.com/) -These Go and Dep versions are compliant with the `buildpack` used by Prow. For more details, read [the Buildpack Golang Docker Image README](https://github.com/kyma-project/test-infra/blob/master/prow/images/buildpack-golang/README.md). +These Go and Dep versions are compliant with the `buildpack` used by Prow. For more details, read [the Buildpack Golang Docker Image README](https://github.com/kyma-project/test-infra/blob/main/prow/images/buildpack-golang/README.md). ## Usage diff --git a/components/service-binding-usage-controller/examples/README.md b/components/service-binding-usage-controller/examples/README.md index d878ec361543..8ee043ce28eb 100644 --- a/components/service-binding-usage-controller/examples/README.md +++ b/components/service-binding-usage-controller/examples/README.md @@ -87,7 +87,7 @@ kubectl delete ns $namespace ### Use bindings on a Function -To use bindings on a Function, follow [this](https://kyma-project.io/docs/master/components/serverless/#tutorials-bind-a-service-instance-to-a-function) tutorial. +To use bindings on a Function, follow [this](https://kyma-project.io/docs/components/serverless/#tutorials-bind-a-service-instance-to-a-function) tutorial. ## Pluggable SBU diff --git a/docs/README.md b/docs/README.md index b674ec22ea60..4d87766f8650 100644 --- a/docs/README.md +++ b/docs/README.md @@ -30,7 +30,7 @@ The navigation order of the documentation page is based on the **rafter.kyma-pro Follow these basic rules when you add a new document to the official Kyma documentation: -1. Get familiar with the [Content Strategy](https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/01-content-strategy.md) to learn about the Kyma's official approach to content development. -2. Follow the [Contribution Guide](https://github.com/kyma-project/community/blob/master/contributing/02-contributing.md) for the general contribution rules and process. -3. Make use of the [templates](https://github.com/kyma-project/community/tree/master/guidelines/templates) to structure your documents properly. -4. Be compliant with the writing [guidelines](https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines) to contribute high-quality and standardized content. +1. Get familiar with the [Content Strategy](https://github.com/kyma-project/community/blob/main/guidelines/content-guidelines/01-content-strategy.md) to learn about the Kyma's official approach to content development. +2. Follow the [Contribution Guide](https://github.com/kyma-project/community/blob/main/contributing/02-contributing.md) for the general contribution rules and process. +3. Make use of the [templates](https://github.com/kyma-project/community/tree/main/guidelines/templates) to structure your documents properly. +4. Be compliant with the writing [guidelines](https://github.com/kyma-project/community/blob/main/guidelines/content-guidelines) to contribute high-quality and standardized content. diff --git a/docs/api-gateway/03-02-whitelisted-domains.md b/docs/api-gateway/03-02-whitelisted-domains.md index ba582a702389..dcf3787360a0 100644 --- a/docs/api-gateway/03-02-whitelisted-domains.md +++ b/docs/api-gateway/03-02-whitelisted-domains.md @@ -1,12 +1,12 @@ --- -title: Whitelisted domains in the API Gateway Controller +title: Allowed domains in the API Gateway Controller type: Details --- -The API Gateway Controller uses a whitelist of domains for which it allows to expose services. Every time a user creates a new APIRule custom resource (CR) for a service, the API Gateway Controller checks the domain of the service specified in the CR against the whitelist. If the domain of the service matches a whitelisted entry, the API Gateway Controller creates a Virtual Service and Oathkeeper Access Rules for the service according to the details specified in the CR. If the domain is not whitelisted, the Controller creates neither a Virtual Service nor Oathkeeper Access Rules and, as a result, does not expose the service. +The API Gateway Controller uses an allowlist of domains for which it allows to expose services. Every time a user creates a new APIRule custom resource (CR) for a service, the API Gateway Controller checks the domain of the service specified in the CR against the allowlist. If the domain of the service matches an allowed entry, the API Gateway Controller creates a Virtual Service and Oathkeeper Access Rules for the service according to the details specified in the CR. If the domain is not allowed, the Controller creates neither a Virtual Service nor Oathkeeper Access Rules and, as a result, does not expose the service. -If the domain does not match the whitelist, the API Gateway Controller sets an appropriate validation status on the APIRule CR created for that service. +If the domain does not match the allowlist, the API Gateway Controller sets an appropriate validation status on the APIRule CR created for that service. >**TIP:** For more information, read about the [Api CR statuses](#custom-resource-api-rule-status-codes). -By default, the only whitelisted domain is the domain of the Kyma cluster. +By default, the only allowed domain is the domain of the Kyma cluster. diff --git a/docs/api-gateway/03-03-blacklisted-services.md b/docs/api-gateway/03-03-blacklisted-services.md index c8c8f33eeaa4..222a65741eea 100644 --- a/docs/api-gateway/03-03-blacklisted-services.md +++ b/docs/api-gateway/03-03-blacklisted-services.md @@ -1,10 +1,10 @@ --- -title: Blacklisted services in the API Gateway Controller +title: Blocked services in the API Gateway Controller type: Details --- -The API Gateway Controller uses a blacklist of services for which it does not create either a Virtual Service or Oathkeeper Access Rules. As a result, these services cannot be exposed. Every time a user creates a new APIRule custom resource (CR) for a service, the API Gateway Controller checks the name of the service specified in the CR against the blacklist. If the name of the service matches a blacklisted entry, the API Gateway Controller sets an appropriate validation status on the APIRule CR created for that service. +The API Gateway Controller uses a blocklist of services for which it does not create either a Virtual Service or Oathkeeper Access Rules. As a result, these services cannot be exposed. Every time a user creates a new APIRule custom resource (CR) for a service, the API Gateway Controller checks the name of the service specified in the CR against the blocklist. If the name of the service matches a blocked entry, the API Gateway Controller sets an appropriate validation status on the APIRule CR created for that service. >**TIP:** For more information, read about the [Api CR statuses](#custom-resource-api-rule-status-codes). -The blacklist works as a security measure and prevents users from exposing vital internal services of Kubernetes, Istio, and API Server Proxy. +The blocklist works as a security measure and prevents users from exposing vital internal services of Kubernetes, Istio, and API Server Proxy. diff --git a/docs/api-gateway/08-02-exposesecure.md b/docs/api-gateway/08-02-exposesecure.md index 22866a8cda51..2cea246f4a56 100644 --- a/docs/api-gateway/08-02-exposesecure.md +++ b/docs/api-gateway/08-02-exposesecure.md @@ -161,7 +161,7 @@ The exposed service requires tokens with "read" scope for `GET` requests in the 1. Create a Function using the [supplied code](./assets/function.yaml): ```shell - kubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/master/docs/api-gateway/assets/function.yaml + kubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/main/docs/api-gateway/assets/function.yaml ``` 2. Expose the Function and secure it by creating an APIRule CR: diff --git a/docs/application-connector-compass-mode/02-01-application-connector.md b/docs/application-connector-compass-mode/02-01-application-connector.md index 2718c2ce01c2..0fe2d4e973a5 100644 --- a/docs/application-connector-compass-mode/02-01-application-connector.md +++ b/docs/application-connector-compass-mode/02-01-application-connector.md @@ -54,7 +54,7 @@ The AB implements the [Open Service Broker API](https://www.openservicebrokerapi ## Application Operator -The Application Operator (AO) can work in two modes. In the default legacy mode, the AO listens for creating or deleting the [Application](#custom-resource-application) custom resources and acts accordingly, either provisioning or deprovisioning an instance of the Application Gateway and the Event Publisher for every custom resource. In the alternative Compass mode, it listens for an additional resource, [ServiceInstance](/components/service-catalog/#architecture-resources). In this mode, it provisions an instance of the Application Gateway once per Namespace. That means that there is always only one Application Gateway per Namespace, even if there are more ServiceInstances and Applications. The Application Gateway gets deleted with the last ServiceInstance in that Namespace. The Compass mode is enabled by setting the **gatewayOncePerNamespace** [feature flag](https://github.com/kyma-project/kyma/blob/master/components/application-operator/README.md#usage) to true. +The Application Operator (AO) can work in two modes. In the default legacy mode, the AO listens for creating or deleting the [Application](#custom-resource-application) custom resources and acts accordingly, either provisioning or deprovisioning an instance of the Application Gateway and the Event Publisher for every custom resource. In the alternative Compass mode, it listens for an additional resource, [ServiceInstance](/components/service-catalog/#architecture-resources). In this mode, it provisions an instance of the Application Gateway once per Namespace. That means that there is always only one Application Gateway per Namespace, even if there are more ServiceInstances and Applications. The Application Gateway gets deleted with the last ServiceInstance in that Namespace. The Compass mode is enabled by setting the **gatewayOncePerNamespace** [feature flag](https://github.com/kyma-project/kyma/blob/main/components/application-operator/README.md#usage) to true. >**NOTE:** Every Application custom resource corresponds to a single Application to which you can connect an external solution. diff --git a/docs/application-connector-compass-mode/02-04-application-broker.md b/docs/application-connector-compass-mode/02-04-application-broker.md index 493c0d7d5724..e65e0de7a422 100644 --- a/docs/application-connector-compass-mode/02-04-application-broker.md +++ b/docs/application-connector-compass-mode/02-04-application-broker.md @@ -25,7 +25,7 @@ The provisioning and binding workflow for an API ServicePlan consists of the fol 1. Select an API ServiceClass and choose an API ServicePlan from the Service Catalog. 2. Provision the ServiceClass with the chosen API ServicePlan by creating its ServiceInstance in a Namespace. 3. Bind your ServiceInstance to the service or Function. During the binding process, ServiceBinding and ServiceBindingUsage resources are created. - * ServiceBinding contains a Secret with the Gateway URL required to connect to the given API. The Gateway URL is specified under the **sanitized({API\_NAME}_{API_ID})_GATEWAY_URL** field. To learn more about sanitization, refer to the [sanitization function](https://github.com/kyma-project/kyma/blob/master/components/application-broker/internal/broker/bind_creds_renderer.go#L109). + * ServiceBinding contains a Secret with the Gateway URL required to connect to the given API. The Gateway URL is specified under the **sanitized({API\_NAME}_{API_ID})_GATEWAY_URL** field. To learn more about sanitization, refer to the [sanitization function](https://github.com/kyma-project/kyma/blob/main/components/application-broker/internal/broker/bind_creds_renderer.go#L109). >**NOTE:** If you want to call the Application directly and skip the Application Gateway component, use **sanitized({API\_NAME}_{API_ID})_TARGET_URL** with corresponding **CONFIGURATION** and **CREDENTIALS_TYPE**. For more information, read the document about [proxy configuration](https://kyma-project.io/docs/components/application-connector#details-application-gateway-proxy-configuration). * ServiceBindingUsage injects the Secret, together with the label given during the registration process, to the Function or service. 4. The service or Function calls the API through the Application Gateway, allowing you to access the Application API. @@ -40,7 +40,7 @@ This section describes in detail how the API credentials are generated. 1. User creates a ServiceInstance. 2. Service Catalog sends a provisioning request to the Application Broker. 3. Application Broker requests credentials for a ServiceInstance. The request is processed through the Director proxy exposed by Runtime Agent to Director. - >**NOTE:** The Director proxy is secured by [Istio RBAC](https://github.com/kyma-project/kyma/blob/master/resources/compass-runtime-agent/templates/istio-rbac.yaml) and only Application Broker can access it. + >**NOTE:** The Director proxy is secured by [Istio RBAC](https://github.com/kyma-project/kyma/blob/main/resources/compass-runtime-agent/templates/istio-rbac.yaml) and only Application Broker can access it. 4. Application Broker polls credential status with a 20 minute timeout. The polling is completed when the credential status is either `SUCCEEDED` or `FAILED`. diff --git a/docs/application-connector/02-01-application-connector.md b/docs/application-connector/02-01-application-connector.md index 4e6e9e4cfd47..425cc826cbf7 100644 --- a/docs/application-connector/02-01-application-connector.md +++ b/docs/application-connector/02-01-application-connector.md @@ -54,7 +54,7 @@ The AB implements the [Open Service Broker API](https://www.openservicebrokerapi ## Application Operator -The Application Operator (AO) can work in two modes. In the default legacy mode, the AO listens for creating or deleting the [Application](#custom-resource-application) custom resources and acts accordingly, either provisioning or deprovisioning an instance of the Application Gateway and the Event Publisher for every custom resource. In the alternative Compass mode, it listens for an additional resource, [ServiceInstance](service-catalog#details-resources). In this mode, it provisions an instance of the Application Gateway once per Namespace. That means that there is always only one Application Gateway per Namespace, even if there are more ServiceInstances and Applications. The Application Gateway gets deleted with the last ServiceInstance in that Namespace. The Compass mode is enabled by setting the **gatewayOncePerNamespace** [feature flag](https://github.com/kyma-project/kyma/blob/master/components/application-operator/README.md#usage) to true. +The Application Operator (AO) can work in two modes. In the default legacy mode, the AO listens for creating or deleting the [Application](#custom-resource-application) custom resources and acts accordingly, either provisioning or deprovisioning an instance of the Application Gateway and the Event Publisher for every custom resource. In the alternative Compass mode, it listens for an additional resource, [ServiceInstance](service-catalog#details-resources). In this mode, it provisions an instance of the Application Gateway once per Namespace. That means that there is always only one Application Gateway per Namespace, even if there are more ServiceInstances and Applications. The Application Gateway gets deleted with the last ServiceInstance in that Namespace. The Compass mode is enabled by setting the **gatewayOncePerNamespace** [feature flag](https://github.com/kyma-project/kyma/blob/main/components/application-operator/README.md#usage) to true. >**NOTE:** Every Application custom resource corresponds to a single Application to which you can connect an external solution. diff --git a/docs/console/03-04-rafter-in-console.md b/docs/console/03-04-rafter-in-console.md index 7f33e314f5e3..97379744111d 100644 --- a/docs/console/03-04-rafter-in-console.md +++ b/docs/console/03-04-rafter-in-console.md @@ -37,4 +37,4 @@ The source files are uploaded directly to the given storage without any modifica ![Specification types](./assets/spec-types.svg) -> **TIP:** The default Kyma webhooks that convert and validate `asyncapi` source files and extract metadata from `markdown` files are defined in the [`webhook-config-map.yaml`](https://github.com/kyma-project/kyma/blob/master/resources/rafter/charts/controller-manager/templates/webhooks-config-map.yaml) ConfigMap. +> **TIP:** The default Kyma webhooks that convert and validate `asyncapi` source files and extract metadata from `markdown` files are defined in the [`webhook-config-map.yaml`](https://github.com/kyma-project/kyma/blob/main/resources/rafter/charts/controller-manager/templates/webhooks-config-map.yaml) ConfigMap. diff --git a/docs/getting-started/01-overview.md b/docs/getting-started/01-overview.md index 88a74007c184..ec6f3aee234a 100644 --- a/docs/getting-started/01-overview.md +++ b/docs/getting-started/01-overview.md @@ -33,9 +33,9 @@ All guides, whenever possible, demonstrate the steps in both kubectl and Console Let's introduce the main actors that will lead us through the guides. These are our in-house examples, mock applications, and experimental services: -- [`orders-service`](https://github.com/kyma-project/examples/tree/master/orders-service) is a sample microservice written in Go. It can expose HTTP endpoints that can be used to create and read basic order JSON entities. The service can run with either an in-memory database that is enabled by default or an external Redis database. We will use it as an example to show you how you can use Kyma to deploy your own microservice, expose it on HTTP endpoints to make it available for external services, and then bind it to an external database service (Redis). +- [`orders-service`](https://github.com/kyma-project/examples/tree/main/orders-service) is a sample microservice written in Go. It can expose HTTP endpoints that can be used to create and read basic order JSON entities. The service can run with either an in-memory database that is enabled by default or an external Redis database. We will use it as an example to show you how you can use Kyma to deploy your own microservice, expose it on HTTP endpoints to make it available for external services, and then bind it to an external database service (Redis). -- [`orders-function`](https://github.com/kyma-project/examples/tree/master/orders-service/deployment/orders-function.yaml) that is an equivalent of `orders-service`. Function's configuration allows you to save individual order data in its storage and retrieve multiple order records it. Like the microservice, the Function can run with either an in-memory database or a Redis instance. +- [`orders-function`](https://github.com/kyma-project/examples/tree/main/orders-service/deployment/orders-function.yaml) that is an equivalent of `orders-service`. Function's configuration allows you to save individual order data in its storage and retrieve multiple order records it. Like the microservice, the Function can run with either an in-memory database or a Redis instance. - [Redis addon](https://github.com/kyma-project/addons/tree/master/addons/redis-0.0.3) is basically a bundle of two Redis services available in two plans: `micro` and `enterprise`. You will connect it to Kyma through Helm Broker and expose it in the Kyma cluster as an addon under Service Catalog. The Redis service represents an open-source, in-memory data structure store used as a database, cache, and message broker. For the purpose of these guides, you will use the `micro` plan with in-memory storage to demonstrate how it can replace the default memory of the microservice. diff --git a/docs/getting-started/03-deploy-microservice.md b/docs/getting-started/03-deploy-microservice.md index eac20a630497..ccfa98a12c91 100644 --- a/docs/getting-started/03-deploy-microservice.md +++ b/docs/getting-started/03-deploy-microservice.md @@ -3,7 +3,7 @@ title: Deploy a microservice type: Getting Started --- -You will now deploy a standalone [`orders-service`](https://github.com/kyma-project/examples/blob/master/orders-service/README.md) microservice in the `orders-service` Namespace. This microservice will act as a link between the external application and the Redis service and we will build the whole end-to-end flow around it. +You will now deploy a standalone [`orders-service`](https://github.com/kyma-project/examples/blob/main/orders-service/README.md) microservice in the `orders-service` Namespace. This microservice will act as a link between the external application and the Redis service and we will build the whole end-to-end flow around it. In this guide you will create: @@ -27,7 +27,7 @@ Follow these steps: 1. Apply the microservice definition to the `orders-service` Namespace on your cluster: ```bash -kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/deployment/orders-service-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/deployment/orders-service-deployment.yaml ``` 2. Check that the Deployment was created. The correct Deployment status sets **readyReplicas** to `1`: @@ -42,7 +42,7 @@ kubectl get deployment orders-service -n orders-service -o=jsonpath="{.status.re Console UI -1. On your machine, create `orders-service-deployment.yaml` containing [this Deployment definition](https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/deployment/orders-service-deployment.yaml). +1. On your machine, create `orders-service-deployment.yaml` containing [this Deployment definition](https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/deployment/orders-service-deployment.yaml). 2. Back in the Console UI, go to the `orders-service` Namespace overview and select **Deploy new workload** > **Upload YAML**. 3. Browse the `orders-service-deployment.yaml` file and select **Deploy** to confirm the changes. 4. Go to **Workloads** > **Deployments** to make sure the status of `orders-service` is `RUNNING`. @@ -65,7 +65,7 @@ Follow these steps: Apply the Kubernetes Service to the `orders-service` Namespace on your cluster: ```bash -kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/deployment/orders-service-service.yaml +kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/deployment/orders-service-service.yaml ``` @@ -74,7 +74,7 @@ kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/master/ Console UI -1. On your machine, create `orders-service-service.yaml` containing [this Service definition](https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/deployment/orders-service-service.yaml). +1. On your machine, create `orders-service-service.yaml` containing [this Service definition](https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/deployment/orders-service-service.yaml). 2. Back in the Console UI, go to the `orders-service` Namespace overview and select **Deploy new workload** > **Upload YAML**. 3. Browse the `orders-service-service.yaml` file and select **Deploy** to confirm the changes. 4. Go to **Discovery and Network** > **Services** to make sure the status of `orders-service` is `RUNNING`. diff --git a/docs/getting-started/10-create-function.md b/docs/getting-started/10-create-function.md index 111f55a396b2..e02e77bc0591 100644 --- a/docs/getting-started/10-create-function.md +++ b/docs/getting-started/10-create-function.md @@ -22,7 +22,7 @@ Follows these steps: 1. Apply a [Function CR](/components/serverless/#custom-resource-function) that specifies the Function's logic: ```bash - kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/deployment/orders-function.yaml + kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/deployment/orders-function.yaml ``` 2. Check that the Function was created and all its conditions are set to `True`: @@ -54,7 +54,7 @@ Follows these steps: The pop-up box will close and a message on the screen will confirm that the Function was created. -4. In the **Source** tab of the automatically opened Function details view, enter the Function's code from the [`handler.js`](https://raw.githubusercontent.com/kyma-project/examples/master/orders-service/function/handler.js) file. +4. In the **Source** tab of the automatically opened Function details view, enter the Function's code from the [`handler.js`](https://raw.githubusercontent.com/kyma-project/examples/main/orders-service/function/handler.js) file. 5. In the **Dependencies** tab, enter: diff --git a/docs/helm-broker/01-01-helm-broker.md b/docs/helm-broker/01-01-helm-broker.md index 661d9fb1ce75..3ac77e6cf14c 100644 --- a/docs/helm-broker/01-01-helm-broker.md +++ b/docs/helm-broker/01-01-helm-broker.md @@ -4,7 +4,7 @@ title: Overview The Helm Broker is a [Service Broker](/components/service-catalog/#overview-service-brokers) which exposes Helm charts as Service Classes in the [Service Catalog](/components/service-catalog/). To do so, the Helm Broker uses the concept of addons. An addon is an abstraction layer over a Helm chart which provides all information required to convert the chart into a Service Class. -The Helm Broker fetches addons which contain a set of specific [files](#details-create-addons). You must place your addons in a repository of an appropriate [format](#details-create-addons-repository). The Helm Broker fetches default cluster-wide addons defined by the [helm-repos-urls](https://github.com/kyma-project/kyma/blob/master/resources/helm-broker/templates/default-addons-cfg.yaml) custom resource (CR). This CR contains URLs that point to the release of [`addons`](https://github.com/kyma-project/addons/releases) repository compatible with a given [Kyma release](https://github.com/kyma-project/kyma/releases). You can also configure the Helm Broker to fetch addons definitions from other addons repositories. +The Helm Broker fetches addons which contain a set of specific [files](#details-create-addons). You must place your addons in a repository of an appropriate [format](#details-create-addons-repository). The Helm Broker fetches default cluster-wide addons defined by the [helm-repos-urls](https://github.com/kyma-project/kyma/blob/main/resources/helm-broker/templates/default-addons-cfg.yaml) custom resource (CR). This CR contains URLs that point to the release of [`addons`](https://github.com/kyma-project/addons/releases) repository compatible with a given [Kyma release](https://github.com/kyma-project/kyma/releases). You can also configure the Helm Broker to fetch addons definitions from other addons repositories. In Kyma, you can use addons to install the following Service Brokers: @@ -20,4 +20,4 @@ To be compliant with the Service Catalog version used in Kyma, the Helm Broker s - v2.12 - v2.11 -> **NOTE:** The Helm Broker does not implement the OSB API update operation. +> **NOTE:** Helm Broker does not implement the OSB API update operation. diff --git a/docs/helm-broker/02-01-helm-broker.md b/docs/helm-broker/02-01-helm-broker.md index c1582074d6fa..8edd90d8a639 100644 --- a/docs/helm-broker/02-01-helm-broker.md +++ b/docs/helm-broker/02-01-helm-broker.md @@ -3,7 +3,7 @@ title: Basic architecture type: Architecture --- -The Helm Broker is installed alongside other Kyma components and it automatically registers itself in the Service Catalog as a ClusterServiceBroker. The installation provides the default [helm-repos-urls](https://github.com/kyma-project/kyma/blob/master/resources/helm-broker/templates/addons-cfg.yaml) ClusterAddonsConfiguration (CAC) custom resource (CR). It contains URLs from which Helm Broker fetches addons. You can also add your own addons with URLs that point to [your addons repository](#details-create-addons-repository). +The Helm Broker is installed alongside other Kyma components and it automatically registers itself in the Service Catalog as a ClusterServiceBroker. The installation provides the default [helm-repos-urls](https://github.com/kyma-project/kyma/blob/main/resources/helm-broker/templates/addons-cfg.yaml) ClusterAddonsConfiguration (CAC) custom resource (CR). It contains URLs from which Helm Broker fetches addons. You can also add your own addons with URLs that point to [your addons repository](#details-create-addons-repository). If you want the Helm Broker to act as a Namespace-scoped ServiceBroker, create the [AddonsConfiguration](#custom-resource-addonsconfiguration) (AC) CR. In such a case, the Helm Broker creates a service and registers itself in the Service Catalog as a ServiceBroker inside the Namespace in which the CR is created. diff --git a/docs/helm-broker/03-04-create-addons-repo.md b/docs/helm-broker/03-04-create-addons-repo.md index aa4d90760177..2d232a89fede 100644 --- a/docs/helm-broker/03-04-create-addons-repo.md +++ b/docs/helm-broker/03-04-create-addons-repo.md @@ -94,7 +94,7 @@ See the [example](https://github.com/kyma-project/addons/tree/master/addons) of You can specify a Git repository URL by adding a special `git::` prefix to the URL address. After this prefix, provide any valid Git URL with one of the protocols supported by Git. In the URL, you can specify a branch, commit, or tag version. You can also add the `depth` query parameter with a number that specifies the last revision you want to clone from the repository. ->**NOTE:** If you use `depth` together with `ref`, make sure that `depth` number is big enough to clone a proper reference. For example, if you have `depth=1` and `ref` set to a commit from the distant past, the URL will not work as you clone only the first commit from the `master` branch and there is no option to do the checkout. +>**NOTE:** If you use `depth` together with `ref`, make sure that `depth` number is big enough to clone a proper reference. For example, if you have `depth=1` and `ref` set to a commit from the distant past, the URL will not work as you clone only the first commit from the `main` branch and there is no option to do the checkout. These are the allowed addon repository URLs provided in CAC or AC custom resources for Git: ```yaml diff --git a/docs/helm-broker/03-05-registration-rules.md b/docs/helm-broker/03-05-registration-rules.md index 94a39150e0de..e9587689456e 100644 --- a/docs/helm-broker/03-05-registration-rules.md +++ b/docs/helm-broker/03-05-registration-rules.md @@ -7,7 +7,7 @@ This document presents the rules you must follow when you configure the Helm Bro ## Using HTTP URLs -On your non-local clusters, you can use only servers with TLS enabled. All incorrect or unsecured URLs will be omitted. Find the information about the rejected URLs in the Helm Broker logs. You can use unsecured URLs only on your local cluster. To use URLs without TLS enabled, set the **global.isDevelopMode** environment variable in the [`values.yaml`](https://github.com/kyma-project/kyma/blob/master/resources/helm-broker/values.yaml) file to `true`. +On your non-local clusters, you can use only servers with TLS enabled. All incorrect or unsecured URLs will be omitted. Find the information about the rejected URLs in the Helm Broker logs. You can use unsecured URLs only on your local cluster. To use URLs without TLS enabled, set the **global.isDevelopMode** environment variable in the [`values.yaml`](https://github.com/kyma-project/kyma/blob/main/resources/helm-broker/values.yaml) file to `true`. ## Registering the same ID multiple times diff --git a/docs/kiali/05-01-kiali.md b/docs/kiali/05-01-kiali.md index 7af7d3a802e1..a1e05e3d5fd0 100644 --- a/docs/kiali/05-01-kiali.md +++ b/docs/kiali/05-01-kiali.md @@ -24,4 +24,4 @@ This table lists the configurable parameters, their descriptions, and default va | **kiali.spec.deployment.resources.limits.memory** | Maximum amount of memory available for the Kiali Deployment to use. | `100Mi` | | **kiali.spec.kubernetes_config.qps** | Defines the allowed queries per second to adjust the API server's throttling rate. | `50` | -For more details on Kiali configuration and customization, see the [`values.yaml`](https://github.com/kyma-project/kyma/blob/master/resources/kiali/values.yaml) file. +For more details on Kiali configuration and customization, see the [`values.yaml`](https://github.com/kyma-project/kyma/blob/main/resources/kiali/values.yaml) file. diff --git a/docs/kyma/04-01-overview.md b/docs/kyma/04-01-overview.md index 7de17ee7bdc7..1e826e777ca1 100644 --- a/docs/kyma/04-01-overview.md +++ b/docs/kyma/04-01-overview.md @@ -42,7 +42,7 @@ By default, Kyma is installed with the default chart values defined in the `valu - Evaluation - a profile with limited resources that you can use for trial purposes - Production - a profile configured for high availability and scalability. It requires more resources than the evaluation profile but is a better choice for production workload. -You can check the values used for each component in respective folders of the [`resources`](https://github.com/kyma-project/kyma/tree/master/resources) directory. The `profile-evaluation.yaml` file contains values used for the evaluation profile, and the `profile-production.yaml` file contains values for the production profile. If the component doesn't have files for respective profiles, the profile values are the same as default chart values defined in the `values.yaml` file. +You can check the values used for each component in respective folders of the [`resources`](https://github.com/kyma-project/kyma/tree/main/resources) directory. The `profile-evaluation.yaml` file contains values used for the evaluation profile, and the `profile-production.yaml` file contains values for the production profile. If the component doesn't have files for respective profiles, the profile values are the same as default chart values defined in the `values.yaml` file. A profile is defined globally for the whole Kyma installation. It's not possible to install a profile only for the selected components. However, you can set [overrides](#configuration-helm-overrides-for-kyma-installation) to override values set for the profile. The profile values have precedence over the default chart values, and overrides have precedence over the applied profile. diff --git a/docs/kyma/04-03-cluster-installation.md b/docs/kyma/04-03-cluster-installation.md index 4094cfbc7a43..3d56eb27ed2e 100644 --- a/docs/kyma/04-03-cluster-installation.md +++ b/docs/kyma/04-03-cluster-installation.md @@ -73,7 +73,7 @@ This installation guide explains how you can quickly deploy Kyma on a cluster wi GKE -1. Create a service account and a service account key as JSON following [these steps](https://github.com/kyma-incubator/hydroform/blob/master/provision/examples/gcp/README.md#configure-gcp). +1. Create a service account and a service account key as JSON following [these steps](https://github.com/kyma-incubator/hydroform/blob/main/provision/examples/gcp/README.md#configure-gcp). 2. Export the cluster name, the name of your GCP project, and the [zone](https://cloud.google.com/compute/docs/regions-zones/) you want to deploy to as environment variables: @@ -177,14 +177,14 @@ This installation guide explains how you can quickly deploy Kyma on a cluster wi ``` kyma provision gardener gcp -n {cluster_name} -p {project_name} -s {kyma_gardener_gcp_secret_name} -c {path_to_gardener_kubeconfig} ``` - See the complete [list of flags and their descriptions](https://github.com/kyma-project/cli/blob/master/docs/gen-docs/kyma_provision_gardener_gcp.md). + See the complete [list of flags and their descriptions](https://github.com/kyma-project/cli/blob/main/docs/gen-docs/kyma_provision_gardener_gcp.md). To provision a Gardener cluster on Azure, run: ``` kyma provision gardener az -n {cluster_name} -p {project_name} -s {kyma_gardener_azure_secret_name} -c {path_to_gardener_kubeconfig} ``` - See the complete [list of flags and their descriptions](https://github.com/kyma-project/cli/blob/master/docs/gen-docs/kyma_provision_gardener_az.md). + See the complete [list of flags and their descriptions](https://github.com/kyma-project/cli/blob/main/docs/gen-docs/kyma_provision_gardener_az.md). 3. After you provision the cluster, its `kubeconfig` file will be downloaded and automatically set as the current context. @@ -205,7 +205,7 @@ To install Kyma with one of the predefined [profiles](#installation-overview-pro kyma install -s $KYMA_VERSION --profile {evaluation|production} ``` ->**NOTE:** If you don't specify `$KYMA_VERSION`, the version from the latest commit on the `master` branch is installed. If you don't specify the profile, the default version of Kyma is installed. +>**NOTE:** If you don't specify `$KYMA_VERSION`, the version from the latest commit on the `main` branch is installed. If you don't specify the profile, the default version of Kyma is installed. ## Post-installation steps diff --git a/docs/kyma/04-04-use-your-own-domain.md b/docs/kyma/04-04-use-your-own-domain.md index 1d871ce30e6e..e5faa9ca1481 100644 --- a/docs/kyma/04-04-use-your-own-domain.md +++ b/docs/kyma/04-04-use-your-own-domain.md @@ -310,7 +310,7 @@ Get the TLS certificate: GKE -1. Create a service account and a service account key as JSON following [these steps](https://github.com/kyma-incubator/hydroform/blob/master/provision/examples/gcp/README.md#configure-gcp). +1. Create a service account and a service account key as JSON following [these steps](https://github.com/kyma-incubator/hydroform/blob/main/provision/examples/gcp/README.md#configure-gcp). 2. Export the cluster name, the name of your GCP project, and the [zone](https://cloud.google.com/compute/docs/regions-zones/) you want to deploy to as environment variables: diff --git a/docs/kyma/04-05-use-your-own-image.md b/docs/kyma/04-05-use-your-own-image.md index 95c4b5fda749..a660995e5425 100644 --- a/docs/kyma/04-05-use-your-own-image.md +++ b/docs/kyma/04-05-use-your-own-image.md @@ -6,7 +6,7 @@ type: Installation When you install Kyma from a release, you use the release artifacts that already contain the Kyma Installer - a Docker image containing the combined binary of the Kyma Operator and the component charts from the `/resources` folder. If you want to install Kyma from sources, you must build the image yourself. You also require a new image if you add components and custom Helm charts that are not included in the `/resources` folder to the installation. -Alternatively, you can also install Kyma from the latest master or any previous master commit using Kyma CLI. See different [installation source flags](https://github.com/kyma-project/cli/blob/master/docs/gen-docs/kyma_install.md#flags). +Alternatively, you can also install Kyma from the latest main or any previous main commit using Kyma CLI. See different [installation source flags](https://github.com/kyma-project/cli/blob/main/docs/gen-docs/kyma_install.md#flags). In addition to the tools required to install Kyma on a cluster, you also need: @@ -24,7 +24,7 @@ In addition to the tools required to install Kyma on a cluster, you also need: ```bash git clone https://github.com/kyma-project/kyma.git ; cd kyma ``` - +
diff --git a/docs/kyma/04-07-upgrade.md b/docs/kyma/04-07-upgrade.md index a64f1e4b4a1e..0423cfa12632 100644 --- a/docs/kyma/04-07-upgrade.md +++ b/docs/kyma/04-07-upgrade.md @@ -19,7 +19,7 @@ For example, if you're running Kyma 1.0 and you want to upgrade to version 1.3, The upgrade procedure relies heavily on Helm. As a result, the availability of cluster services during the upgrade is not defined by Kyma and can vary from version to version. The existing custom resources (CRs) remain in the cluster. -For more details, read about the [technical aspects](https://github.com/kyma-project/kyma/blob/master/components/kyma-operator/README.md#upgrade-kyma) of the upgrade. +For more details, read about the [technical aspects](https://github.com/kyma-project/kyma/blob/main/components/kyma-operator/README.md#upgrade-kyma) of the upgrade. ## Upgrade Kyma to a newer version diff --git a/docs/kyma/04-08-update.md b/docs/kyma/04-08-update.md index 92e81961659a..d90c4750052c 100644 --- a/docs/kyma/04-08-update.md +++ b/docs/kyma/04-08-update.md @@ -34,7 +34,7 @@ In case of dependency conflicts or major changes between components versions, so ## Prepare the update -- If you update an existing component, make all required changes to the Helm charts of the component located in the [`resources`](https://github.com/kyma-project/kyma/tree/master/resources) directory. +- If you update an existing component, make all required changes to the Helm charts of the component located in the [`resources`](https://github.com/kyma-project/kyma/tree/main/resources) directory. - If you add a new component to your Kyma deployment, add a top-level Helm chart for that component. Additionally, download the current [Installation custom resource](#custom-resource-installation) from the cluster and add the new component to the components list: diff --git a/docs/kyma/05-02-custom-component-installation.md b/docs/kyma/05-02-custom-component-installation.md index ff525937b96e..00840348ea99 100644 --- a/docs/kyma/05-02-custom-component-installation.md +++ b/docs/kyma/05-02-custom-component-installation.md @@ -5,7 +5,7 @@ type: Configuration By default, you install Kyma with a set of components provided in the [**Kyma Lite**](#installation-overview) package. -During installation, the Kyma Installer applies the content of the [local](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr.yaml.tpl#L14) or [cluster](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr-cluster.yaml.tpl#L14) installation file that includes the list of component names and Namespaces in which the components are installed. The Installer skips the lines starting with a hash character (#): +During installation, the Kyma Installer applies the content of the [local](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr.yaml.tpl#L14) or [cluster](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr-cluster.yaml.tpl#L14) installation file that includes the list of component names and Namespaces in which the components are installed. The Installer skips the lines starting with a hash character (#): ```yaml # - name: "tracing" @@ -31,11 +31,11 @@ Read the subsections for details. You can provide a custom list of components to Kyma CLI during the installation. The version of your component's deployment must match the version that Kyma currently supports. ->**NOTE:** For some components, you must perform additional actions to exclude them from the Kyma installation. In case of the Service Catalog, you must provide your own deployment of this component in the Kyma-supported version before you remove them from the installation process. See the [`values.yaml`](https://github.com/kyma-project/kyma/blob/master/resources/service-catalog/charts/catalog/values.yaml#L3) file for the currently supported version of the Service Catalog. +>**NOTE:** For some components, you must perform additional actions to exclude them from the Kyma installation. In case of the Service Catalog, you must provide your own deployment of this component in the Kyma-supported version before you remove them from the installation process. See the [`values.yaml`](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog/charts/catalog/values.yaml#L3) file for the currently supported version of the Service Catalog. ### Installation from the release -1. Create a file with the list of components you desire to install. You can copy and paste most of the components from the regular [installation file](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr-cluster.yaml.tpl#L14), then modify the list as you like. An example file can look like the following: +1. Create a file with the list of components you desire to install. You can copy and paste most of the components from the regular [installation file](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr-cluster.yaml.tpl#L14), then modify the list as you like. An example file can look like the following: ```yaml components: @@ -57,8 +57,8 @@ components: 1. Customize the installation by adding a component to the list of components or removing the hash character (#) in front of the `name` and `namespace` entries in the following installation files: - * [`installer-cr.yaml.tpl`](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr.yaml.tpl) for the **local** installation - * [`installer-cr-cluster.yaml.tpl`](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr-cluster.yaml.tpl) for the **cluster** installation + * [`installer-cr.yaml.tpl`](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr.yaml.tpl) for the **local** installation + * [`installer-cr-cluster.yaml.tpl`](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr-cluster.yaml.tpl) for the **cluster** installation 2. Follow the installation steps to [install Kyma locally from sources](#installation-install-kyma-locally) or [install Kyma on a cluster](#installation-install-kyma-on-a-cluster). diff --git a/docs/kyma/05-03-overrides.md b/docs/kyma/05-03-overrides.md index 4baa3ec4fa64..12bd93faa223 100644 --- a/docs/kyma/05-03-overrides.md +++ b/docs/kyma/05-03-overrides.md @@ -3,7 +3,7 @@ title: Helm overrides for Kyma installation type: Configuration --- -Kyma packages its components into [Helm](https://helm.sh/docs/) charts that the [Kyma Operator](https://github.com/kyma-project/kyma/tree/master/components/kyma-operator) uses during installation and updates. +Kyma packages its components into [Helm](https://helm.sh/docs/) charts that the [Kyma Operator](https://github.com/kyma-project/kyma/tree/main/components/kyma-operator) uses during installation and updates. This document describes how to configure the Kyma Installer with new values for Helm [charts](https://v2.helm.sh/docs/developing_charts/) to override the default settings in `values.yaml` files. ## Overview diff --git a/docs/kyma/16-01-try-out-kyma.md b/docs/kyma/16-01-try-out-kyma.md index 775fc8bc88d7..aae53f046857 100644 --- a/docs/kyma/16-01-try-out-kyma.md +++ b/docs/kyma/16-01-try-out-kyma.md @@ -9,9 +9,9 @@ Follow the links to examples' code and content sources, and try them on your own | Example | Description | Technology | |---|---|---| -| [Orders Service](https://github.com/kyma-project/examples/blob/master/orders-service/README.md) | This example demonstrates how you can use Kyma to expose microservices and Functions on HTTP endpoints and bind them to an external database. | Go, Redis | -| [HTTP DB Service](https://github.com/kyma-project/examples/blob/master/http-db-service/README.md) | Test the service that exposes an HTTP API to access a database on the cluster. | Go, MSSQL | -| [Alert Rules](https://github.com/kyma-project/examples/blob/master/monitoring-alert-rules/README.md) | Configure alert rules in Kyma. | Prometheus | -| [Custom Metrics in Kyma](https://github.com/kyma-project/examples/blob/master/monitoring-custom-metrics/README.md) | Expose custom metrics in Kyma. | Go, Prometheus | -| [Event Email Service](https://github.com/kyma-project/examples/blob/master/event-email-service/README.md) | Send an automated email upon receiving an Event. | NodeJS | -| [Tracing](https://github.com/kyma-project/examples/blob/master/tracing/README.md) | Configure tracing for a service in Kyma. | Go | +| [Orders Service](https://github.com/kyma-project/examples/blob/main/orders-service/README.md) | This example demonstrates how you can use Kyma to expose microservices and Functions on HTTP endpoints and bind them to an external database. | Go, Redis | +| [HTTP DB Service](https://github.com/kyma-project/examples/blob/main/http-db-service/README.md) | Test the service that exposes an HTTP API to access a database on the cluster. | Go, MSSQL | +| [Alert Rules](https://github.com/kyma-project/examples/blob/main/monitoring-alert-rules/README.md) | Configure alert rules in Kyma. | Prometheus | +| [Custom Metrics in Kyma](https://github.com/kyma-project/examples/blob/main/monitoring-custom-metrics/README.md) | Expose custom metrics in Kyma. | Go, Prometheus | +| [Event Email Service](https://github.com/kyma-project/examples/blob/main/event-email-service/README.md) | Send an automated email upon receiving an Event. | NodeJS | +| [Tracing](https://github.com/kyma-project/examples/blob/main/tracing/README.md) | Configure tracing for a service in Kyma. | Go | diff --git a/docs/monitoring/03-01-alertmanager.md b/docs/monitoring/03-01-alertmanager.md index e9bd12f8c777..20904541baff 100644 --- a/docs/monitoring/03-01-alertmanager.md +++ b/docs/monitoring/03-01-alertmanager.md @@ -14,6 +14,6 @@ Use the following files to configure and manage Alertmanager: ## Alerting rules -Kyma comes with a set of [alerting rules](https://github.com/kyma-project/kyma/tree/master/resources/monitoring/templates/prometheus/rules-1.14) provided out of the box. +Kyma comes with a set of [alerting rules](https://github.com/kyma-project/kyma/tree/main/resources/monitoring/templates/prometheus/rules-1.14) provided out of the box. These rules provide alerting configuration for logging, web apps, rest services, and custom Kyma rules. You can also define your own alerting rule. To learn how, see the [tutorial](/components/monitoring/#tutorials-define-alerting-rules). diff --git a/docs/monitoring/08-01-overview.md b/docs/monitoring/08-01-overview.md index 656f12aae2e0..06eff7dbd424 100644 --- a/docs/monitoring/08-01-overview.md +++ b/docs/monitoring/08-01-overview.md @@ -5,7 +5,7 @@ type: Tutorials The set of monitoring tutorials you are about to read describes the complete monitoring flow for your services in Kyma. Going through the tutorials, you get the gist of Kyma built-in monitoring applications, such as Prometheus, Grafana, and Alertmanager. This hands-on experience with monitoring helps you understand how and where you can observe and visualize your service metrics to monitor them for any alerting values. -All the tutorials use the [`monitoring-custom-metrics`](https://github.com/kyma-project/examples/tree/master/monitoring-custom-metrics) example and one of its services called `sample-metrics-8081`. This service exposes the `cpu_temperature_celsius` custom metric on the `/metrics` endpoint. This custom metric is the central element of the whole tutorial set. The metric value simulates the current processor temperature and changes randomly from 60 to 90 degrees Celsius. The alerting threshold in these tutorials is 75 degrees Celsius. If the temperature exceeds this value, the Grafana dashboard, Prometheus rule, and Alertmanager notifications you create inform you about this. +All the tutorials use the [`monitoring-custom-metrics`](https://github.com/kyma-project/examples/tree/main/monitoring-custom-metrics) example and one of its services called `sample-metrics-8081`. This service exposes the `cpu_temperature_celsius` custom metric on the `/metrics` endpoint. This custom metric is the central element of the whole tutorial set. The metric value simulates the current processor temperature and changes randomly from 60 to 90 degrees Celsius. The alerting threshold in these tutorials is 75 degrees Celsius. If the temperature exceeds this value, the Grafana dashboard, Prometheus rule, and Alertmanager notifications you create inform you about this. The tutorial set consists of these documents: diff --git a/docs/monitoring/08-02-observe-application-metrics.md b/docs/monitoring/08-02-observe-application-metrics.md index 7442e299c865..63f230b0f692 100644 --- a/docs/monitoring/08-02-observe-application-metrics.md +++ b/docs/monitoring/08-02-observe-application-metrics.md @@ -5,7 +5,7 @@ type: Tutorials This tutorial shows how you can observe your application metrics. Learn how to list all metrics exposed by a sample Go service and watch their changing values by redirecting the metrics port and the default Prometheus server port to the localhost. -This tutorial uses the [`monitoring-custom-metrics`](https://github.com/kyma-project/examples/tree/master/monitoring-custom-metrics) example and one of its services named `sample-metrics-8081`. The service exposes its metrics on the standard `/metrics` endpoint that is available under port `8081`. You deploy the service (`deployment.yaml`) along with the ServiceMonitor custom resource (`service-monitor.yaml`) that instructs Prometheus to scrape metrics: +This tutorial uses the [`monitoring-custom-metrics`](https://github.com/kyma-project/examples/tree/main/monitoring-custom-metrics) example and one of its services named `sample-metrics-8081`. The service exposes its metrics on the standard `/metrics` endpoint that is available under port `8081`. You deploy the service (`deployment.yaml`) along with the ServiceMonitor custom resource (`service-monitor.yaml`) that instructs Prometheus to scrape metrics: - From the service with the `k8s-app: metrics` label - From the `/metrics` endpoint @@ -44,13 +44,13 @@ Follow these steps: 2. Deploy the sample service in the `testing-monitoring` Namespace. ```bash - kubectl create -f https://raw.githubusercontent.com/kyma-project/examples/master/monitoring-custom-metrics/deployment/deployment.yaml --namespace=testing-monitoring + kubectl create -f https://raw.githubusercontent.com/kyma-project/examples/main/monitoring-custom-metrics/deployment/deployment.yaml --namespace=testing-monitoring ``` 3. Deploy the ServiceMonitor custom resource definition (CRD) in the `kyma-system` Namespace that is a default Namespace for all ServiceMonitor CRDs. ```bash - kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/master/monitoring-custom-metrics/deployment/service-monitor.yaml + kubectl apply -f https://raw.githubusercontent.com/kyma-project/examples/main/monitoring-custom-metrics/deployment/service-monitor.yaml ``` 4. Test your deployment. diff --git a/docs/monitoring/08-03-create-and-configure-grafana-dashboard.md b/docs/monitoring/08-03-create-and-configure-grafana-dashboard.md index df33dbbe338d..9c94eb163ed6 100644 --- a/docs/monitoring/08-03-create-and-configure-grafana-dashboard.md +++ b/docs/monitoring/08-03-create-and-configure-grafana-dashboard.md @@ -85,4 +85,4 @@ Refresh the browser to see how the dashboard changes according to the current va ![Red dashboard](./assets/red-dashboard.png) ->**NOTE:** You can also define the dashboard's ConfigMap and add it to the `resources` folder under the given component's chart. To make the dashboard visible, simply use the `kubectl apply` command to deploy it. For details on adding monitoring to components, see the [`README.md`](https://github.com/kyma-project/kyma/blob/master/resources/monitoring/charts/grafana/README.md) document. +>**NOTE:** You can also define the dashboard's ConfigMap and add it to the `resources` folder under the given component's chart. To make the dashboard visible, simply use the `kubectl apply` command to deploy it. For details on adding monitoring to components, see the [`README.md`](https://github.com/kyma-project/kyma/blob/main/resources/monitoring/charts/grafana/README.md) document. diff --git a/docs/monitoring/08-05-send-notifications.md b/docs/monitoring/08-05-send-notifications.md index b2735db78e32..a16dccb84f74 100644 --- a/docs/monitoring/08-05-send-notifications.md +++ b/docs/monitoring/08-05-send-notifications.md @@ -22,7 +22,7 @@ Follow these steps to configure notifications for Slack every time Alertmanager ![Integration Settings](./assets/integration-settings.png) -3. Override Alertmanager configuration. The configuration for notification receivers is located in the [template](https://github.com/kyma-project/kyma/blob/master/resources/monitoring/templates/kyma-additions/alertmanager.config.yaml). By default, it contains settings for VictorOps and Slack. Define a Secret to [override](/root/kyma/#configuration-helm-overrides-for-kyma-installation) default [values](https://github.com/kyma-project/kyma/blob/master/resources/monitoring/charts/prometheus-node-exporter/values.yaml) used by the chart. +3. Override Alertmanager configuration. The configuration for notification receivers is located in the [template](https://github.com/kyma-project/kyma/blob/main/resources/monitoring/templates/kyma-additions/alertmanager.config.yaml). By default, it contains settings for VictorOps and Slack. Define a Secret to [override](/root/kyma/#configuration-helm-overrides-for-kyma-installation) default [values](https://github.com/kyma-project/kyma/blob/main/resources/monitoring/charts/prometheus-node-exporter/values.yaml) used by the chart. ```yaml apiVersion: v1 diff --git a/docs/rafter/05-01-rafter.md b/docs/rafter/05-01-rafter.md index 0c47967c6690..ddc942b796df 100644 --- a/docs/rafter/05-01-rafter.md +++ b/docs/rafter/05-01-rafter.md @@ -30,8 +30,8 @@ This table lists the configurable parameters, their descriptions, and default va | **controller-manager.pod.resources.requests.memory** | Requests for memory resources. | `32Mi` | | **controller-manager.envs.clusterAssetGroup.relistInterval** | Time intervals in which the Rafter Controller Manager verifies the ClusterAssetGroup for changes. | `5m` | | **controller-manager.envs.assetGroup.relistInterval** | Time intervals in which the Rafter Controller Manager verifies the AssetGroup for changes. | `5m` | -| **controller-manager.envs.clusterBucket.region** | Regional location of the ClusterBucket in a given cloud storage. Use one of the available [regions](https://github.com/kyma-project/kyma/blob/master/resources/cluster-essentials/files/clusterbuckets.rafter.crd.yaml#L53). | `us-east-1` | -| **controller-manager.envs.bucket.region** | Regional location of the bucket in a given cloud storage. Use one of the available [regions](https://github.com/kyma-project/kyma/blob/master/resources/cluster-essentials/files/buckets.rafter.crd.yaml#L53). | `us-east-1` | +| **controller-manager.envs.clusterBucket.region** | Regional location of the ClusterBucket in a given cloud storage. Use one of the available [regions](https://github.com/kyma-project/kyma/blob/main/resources/cluster-essentials/files/clusterbuckets.rafter.crd.yaml#L53). | `us-east-1` | +| **controller-manager.envs.bucket.region** | Regional location of the bucket in a given cloud storage. Use one of the available [regions](https://github.com/kyma-project/kyma/blob/main/resources/cluster-essentials/files/buckets.rafter.crd.yaml#L53). | `us-east-1` | | **controller-manager.envs.clusterBucket.maxConcurrentReconciles** | Maximum number of cluster bucket concurrent reconciles which will run. | `1` | | **controller-manager.envs.bucket.maxConcurrentReconciles** | Maximum number of bucket concurrent reconciles which will run. | `1` | | **controller-manager.envs.clusterAsset.maxConcurrentReconciles** | Maximum number of cluster asset concurrent reconciles which will run. | `1` | diff --git a/docs/rafter/06-05-clusterassetgroup.md b/docs/rafter/06-05-clusterassetgroup.md index 739b773ab67b..5aa5a1fc324e 100644 --- a/docs/rafter/06-05-clusterassetgroup.md +++ b/docs/rafter/06-05-clusterassetgroup.md @@ -34,7 +34,7 @@ spec: mode: package parameters: disableRelativeLinks: "true" - url: https://github.com/kyma-project/kyma/archive/master.zip + url: https://github.com/kyma-project/kyma/archive/main.zip filter: /docs/service-mesh/docs/ status: lastHeartbeatTime: "2019-03-18T13:42:55Z" diff --git a/docs/runtime-agent/04-01-installation-modes.md b/docs/runtime-agent/04-01-installation-modes.md index 66d5abed792d..2ab4d49e175b 100644 --- a/docs/runtime-agent/04-01-installation-modes.md +++ b/docs/runtime-agent/04-01-installation-modes.md @@ -2,7 +2,7 @@ title: Installation --- -To enable Kyma with the Runtime Agent, follow the cluster Kyma installation using the [`installer-cr-cluster-runtime.yaml.tpl`](https://github.com/kyma-project/kyma/blob/master/installation/resources/installer-cr-cluster-runtime.yaml.tpl) configuration file and enable the `compass-runtime-agent` module. The default [legacy mode](#architecture-application-connector-components-application-operator) used in Kyma does not support integration with Compass. For that reason, before you start the installation, apply the following ConfigMap which disables components used in the legacy mode, such as the Application Registry and the Connector Service: +To enable Kyma with the Runtime Agent, follow the cluster Kyma installation using the [`installer-cr-cluster-runtime.yaml.tpl`](https://github.com/kyma-project/kyma/blob/main/installation/resources/installer-cr-cluster-runtime.yaml.tpl) configuration file and enable the `compass-runtime-agent` module. The default [legacy mode](#architecture-application-connector-components-application-operator) used in Kyma does not support integration with Compass. For that reason, before you start the installation, apply the following ConfigMap which disables components used in the legacy mode, such as the Application Registry and the Connector Service: ```yaml cat <**NOTE:** You can customize the expiration settings of the tokens by creating [overrides](/root/kyma#configuration-helm-overrides-for-kyma-installation) to the [configuration](https://github.com/kyma-project/kyma/blob/master/resources/dex/values.yaml#L59) of the Dex component chart. +>**NOTE:** You can customize the expiration settings of the tokens by creating [overrides](/root/kyma#configuration-helm-overrides-for-kyma-installation) to the [configuration](https://github.com/kyma-project/kyma/blob/main/resources/dex/values.yaml#L59) of the Dex component chart. ## Service-to-service authentication @@ -58,4 +58,4 @@ As Kyma is build on top of Istio Service Mesh, service-to-service authentication ## User-to-service authentication -Kyma uses a custom [API Gateway](/components/api-gateway/#overview-overview) component that is build on top of [ORY Oathkeeper](https://www.ory.sh/oathkeeper/docs/). The API Gateway allows exposing user applications within the Kyma environment and secures them if necessary. You can then access the secured resources using [authentication options](/components/api-gateway/#architecture-architecture-request-flow). \ No newline at end of file +Kyma uses a custom [API Gateway](/components/api-gateway/#overview-overview) component that is build on top of [ORY Oathkeeper](https://www.ory.sh/oathkeeper/docs/). The API Gateway allows exposing user applications within the Kyma environment and secures them if necessary. You can then access the secured resources using [authentication options](/components/api-gateway/#architecture-architecture-request-flow). diff --git a/docs/security/03-02-authorization-in-kyma.md b/docs/security/03-02-authorization-in-kyma.md index dd2a8442b7fe..ae0606733224 100644 --- a/docs/security/03-02-authorization-in-kyma.md +++ b/docs/security/03-02-authorization-in-kyma.md @@ -24,20 +24,20 @@ The predefined roles are: | **kyma-edit** | None | The role for editing Kyma-specific resources. It's [aggregated](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) by other roles. | | **kyma-developer** | None | The role created for developers who build implementations using Kyma. It allows you to list and edit Kubernetes and Kyma-specific resources. You need to bind it manually to a user or a group in the Namespaces of your choice. Use the `runtimeDeveloper` group when you run Kyma with the default `cluster-users` chart configuration. | | **kyma-admin** | `runtimeAdmin` | The role with the highest permission level which gives access to all Kubernetes and Kyma resources and components with administrative rights. | -| **kyma-namespace-admin** | `runtimeNamespaceAdmin` | The role that has the same rights as the **kyma-admin** role, except for the write access to [AddonsConfigurations](https://kyma-project.io/docs/master/components/helm-broker#custom-resource-addons-configuration). The [Permission Controller](#details-permission-controller) automatically creates a RoleBinding to the `runtimeNamespaceAdmin` group in all non-system Namespaces. | +| **kyma-namespace-admin** | `runtimeNamespaceAdmin` | The role that has the same rights as the **kyma-admin** role, except for the write access to [AddonsConfigurations](https://kyma-project.io/docs/components/helm-broker#custom-resource-addons-configuration). The [Permission Controller](#details-permission-controller) automatically creates a RoleBinding to the `runtimeNamespaceAdmin` group in all non-system Namespaces. | -To learn more about the default roles and how they are constructed, see the [`rbac-roles.yaml`](https://github.com/kyma-project/kyma/blob/master/resources/cluster-users/templates/rbac-roles.yaml) file. +To learn more about the default roles and how they are constructed, see the [`rbac-roles.yaml`](https://github.com/kyma-project/kyma/blob/main/resources/cluster-users/templates/rbac-roles.yaml) file. ### Namespace-wide authorization To ensure that users can manage their Namespaces effectively and create bindings to suit their needs, a Permission Controller is deployed within the cluster. -The Permission Controller is a Kubernetes controller which listens for new Namespaces and creates RoleBindings for the users of the specified group to the **kyma-namespace-admin** role within these Namespaces. The Controller uses a blacklist mechanism, which defines the Namespaces in which the users of the defined group are not assigned the **kyma-namespace-admin** role. - +The Permission Controller is a Kubernetes controller which listens for new Namespaces and creates RoleBindings for the users of the specified group to the **kyma-namespace-admin** role within these Namespaces. The Controller uses a blocking mechanism which defines the Namespaces in which the users of the defined group are not assigned the **kyma-namespace-admin** role. + When the Controller is deployed in a cluster, it checks all existing Namespaces and assigns the roles accordingly. -By default, the controller binds users of the **runtimeNamespaceAdmin** group to the **kyma-namespace-admin** role in the Namespaces they create. Additionally, the controller creates a RoleBinding for the static `namespace.admin@kyma.cx` user to the **kyma-admin** role in every Namespace that is not blacklisted. This allows clients to manage their Namespaces and create additional bindings to suit their needs. +By default, the controller binds users of the **runtimeNamespaceAdmin** group to the **kyma-namespace-admin** role in the Namespaces they create. Additionally, the controller creates a RoleBinding for the static `namespace.admin@kyma.cx` user to the **kyma-admin** role in every Namespace that is not excluded. This allows clients to manage their Namespaces and create additional bindings to suit their needs. ->**CAUTION:** To give a user the **kyma-developer** role permissions in a Namespace, create a [RoleBinding](#role-binding) to the **kyma-developer** cluster role in that Namespace. You can define a subject of the RoleBinding by specifying either a **Group**, or a **User**. If you decide to specify a **User**, provide a user email. +>**CAUTION:** To give a user the **kyma-developer** role permissions in a Namespace, create a [RoleBinding](#role-binding) to the **kyma-developer** cluster role in that Namespace. You can define a subject of the RoleBinding by specifying either a **Group**, or a **User**. If you decide to specify a **User**, provide a user email. ### Role binding diff --git a/docs/security/03-03-accessing-kyma.md b/docs/security/03-03-accessing-kyma.md index 05beabd4fea6..519742eca107 100644 --- a/docs/security/03-03-accessing-kyma.md +++ b/docs/security/03-03-accessing-kyma.md @@ -5,11 +5,11 @@ type: Details As a user, you can access Kyma using the following: -- [Kyma Console](components/console/#overview-overview) which allows you to view, create, and manage your resources. -- [Kubernetes-native CLI (kubectl)](https://kubernetes.io/docs/reference/kubectl/overview/), which you can also use to manage your resources using a command-line interface. Kyma uses a custom [API Server Proxy component](https://github.com/kyma-project/kyma/blob/master/components/apiserver-proxy/README.md) to handle all connections between the user and the Kubernetes API server. To access and manage your resources, you need a config file which includes the JWT token required for authentication. You have two options: +- [Kyma Console](components/console/#overview-overview) which allows you to view, create, and manage your resources. +- [Kubernetes-native CLI (kubectl)](https://kubernetes.io/docs/reference/kubectl/overview/), which you can also use to manage your resources using a command-line interface. Kyma uses a custom [API Server Proxy component](https://github.com/kyma-project/kyma/blob/main/components/apiserver-proxy/README.md) to handle all connections between the user and the Kubernetes API server. To access and manage your resources, you need a config file which includes the JWT token required for authentication. You have two options: * Cluster config file you can obtain directly from your cloud provider. It allows you to directly access the Kubernetes API server, usually as the admin user. Kyma does not manage this config in any way. - * Kyma-generated config file you can download using the Kyma Console. This config uses the Kyma `api-server` proxy to access the Kubernetes API server and predefined user configuration to manage access and restrictions. + * Kyma-generated config file you can download using the Kyma Console. This config uses the Kyma `api-server` proxy to access the Kubernetes API server and predefined user configuration to manage access and restrictions. ## Console UI @@ -19,7 +19,7 @@ The diagram shows the Kyma access flow using the Console UI. >**NOTE:** The Console is permission-aware so it only shows elements to which you have access as a logged-in user. The access is RBAC-based. -1. Access the Kyma Console UI exposed by the [Istio Ingress Gateway](components/application-connector/#architecture-application-connector-components-istio-ingress-gateway) component. +1. Access the Kyma Console UI exposed by the [Istio Ingress Gateway](components/application-connector/#architecture-application-connector-components-istio-ingress-gateway) component. 2. Under the hood, the Ingress Gateway component redirects all traffic to TLS, performs TLS termination to decrypt the incoming data, and forwards you to the Kyma Console. 3. If the Kyma Console does not find a JWT token in the browser session storage, it redirects you to Dex, the Open ID Connect (OIDC) provider. Dex lists all defined identity provider connectors, so you can select one to authenticate with. 4. After successful authentication, Dex issues a JWT token for you. The token is stored in the browser session so it can be used for further interaction. @@ -31,12 +31,12 @@ To manage the connected cluster using the kubectl Command Line Interface (CLI), ![Kyma access kubectl](assets/kyma-access-kubectl.svg) -1. Use the Console UI to [request the IAM Kubeconfig Service to generate the `kubeconfig` file](#tutorials-get-the-kubeconfig-file). +1. Use the Console UI to [request the IAM Kubeconfig Service to generate the `kubeconfig` file](#tutorials-get-the-kubeconfig-file). 2. Under the hood, the Ingress Gateway performs TLS termination to decrypt the incoming data and allows the Kyma Console to proceed with the request. 3. The request goes out from the Kyma Console to the IAM Kubeconfig Service. 4. IAM Kubeconfig Service validates your in-session ID token and rewrites it into the generated `kubeconfig` file. - - >**NOTE:** The time to live (TTL) of the ID token is 8 hours, which effectively means that the TTL of the generated `kubeconfig` file is 8 hours as well. + + >**NOTE:** The time to live (TTL) of the ID token is 8 hours, which effectively means that the TTL of the generated `kubeconfig` file is 8 hours as well. The content of the file looks as follows: ```yaml diff --git a/docs/security/03-04-ingress-egress-traffic.md b/docs/security/03-04-ingress-egress-traffic.md index 0aee600a349c..f0d736d526fb 100644 --- a/docs/security/03-04-ingress-egress-traffic.md +++ b/docs/security/03-04-ingress-egress-traffic.md @@ -5,20 +5,20 @@ type: Details ## Ingress -Kyma uses the [Istio Ingress Gateway](https://istio.io/latest/docs/reference/config/networking/gateway/) to handle all incoming traffic, manage TLS termination, and handle mTLS communication between the cluster and external services. By default, the [`kyma-gateway`](https://github.com/kyma-project/kyma/blob/master/resources/core/charts/gateway/templates/gateway.yaml) configuration defines the points of entry to expose all applications using the supplied domain and certificates. -Applications are exposed using the [API Gateway](components/api-gateway/#overview-overview) controller. +Kyma uses the [Istio Ingress Gateway](https://istio.io/latest/docs/reference/config/networking/gateway/) to handle all incoming traffic, manage TLS termination, and handle mTLS communication between the cluster and external services. By default, the [`kyma-gateway`](https://github.com/kyma-project/kyma/blob/main/resources/core/charts/gateway/templates/gateway.yaml) configuration defines the points of entry to expose all applications using the supplied domain and certificates. +Applications are exposed using the [API Gateway](components/api-gateway/#overview-overview) controller. The configuration specifies the following parameters and their values: -| Parameter | Description | Value| -|-----| ---| -----| +| Parameter | Description | Value| +|-----| ---| -----| | **spec.servers.port** | The ports gateway listens on. Port `80` is automatically redirected to `443`.| `443`, `80`.| | **spec.servers.tls.minProtocolVersion** | The minimum protocol version required by the TLS connection. | `TLSV1_2` protocol version. `TLSV1_0` and `TLSV1_1` are rejected. | | **spec.servers.tls.cipherSuites** | Accepted cypher suites. | `ECDHE-RSA-CHACHA20-POLY1305`, `ECDHE-RSA-AES256-GCM-SHA384`, `ECDHE-RSA-AES256-SHA`, `ECDHE-RSA-AES128-GCM-SHA256`, `ECDHE-RSA-AES128-SHA`| ## TLS management -Kyma employs the Bring Your Own Domain/Certificates model that requires you to supply the certificate and key during installation. You can do it using the [Helm overrides for Kyma installation](/root/kyma/#configuration-helm-overrides-for-kyma-installation). See a sample ConfigMap specifying the values to override: +Kyma employs the Bring Your Own Domain/Certificates model that requires you to supply the certificate and key during installation. You can do it using the [Helm overrides for Kyma installation](/root/kyma/#configuration-helm-overrides-for-kyma-installation). See a sample ConfigMap specifying the values to override: ```yaml --- @@ -34,7 +34,7 @@ data: global.tlsCrt: "CERT" global.tlsKey: "CERT_KEY" ``` -During installation, the values are [propagated in the cluster](#certificate-propagation-paths) to all components that require them. +During installation, the values are [propagated in the cluster](#certificate-propagation-paths) to all components that require them. ### Demo setup with xip.io @@ -48,7 +48,7 @@ You can install Kyma on top of [Gardener](https://gardener.cloud/) managed insta ### API Server Proxy -The [API Server Proxy](https://github.com/kyma-project/kyma/tree/master/components/apiserver-proxy) component is a reverse proxy which acts as an intermediary for the Kubernetes API. By default, it is exposed as a LoadBalancer Service, meaning it requires a dedicated certificate and DNS entry. +The [API Server Proxy](https://github.com/kyma-project/kyma/tree/main/components/apiserver-proxy) component is a reverse proxy which acts as an intermediary for the Kubernetes API. By default, it is exposed as a LoadBalancer Service, meaning it requires a dedicated certificate and DNS entry. To learn more about about API Server Proxy configuration, see the [configuration section](/components/security/#configuration-api-server-proxy-chart). @@ -60,9 +60,9 @@ The certificate data is propagated though Kyma and delivered to several componen 1. Kyma Installer reads the override files you have configured. 2. Kyma installer passes the values to the specific Kyma components. -3. Each of these components generates Secrets, ConfigMaps, and Certificates in a certain order. +3. Each of these components generates Secrets, ConfigMaps, and Certificates in a certain order. -The table shows the order in which the configuration elements are created. +The table shows the order in which the configuration elements are created. >**NOTE:** The table does not include all possible dependencies between the components and elements that use the certificates. It serves as a reference to know where to find information about the certificates and configurations. @@ -74,12 +74,12 @@ The order differs depending on the mode: Bring Your Own Certificate | **Kind** | **Name** | **Namespace** | - | :--- | :--- | :--- | + | :--- | :--- | :--- | | Secret | ingress-tls-cert | `kyma-system` | - | ConfigMap | net-global-overrides | `kyma-installer `| + | ConfigMap | net-global-overrides | `kyma-installer `| | Secret | kyma-gateway-certs | `istio-system` | | Secret | app-connector-certs | `istio-system `| - | Secret | apiserver-proxy-tls-cert | `kyma-system` | + | Secret | apiserver-proxy-tls-cert | `kyma-system` | | ConfigMap | apiserver-proxy | `kyma-system `|
@@ -87,25 +87,25 @@ The order differs depending on the mode: Demo xip.io setup | **Kind** | **Name** | **Namespace** | - | :--- | :--- | :--- | + | :--- | :--- | :--- | | Secret | ingress-tls-cert | `kyma-system` | - | ConfigMap | net-global-overrides | `kyma-installer `| + | ConfigMap | net-global-overrides | `kyma-installer `| | Secret | kyma-gateway-certs | `istio-system` | | Secret | app-connector-certs | `istio-system `| - | Secret | apiserver-proxy-tls-cert | `kyma-system` | + | Secret | apiserver-proxy-tls-cert | `kyma-system` | | ConfigMap | apiserver-proxy | `kyma-system `|
- Gardener-managed + Gardener-managed | **Kind** | **Name** | **Namespace** | - | :--- | :--- | :--- | + | :--- | :--- | :--- | | Secret | ingress-tls-cert | `kyma-system `| - | ConfigMap | net-global-overrides | `kyma-installer `| + | ConfigMap | net-global-overrides | `kyma-installer `| | Secret | app-connector-certs | `istio-system` | | Certificate | kyma-tls-cert | `istio-system`| - | Certificate | apiserver-proxy-tls-cert | `kyma-system` | + | Certificate | apiserver-proxy-tls-cert | `kyma-system` | |ConfigMap | apiserver-proxy | `kyma-system` |
@@ -113,4 +113,4 @@ The order differs depending on the mode: ## Egress Currently no Egress limitations are implemented, meaning that all applications deployed in the Kyma cluster can access outside resources without limitations. ->**NOTE:** in the case of connection problems with external services it may be required to create an [Service Entry](https://istio.io/latest/docs/reference/config/networking/service-entry/) object to register the service. +>**NOTE:** in the case of connection problems with external services it may be required to create an [Service Entry](https://istio.io/latest/docs/reference/config/networking/service-entry/) object to register the service. diff --git a/docs/security/03-05-graphql.md b/docs/security/03-05-graphql.md index 3cf84692a257..756dafdb8fbf 100644 --- a/docs/security/03-05-graphql.md +++ b/docs/security/03-05-graphql.md @@ -22,7 +22,7 @@ The implementation assigns GraphQL actions to specific Kubernetes verbs: ## Available GraphQL actions To access cluster resources through GraphQL, an action securing given resource must be defined and implemented in the cluster. -See the [GraphQL schema](https://github.com/kyma-project/kyma/blob/master/components/console-backend-service/internal/gqlschema/schema.graphql) file for the list of actions implemented in every Kyma cluster by default. +See the [GraphQL schema](https://github.com/kyma-project/kyma/blob/main/components/console-backend-service/internal/gqlschema/schema.graphql) file for the list of actions implemented in every Kyma cluster by default. ## Secure a defined GraphQL action diff --git a/docs/security/05-07-permission-controller.md b/docs/security/05-07-permission-controller.md index d1892dd364ec..c7d591afe659 100644 --- a/docs/security/05-07-permission-controller.md +++ b/docs/security/05-07-permission-controller.md @@ -17,7 +17,7 @@ The following table lists the configurable parameters of the permission-controll | --------- | ----------- | ------------- | | `global.kymaRuntime.namespaceAdminGroup` | Determines the user group for which a RoleBinding to the **kyma-namespace-admin** role is created in all Namespaces except those specified in the `config.namespaceBlacklist` parameter. | `runtimeNamespaceAdmin` | | `config.namespaceBlacklist` | Comma-separated list of Namespaces in which a RoleBinding to the **kyma-namespace-admin** role is not created for the members of the group specified in the `global.kymaRuntime.namespaceAdminGroup` parameter.|`kyma-system, istio-system, default, kube-node-lease, kube-public, kube-system, kyma-installer, kyma-integration, natss, compass-system` | -| `config.enableStaticUser`| Determines if a RoleBinding to the **kyma-namespace-admin** role for the static `namespace.admin@kyma.cx` user is created for every Namespace that is not blacklisted. | `true` | +| `config.enableStaticUser`| Determines if a RoleBinding to the **kyma-namespace-admin** role for the static `namespace.admin@kyma.cx` user is created for every Namespace that is not blocked. | `true` | ## Customization examples You can adjust the default settings of the Permission Controller by applying these overrides to the cluster either before installation, or at runtime: @@ -39,7 +39,7 @@ data: EOF ``` -2. To change the blacklisted Namespaces and decide whether the `namespace.admin@kyma.cx` static user should be assigned the **kyma-admin** role, run: +2. To change the excluded Namespaces and decide whether the `namespace.admin@kyma.cx` static user should be assigned the **kyma-admin** role, run: ```bash cat < **NOTE:** This tutorial shows an alternative way of storing Function's code and dependencies. If you want to follow the whole end-to-end flow described for Functions in the Serverless tutorials, [create an inline Function](#tutorials-create-an-inline-function) instead. To learn more about Git repository sources for Functions and different ways of securing your repository, read about the [Git source type](#details-git-source-type). @@ -98,12 +98,12 @@ Follows these steps: type: git runtime: nodejs12 source: $GIT_FUNCTION - reference: master + reference: main baseDir: orders-service/function EOF ``` - >**NOTE:** See this [Function's code and dependencies](https://github.com/kyma-project/examples/tree/master/orders-service/function). + >**NOTE:** See this [Function's code and dependencies](https://github.com/kyma-project/examples/tree/main/orders-service/function). 5. Check if your Function was created and all conditions are set to `True`: @@ -174,7 +174,7 @@ Follows these steps: 5. Go to the **Functions** tab and select **Create Function**. -6. In the pop-up box, change `Source Type` to `From Repository`. Select the created repository's name and fill in the `Reference` field with `master` and the `Base Directory` field with `orders-service/function`. Select **Create** to confirm changes. +6. In the pop-up box, change `Source Type` to `From Repository`. Select the created repository's name and fill in the `Reference` field with `main` and the `Base Directory` field with `orders-service/function`. Select **Create** to confirm changes. The pop-up box closes and the message appears on the screen after a while, confirming that the Function was created. Make sure that the new Function has the `RUNNING` status in the list of all Functions under the **Functions** view. diff --git a/docs/serverless/08-07-sync-function-with-gitops.md b/docs/serverless/08-07-sync-function-with-gitops.md index 2674c087fb68..7332dee60249 100644 --- a/docs/serverless/08-07-sync-function-with-gitops.md +++ b/docs/serverless/08-07-sync-function-with-gitops.md @@ -41,10 +41,10 @@ These sections will lead you through the whole installation, configuration, and kubectl cluster-info ``` -3. Apply the `functions.serverless.kyma-project.io` CRD from sources in the [`kyma`](https://github.com/kyma-project/kyma/tree/master/resources/cluster-essentials/files) repository. You will need it to create the Function CR on the cluster. +3. Apply the `functions.serverless.kyma-project.io` CRD from sources in the [`kyma`](https://github.com/kyma-project/kyma/tree/main/resources/cluster-essentials/files) repository. You will need it to create the Function CR on the cluster. ```bash - kubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/master/resources/cluster-essentials/files/functions.serverless.crd.yaml + kubectl apply -f https://raw.githubusercontent.com/kyma-project/kyma/main/resources/cluster-essentials/files/functions.serverless.crd.yaml ``` 4. Run this command to make sure the CRs are applied: @@ -101,7 +101,7 @@ You can now install the Flux operator, connect it with a specific Git repository kubectl create namespace flux ``` -3. Export details of your GitHub repository - its name, the account name, and related e-mail address. You must also specify the name of the folder in your GitHub repository to which you will push the Function CR built from local sources. If you don't have this folder in your repository yet, you will create it in further steps. Flux will synchronize the cluster with the content of this folder on the `main` (`master`) branch. +3. Export details of your GitHub repository - its name, the account name, and related e-mail address. You must also specify the name of the folder in your GitHub repository to which you will push the Function CR built from local sources. If you don't have this folder in your repository yet, you will create it in further steps. Flux will synchronize the cluster with the content of this folder on the `main` branch. ```bash export GH_USER="{USERNAME}" @@ -205,7 +205,7 @@ In this section, you will create a sample inline Function. ```bash git add . # Stage changes for the commit git commit -m 'Add my-function' # Add a commit message - git push origin main # Push changes to the "main" branch of your Git repository. If you have a repository with the "master" branch, use this command instead: git push origin master + git push origin main # Push changes to the "main" branch of your Git repository. If you have a repository with the "main" branch, use this command instead: git push origin main ``` 6. Go to the GitHub repository to check that the changes were pushed. @@ -225,4 +225,4 @@ You can see that Flux synchronized the resource and the new Function CR was adde ## Reverting feature -Once you set it up, Flux will keep monitoring the given Git repository folder for any changes. If you modify the existing resources directly on the cluster, Flux will automatically revert these changes and update the given resource back to its version on the `main` (`master`) branch of the Git repository. +Once you set it up, Flux will keep monitoring the given Git repository folder for any changes. If you modify the existing resources directly on the cluster, Flux will automatically revert these changes and update the given resource back to its version on the `main` branch of the Git repository. diff --git a/docs/service-catalog/06-01-service-binding-usage.md b/docs/service-catalog/06-01-service-binding-usage.md index 1a8b871e2650..ff3c7d01688c 100644 --- a/docs/service-catalog/06-01-service-binding-usage.md +++ b/docs/service-catalog/06-01-service-binding-usage.md @@ -113,5 +113,5 @@ These components use this CR: | Component | Description | |----------|------| -| [ServiceBindingUsage Controller](https://github.com/kyma-project/kyma/tree/master/components/service-binding-usage-controller) | Reacts to every action of creating, updating, and deleting ServiceBindingUsage resources in all Namespaces and uses ServiceBindingUsage data to inject the binding. | +| [ServiceBindingUsage Controller](https://github.com/kyma-project/kyma/tree/main/components/service-binding-usage-controller) | Reacts to every action of creating, updating, and deleting ServiceBindingUsage resources in all Namespaces and uses ServiceBindingUsage data to inject the binding. | | [Console Backend Service](/components/console/#details-console-backend-service) | Exposes the given CR to the Console UI. It also allows you to create and delete a ServiceBindingUsage. | diff --git a/docs/service-catalog/06-02-usage-kind.md b/docs/service-catalog/06-02-usage-kind.md index a624703205d0..d5ef3a6693a8 100644 --- a/docs/service-catalog/06-02-usage-kind.md +++ b/docs/service-catalog/06-02-usage-kind.md @@ -61,7 +61,7 @@ These components use this CR: | Component | Description | |----------|------| -| [ServiceBindingUsage Controller](https://github.com/kyma-project/kyma/tree/master/components/service-binding-usage-controller) | Uses the UsageKind **spec.resource** and **spec.labelsPath** parameters to find a resource and path to which it should inject Secrets. | +| [ServiceBindingUsage Controller](https://github.com/kyma-project/kyma/tree/main/components/service-binding-usage-controller) | Uses the UsageKind **spec.resource** and **spec.labelsPath** parameters to find a resource and path to which it should inject Secrets. | | [Console Backend Service](/components/console/#details-console-backend-service) | Exposes the given CR to the Console UI. | ## RBAC settings diff --git a/docs/service-catalog/15-04-specifications-in-console-ui.md b/docs/service-catalog/15-04-specifications-in-console-ui.md index 7b3ecdd032dd..1eca605a02ec 100644 --- a/docs/service-catalog/15-04-specifications-in-console-ui.md +++ b/docs/service-catalog/15-04-specifications-in-console-ui.md @@ -108,7 +108,7 @@ Content is the body of your document. Write content in [Markdown](https://daring In Kyma, to make documentation more reader-friendly, some Markdown features are customized. See the following examples: -1. [Linking](https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/05-links.md) - link between documents in the same topic or in different topics using metadata. +1. [Linking](https://github.com/kyma-project/community/blob/main/guidelines/content-guidelines/05-links.md) - link between documents in the same topic or in different topics using metadata.
@@ -130,7 +130,7 @@ In Kyma, to make documentation more reader-friendly, some Markdown features are
-2. [Documentation toggles](https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/03-documentation-toggle.md) - render several versions of a given section in one document or have several versions of one document. +2. [Documentation toggles](https://github.com/kyma-project/community/blob/main/guidelines/content-guidelines/03-documentation-toggle.md) - render several versions of a given section in one document or have several versions of one document.
@@ -166,7 +166,7 @@ In Kyma, to make documentation more reader-friendly, some Markdown features are
-3. [Panels](https://github.com/kyma-project/community/blob/master/guidelines/content-guidelines/04-formatting.md#panels) - use colorful containers that call out important or additional information within a topic. +3. [Panels](https://github.com/kyma-project/community/blob/main/guidelines/content-guidelines/04-formatting.md#panels) - use colorful containers that call out important or additional information within a topic.
@@ -187,6 +187,6 @@ In Kyma, to make documentation more reader-friendly, some Markdown features are
-Read the [Content Guidelines](https://github.com/kyma-project/community/tree/master/guidelines/content-guidelines) to learn more about the customized Markdown features and other rules of writing content in Kyma. +Read the [Content Guidelines](https://github.com/kyma-project/community/tree/main/guidelines/content-guidelines) to learn more about the customized Markdown features and other rules of writing content in Kyma. >**CAUTION:** Markdown customized in a different way than in Kyma may not render properly in the Console UI. diff --git a/docs/service-mesh/10-03-connection-refused.md b/docs/service-mesh/10-03-connection-refused.md index cfd70d3532a6..0ce79f0a0138 100644 --- a/docs/service-mesh/10-03-connection-refused.md +++ b/docs/service-mesh/10-03-connection-refused.md @@ -3,10 +3,10 @@ title: Connection refused errors type: Troubleshooting --- -Mutual TLS (mTLS) is enabled in the Service Mesh by default. As a result, every element of the Service Mesh must have an Istio sidecar with a valid TLS certificate to allow communication. Attempts to establish connection between a service without a sidecar and a service with a sidecar result in a `Connection reset by peer` or a `GOAWAY` response. +Mutual TLS (mTLS) is enabled in the Service Mesh by default. As a result, every element of the Service Mesh must have an Istio sidecar with a valid TLS certificate to allow communication. Attempts to establish connection between a service without a sidecar and a service with a sidecar result in a `Connection reset by peer` or a `GOAWAY` response. - To enable sidecar injection for Pods of existing Services, restart them after upgrading Kyma. -- To whitelist a Service without a sidecar and disable mTLS traffic for it, create a [DestinationRule](https://istio.io/docs/reference/config/networking/destination-rule/). +- To allow a Service without a sidecar and disable mTLS traffic for it, create a [DestinationRule](https://istio.io/docs/reference/config/networking/destination-rule/). - To allow connections between Services without a sidecar and a Service with a sidecar, create a [Peer Authentication](https://istio.io/latest/docs/reference/config/security/peer_authentication/) in the `PERMISSIVE` mode. - >**NOTE:** In Istio 1.5, Peer Authentication replaces the deprecated [Authentication Policy](https://istio.io/v1.5/docs/reference/config/security/istio.authentication.v1alpha1/). + >**NOTE:** In Istio 1.5, Peer Authentication replaces the deprecated [Authentication Policy](https://istio.io/v1.5/docs/reference/config/security/istio.authentication.v1alpha1/). diff --git a/resources/README.md b/resources/README.md index bd8679f1e12d..aba2fd40db1d 100644 --- a/resources/README.md +++ b/resources/README.md @@ -26,9 +26,9 @@ The version of the actual component image is located under the **global.{name_of ### Add monitoring to components -Include configuration files for Service Monitors, alert rules, and dashboards under your component's chart to ensure proper health check monitoring of your component. +Include configuration files for Service Monitors, alert rules, and dashboards under your component's chart to ensure proper health check monitoring of your component. -For an example of such a component, see [Service Catalog](https://github.com/kyma-project/kyma/blob/master/resources/service-catalog/charts/catalog/templates) that contains the [ServiceMonitor](https://github.com/kyma-project/kyma/blob/master/resources/service-catalog/charts/catalog/templates/controller-manager-service-monitor.yaml) and [dashboard](https://github.com/kyma-project/kyma/blob/master/resources/service-catalog/charts/catalog/templates/dashboard-configmap.yaml) configurations. +For an example of such a component, see [Service Catalog](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog/charts/catalog/templates) that contains the [ServiceMonitor](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog/charts/catalog/templates/controller-manager-service-monitor.yaml) and [dashboard](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog/charts/catalog/templates/dashboard-configmap.yaml) configurations. When creating a ServiceMonitor resource, follow this naming convention: diff --git a/resources/helm-broker/README.md b/resources/helm-broker/README.md index bf8618f74597..a72ba3b8a042 100644 --- a/resources/helm-broker/README.md +++ b/resources/helm-broker/README.md @@ -2,6 +2,6 @@ ## Overview -Helm Broker provides bundles in the [Service Catalog](../service-catalog/README.md). A bundle is an abstraction layer over a Helm chart which enables you to provide more information about the Helm chart. For example, a bundle can provide plan definitions or binding details. Service Catalog requires this information. Bundles are services available in Service Catalog. +Helm Broker provides bundles in [Service Catalog](../service-catalog/README.md). A bundle is an abstraction layer over a Helm chart which enables you to provide more information about the Helm chart. For example, a bundle can provide plan definitions or binding details. Service Catalog requires this information. Bundles are services available in Service Catalog. -Helm Broker implements the [Service Broker API](https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md). For more information about the Service Brokers, see the [Service Brokers overview](../../docs/service-catalog/docs/13-01-service-brokers.md) documentation. Find the details about the Helm Broker in the [docs](../../docs/helm-broker/docs) repository. \ No newline at end of file +Helm Broker implements the [Service Broker API](https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md). For more information about the Service Brokers, see the [Service Brokers overview](../../docs/service-catalog/docs/13-01-service-brokers.md) documentation. Find the details about Helm Broker in the [docs](../../docs/helm-broker/docs) repository. diff --git a/resources/monitoring/README.md b/resources/monitoring/README.md index 24e05eaf1e40..587359bf072c 100644 --- a/resources/monitoring/README.md +++ b/resources/monitoring/README.md @@ -10,7 +10,7 @@ All the monitoring components run in the `kyma-system` Namespace. ## Custom Resource Definitions -Custom resource definitions for `crd-alertmanager.yaml`, `crd-podmonitor.yaml`, and `crd-servicemonitor.yaml` have been moved to the `resources/cluster-essentials/templates` folder and will be maintained there. Along with the next update of the Prometheus Operator, update the listed files in the [Cluster Essentials](https://github.com/kyma-project/kyma/tree/master/resources/cluster-essentials) chart. +Custom resource definitions for `crd-alertmanager.yaml`, `crd-podmonitor.yaml`, and `crd-servicemonitor.yaml` have been moved to the `resources/cluster-essentials/templates` folder and will be maintained there. Along with the next update of the Prometheus Operator, update the listed files in the [Cluster Essentials](https://github.com/kyma-project/kyma/tree/main/resources/cluster-essentials) chart. ## Kyma customizations diff --git a/resources/monitoring/charts/grafana/README.md b/resources/monitoring/charts/grafana/README.md index be93814c2dcf..dede549fcff3 100644 --- a/resources/monitoring/charts/grafana/README.md +++ b/resources/monitoring/charts/grafana/README.md @@ -45,7 +45,7 @@ To add a dashboard to Kyma: 5. Install Kyma locally and open it in a browser at https://console.kyma.local. 6. Access the Grafana console from Kyma by clicking **Administration > Diagnostics > Status & Metrics** in the left navigation. 7. Sign in and check if the newly added dashboard is deployed. -8. Create a pull request following the [GitHub workflow](https://github.com/kyma-project/community/blob/master/contributing/03-git-workflow.md) defined for Kyma. +8. Create a pull request following the [GitHub workflow](https://github.com/kyma-project/community/blob/main/contributing/03-git-workflow.md) defined for Kyma. ## Add a custom dashboard in Grafana diff --git a/resources/ory/charts/gcloud-sqlproxy/README.md b/resources/ory/charts/gcloud-sqlproxy/README.md index f1f73fa26573..ded6d318eb9a 100755 --- a/resources/ory/charts/gcloud-sqlproxy/README.md +++ b/resources/ory/charts/gcloud-sqlproxy/README.md @@ -1,7 +1,7 @@ # GCP SQL Proxy -[sql-proxy](https://cloud.google.com/sql/docs/postgres/sql-proxy) The Cloud SQL Proxy provides secure access to your Cloud SQL Postgres/MySQL instances without having to whitelist IP addresses or configure SSL. +[sql-proxy](https://cloud.google.com/sql/docs/postgres/sql-proxy) The Cloud SQL Proxy provides secure access to your Cloud SQL Postgres/MySQL instances without having to allow IP addresses or configure SSL. Accessing your Cloud SQL instance using the Cloud SQL Proxy offers these advantages: diff --git a/resources/ory/charts/postgresql/README.md b/resources/ory/charts/postgresql/README.md index d5a02770c98c..95d9e57ad68f 100755 --- a/resources/ory/charts/postgresql/README.md +++ b/resources/ory/charts/postgresql/README.md @@ -90,7 +90,7 @@ The following tables lists the configurable parameters of the PostgreSQL chart a | `replication.enabled` | Enable replication | `false` | | `replication.user` | Replication user | `repl_user` | | `replication.password` | Replication user password | `repl_password` | -| `replication.slaveReplicas` | Number of slaves replicas | `1` | +| `replication.slaveReplicas` | Number of subordinate replicas | `1` | | `replication.synchronousCommit` | Set synchronous commit mode. Allowed values: `on`, `remote_apply`, `remote_write`, `local` and `off` | `off` | | `replication.numSynchronousReplicas` | Number of replicas that will have synchronous replication. Note: Cannot be greater than `replication.slaveReplicas`. | `0` | | `replication.applicationName` | Cluster application name. Useful for advanced replication settings | `my_application` | @@ -121,7 +121,7 @@ The following tables lists the configurable parameters of the PostgreSQL chart a | `service.loadBalancerIP` | loadBalancerIP if service type is `LoadBalancer` | `nil` | | `service.loadBalancerSourceRanges` | Address that are allowed when svc is LoadBalancer | [] | | `schedulerName` | Name of the k8s scheduler (other than default) | `nil` | -| `shmVolume.enabled` | Enable emptyDir volume for /dev/shm for master and slave(s) Pod(s) | `true` | +| `shmVolume.enabled` | Enable emptyDir volume for /dev/shm for main and subordinate Pod(s) | `true` | | `shmVolume.chmod.enabled` | Run at init chmod 777 of the /dev/shm (ignored if `volumePermissions.enabled` is `false`) | `true` | | `persistence.enabled` | Enable persistence using PVC | `true` | | `persistence.existingClaim` | Provide an existing `PersistentVolumeClaim`, the value is evaluated as a template. | `nil` | @@ -248,7 +248,7 @@ This chart includes a `values-production.yaml` file where you can find some para + replication.enabled: true ``` -- Number of slaves replicas: +- Number of subordinate replicas: ```diff - replication.slaveReplicas: 1 + replication.slaveReplicas: 2 @@ -494,7 +494,7 @@ In this case, you should migrate the data from the old chart to the new one foll ### 4.0.0 -This chart will use by default the Bitnami PostgreSQL container starting from version `10.7.0-r68`. This version moves the initialization logic from node.js to bash. This new version of the chart requires setting the `POSTGRES_PASSWORD` in the slaves as well, in order to properly configure the `pg_hba.conf` file. Users from previous versions of the chart are advised to upgrade immediately. +This chart will use by default the Bitnami PostgreSQL container starting from version `10.7.0-r68`. This version moves the initialization logic from node.js to bash. This new version of the chart requires setting the `POSTGRES_PASSWORD` in the subordinates as well, in order to properly configure the `pg_hba.conf` file. Users from previous versions of the chart are advised to upgrade immediately. IMPORTANT: If you do not want to upgrade the chart version then make sure you use the `10.7.0-r68` version of the container. Otherwise, you will get this error @@ -504,7 +504,7 @@ The POSTGRESQL_PASSWORD environment variable is empty or not set. Set the enviro ### 3.0.0 -This releases make it possible to specify different nodeSelector, affinity and tolerations for master and slave pods. +This releases make it possible to specify different nodeSelector, affinity and tolerations for main and subordinate pods. It also fixes an issue with `postgresql.master.fullname` helper template not obeying fullnameOverride. #### Breaking changes diff --git a/resources/permission-controller/README.md b/resources/permission-controller/README.md index 250e0b4d2af6..0e023d8bdbf4 100644 --- a/resources/permission-controller/README.md +++ b/resources/permission-controller/README.md @@ -4,11 +4,11 @@ This chart bootstraps a Permission Controller deployment on a Kubernetes cluster. ## Overview -The Permission Controller listens for new Namespaces and creates a RoleBinding for the users of the specified group to the **kyma-admin** role within these Namespaces. The Controller uses a blacklist mechanism, which defines the Namespaces in which the users of the defined group are not assigned the **kyma-admin** role. When the Controller is deployed in a cluster, it checks all existing Namespaces and assigns the roles accordingly. +The Permission Controller listens for new Namespaces and creates a RoleBinding for the users of the specified group to the **kyma-admin** role within these Namespaces. The Controller uses a blocking mechanism which defines the Namespaces in which the users of the defined group are not assigned the **kyma-admin** role. When the Controller is deployed in a cluster, it checks all existing Namespaces and assigns the roles accordingly. ## Installation Being an integral part of Kyma, permission-controller is available by default in both cluster and local environments. As with the remaining Kyma components, permission-controller is installed using [Helm](https://helm.sh). ## Configuration -See [this](https://kyma-project.io/docs/master/components/security) document to learn how to configure the controller. +See [this](https://kyma-project.io/docs/components/security/) document to learn how to configure the controller. diff --git a/resources/serverless/charts/webhook/README.md b/resources/serverless/charts/webhook/README.md index 10b61469cfed..95dcb69f40c2 100644 --- a/resources/serverless/charts/webhook/README.md +++ b/resources/serverless/charts/webhook/README.md @@ -6,4 +6,4 @@ This project contains the chart for the Webhook. ## Details -Read the webhooks readme (https://github.com/kyma-project/kyma/tree/master/components/function-controller/README.md) to get all details. +Read the webhooks readme (https://github.com/kyma-project/kyma/tree/main/components/function-controller/README.md) to get all details. diff --git a/resources/service-catalog-addons/README.md b/resources/service-catalog-addons/README.md index abc37ad57954..8726863915b0 100644 --- a/resources/service-catalog-addons/README.md +++ b/resources/service-catalog-addons/README.md @@ -2,7 +2,7 @@ ## Overview -The Service Catalog Add-ons provide Kyma add-ons to the [Service Catalog](https://github.com/kyma-project/kyma/blob/master/resources/service-catalog/README.md). +The Service Catalog Add-ons provide Kyma add-ons to the [Service Catalog](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog/README.md). These add-ons consist of the following items: * Kyma Console views related to the Service Catalog @@ -27,4 +27,4 @@ The Service Binding Usage Controller chart provides two default UsageKinds to Ky * [Deployment](charts/service-binding-usage-controller/templates/deployment-usage-kind.yaml) -For more detailed information, go to the [Service Binding Usage Controller](https://github.com/kyma-project/kyma/tree/master/components/service-binding-usage-controller/docs) directory. +For more detailed information, go to the [Service Binding Usage Controller](https://github.com/kyma-project/kyma/tree/main/components/service-binding-usage-controller/docs) directory. diff --git a/resources/service-catalog-addons/charts/service-binding-usage-controller/README.md b/resources/service-catalog-addons/charts/service-binding-usage-controller/README.md index c3a49a0c12f6..66b614ae7b0d 100644 --- a/resources/service-catalog-addons/charts/service-binding-usage-controller/README.md +++ b/resources/service-catalog-addons/charts/service-binding-usage-controller/README.md @@ -6,4 +6,4 @@ The Binding Usage Controller injects **ServiceBindings** to a given application. ## Details -For more information, see the README document in the [Binding Controller](https://github.com/kyma-project/kyma/tree/master/components/service-binding-usage-controller) repository. +For more information, see the README document in the [Binding Controller](https://github.com/kyma-project/kyma/tree/main/components/service-binding-usage-controller) repository. diff --git a/tests/README.md b/tests/README.md index cd1ff41f1911..9741a465de2f 100644 --- a/tests/README.md +++ b/tests/README.md @@ -3,8 +3,8 @@ ## Overview The `tests` directory contains the sources for all Kyma tests. -A Kyma test is Pod, container, or image referenced in a Kyma module or chart test section. It provides the module's test functionality. -A Kyma test runs against a running Kyma cluster. It ensures the integrity and functional correctness of the cluster with all installed modules. +A Kyma test is Pod, container, or image referenced in a Kyma module or chart test section. It provides the module's test functionality. +A Kyma test runs against a running Kyma cluster. It ensures the integrity and functional correctness of the cluster with all installed modules. Each subdirectory in the tests directory defines sources for one test suite, usually focusing on one component. The resulting Docker images are then referenced by the related Kyma modules or charts. ## Details @@ -24,4 +24,4 @@ Bundle performance tests into one `perf` subfolder. ## Development -Follow [this](https://github.com/kyma-project/kyma/blob/master/resources/README.md) development guide when you add a new test to the `kyma` repository. +Follow [this](https://github.com/kyma-project/kyma/blob/main/resources/README.md) development guide when you add a new test to the `kyma` repository. diff --git a/tests/end-to-end/upgrade/README.md b/tests/end-to-end/upgrade/README.md index e8d4debe4a19..b2da2bd2ff1d 100644 --- a/tests/end-to-end/upgrade/README.md +++ b/tests/end-to-end/upgrade/README.md @@ -2,9 +2,9 @@ ## Overview -This project contains end-to-end upgrade tests run for the Kyma [upgrade plan](https://github.com/kyma-project/test-infra/blob/master/prow/scripts/cluster-integration/kyma-gke-upgrade.sh) on CI. The tests are written in Go. The framework allows you to define two actions: +This project contains end-to-end upgrade tests run for the Kyma [upgrade plan](https://github.com/kyma-project/test-infra/blob/main/prow/scripts/cluster-integration/kyma-gke-upgrade.sh) on CI. The tests are written in Go. The framework allows you to define two actions: -- Preparing the data +- Preparing the data - Running tests against the prepared data ## Prerequisites @@ -17,10 +17,10 @@ To set up the project, use these tools: ## Usage -Run end-to-end upgrade tests for the Kyma [upgrade plan](https://github.com/kyma-project/test-infra/blob/master/prow/scripts/cluster-integration/kyma-gke-upgrade.sh) on Prow. The continuous integration flow looks as follows: +Run end-to-end upgrade tests for the Kyma [upgrade plan](https://github.com/kyma-project/test-infra/blob/main/prow/scripts/cluster-integration/kyma-gke-upgrade.sh) on Prow. The continuous integration flow looks as follows: 1. Install Kyma from the [latest](https://github.com/kyma-project/kyma/releases/latest) release. -2. Install the upgrade-test [helm chart](chart/upgrade). +2. Install the upgrade-test [helm chart](chart/upgrade). 3. Execute all TestDefinitions with the label `kyma-project.io/test.before-upgrade`. 4. Upgrade the Kyma cluster. 5. Execute all TestDefinitions with the label `kyma-project.io/test.after-upgrade`. @@ -56,7 +56,7 @@ go run main.go --action prepareData --verbose ## Development ->**NOTE:** The following approach for adding new tests to the upgrade scenario is not needed anymore. To prepare data during the preparation phase, create a new TestDefinition that executes your preparation code and add the label `kyma-project.io/before-upgrade=true`. To execute evaluation code during the evaluation phase, create a new TestDefinition with the label `kyma-project.io/after-upgrade=true` +>**NOTE:** The following approach for adding new tests to the upgrade scenario is not needed anymore. To prepare data during the preparation phase, create a new TestDefinition that executes your preparation code and add the label `kyma-project.io/before-upgrade=true`. To execute evaluation code during the evaluation phase, create a new TestDefinition with the label `kyma-project.io/after-upgrade=true` This section presents how to add and run a new test. It also describes how to verify the code and ensure that your test is correct. diff --git a/tests/function-controller/README.md b/tests/function-controller/README.md index faa157ba29d1..305bd4037570 100644 --- a/tests/function-controller/README.md +++ b/tests/function-controller/README.md @@ -18,7 +18,7 @@ Use the following tools to set up the project: To run integration tests, follow these instructions: -1. [Install](https://kyma-project.io/docs/master/root/kyma/#installation-install-kyma-locally) Kyma. +1. [Install](https://kyma-project.io/docs/#installation-install-kyma-locally) Kyma. 2. Build the test image directly on the Docker engine of the Minikube node without pushing it to a registry. Run: ```bash @@ -74,8 +74,8 @@ Use the following environment variables to configure the application: | **APP_TEST_INGRESS_HOST** | No | `kyma.local` | The Ingress host address | | **APP_TEST_DOMAIN_PORT** | No | `80` | The port of the Service exposed by the API Rule in a given domain | | **APP_TEST_INSECURE_SKIP_VERIFY** | No | `true` | The flag that controls whether tests use verification of the server's certificate and the host name to reach the Function | -| **APP_TEST_VERBOSE** | No | `true` | The value that controls whether tests log resources that are subject to change | -| **APP_TEST_MAX_POLLING_TIME** | No | `5m` | The maximum period of time in which the Function must reconfigure after an update | +| **APP_TEST_VERBOSE** | No | `true` | The value that controls whether tests log resources that are subject to change | +| **APP_TEST_MAX_POLLING_TIME** | No | `5m` | The maximum period of time in which the Function must reconfigure after an update | Those can be supplied to [this](../../resources/serverless/templates/tests/test.yaml) file before installing Kyma. After you install Kyma, you can also edit the TestDefinition CR using this command: diff --git a/tests/perf/README.md b/tests/perf/README.md index b6a55a84d20a..e301675589b0 100644 --- a/tests/perf/README.md +++ b/tests/perf/README.md @@ -43,12 +43,12 @@ The Kyma k6 executor has a pre-defined environment variable and tags that provid These are the available environment variables: - **CLUSTER_DOMAIN_NAME** is the domain name of the target Kyma load test cluster. -- **REVISION** is the SHA ID of the tested `master` branch. +- **REVISION** is the SHA ID of the tested `main` branch. These are the pre-defined test execution tags: - **testName** is the name of a test scenario that every test should provide in the test script implementation. - **component** is the tested component or area. Provide this tag also with the test script implementation. -- **revision** is the SHA ID of the `master` branch used for tests. It is provided with the Kyma performance test runner. The test script should use the **REVISION** variable as a value. +- **revision** is the SHA ID of the `main` branch used for tests. It is provided with the Kyma performance test runner. The test script should use the **REVISION** variable as a value. The tags allow you to distinguish test results in [Grafana](https://grafana.perf.kyma-project.io/d/ReuNR5Aik/kyma-performance-test-results?orgId=1). diff --git a/tests/rafter/README.md b/tests/rafter/README.md index 6948e7f5434d..f726f579dabb 100644 --- a/tests/rafter/README.md +++ b/tests/rafter/README.md @@ -18,7 +18,7 @@ Use the following tools to set up the project: To run integration tests, follow these instructions: -1. [Install](https://kyma-project.io/docs/master/root/kyma/#installation-install-kyma-locally) Kyma. +1. [Install](https://kyma-project.io/docs/#installation-install-kyma-locally) Kyma. 2. Build the test image directly on the Docker engine of the Minikube node without pushing it to a registry. Run: ```bash diff --git a/tools/README.md b/tools/README.md index c4ae66f2cb37..34a1145cc0f3 100644 --- a/tools/README.md +++ b/tools/README.md @@ -4,4 +4,4 @@ The `tools` directory contains sources for all tools that provide supporting fun ## Development -Follow [this](https://github.com/kyma-project/kyma/blob/master/resources/README.md) development guide when you add a new tool to the `kyma` repository. +Follow [this](https://github.com/kyma-project/kyma/blob/main/resources/README.md) development guide when you add a new tool to the `kyma` repository.