diff --git a/README.md b/README.md index 4cb983abe..95f63f811 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ If you are looking for information on how to join us, you are in the right place ## Contribution rules -Before you start contributing, read our [Code of Conduct](docs/contributing/01-code-of-conduct.md) and learn about our [working model](docs/governance/01-governance.md) to understand the way Kyma community works. Get familiar with the [contributing rules](docs/contributing/02-contributing.md), recommended [Git workflow](docs/contributing/03-git-workflow.md), [Prow workflow](docs/contributing/04-prow-workflow.md), and [issues workflow](docs/governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor. +Before you start contributing, read our [Code of Conduct](docs/contributing/01-code-of-conduct.md) and learn about our [working model](docs/governance/01-governance.md) to understand the way Kyma community works. Get familiar with the [contributing rules](docs/contributing/02-contributing.md), recommended [Git workflow](docs/contributing/03-git-workflow.md), and [issues workflow](docs/governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor. ## Guidelines diff --git a/concepts/installer-migration-hooks/README.md b/concepts/installer-migration-hooks/README.md index 2de468dd0..c6b682f0c 100644 --- a/concepts/installer-migration-hooks/README.md +++ b/concepts/installer-migration-hooks/README.md @@ -233,7 +233,7 @@ hydroform - To have a consistent output, we will use the Unified Logging library. The logs should be sent back to the caller (aka CLI). ## Results after implementing Draft-PoC -The pre-described PoC was implemented on [this branch](https://github.com/JeremyHarisch/hydroform/tree/jobManager), and tested using [this](https://github.com/kyma-project/kyma/pull/11132) as an [example pre-job](https://github.com/JeremyHarisch/hydroform/blob/jobManager/parallel-install/pkg/jobmanager/sampleJob.go) for the `logging` component. +The pre-described PoC was implemented on [this branch](https://github.com/JeremyHarisch/hydroform/tree/jobManager), and tested using [this](https://github.com/kyma-project/kyma/pull/11132) as an example pre-job for the `logging` component. In the draft implementation, the Unified Logging Library was not used, but can be used in the final implementation. In general, it works in the way we want to, but with some tradeoffs. The mechanism was tested using a local k3d cluster, as well as on an Azure cluster provisioned by Gardener. diff --git a/concepts/observability-strategy/configurable-logging/03-fluent-bit-operator1.md b/concepts/observability-strategy/configurable-logging/03-fluent-bit-operator1.md index 488166bba..7ad0e59c8 100644 --- a/concepts/observability-strategy/configurable-logging/03-fluent-bit-operator1.md +++ b/concepts/observability-strategy/configurable-logging/03-fluent-bit-operator1.md @@ -123,7 +123,7 @@ kubectl get secret --namespace logging grafana -o jsonpath="{.data.admin-passwor ```bash kubectl -n logging port-forward svc/grafana 3000:80 ``` - + 4. Open the Grafana Dashboard: http://localhost:3000 and log in. Select Menu > Explore, select Data source > Loki, then select Log labels > namespace > logging. A list of logs should appear. # Feature comparison matrix diff --git a/docs/README.md b/docs/README.md index 3495519fc..8e85ab055 100644 --- a/docs/README.md +++ b/docs/README.md @@ -10,7 +10,7 @@ If you are looking for information on how to join us, you are in the right place ## Contribution rules -Before you start contributing, read our [Code of Conduct](./contributing/01-code-of-conduct.md) and learn about our [working model](./governance/01-governance.md) to understand the way the Kyma community works. Get familiar with the [contributing rules](./contributing/02-contributing.md), recommended [Git workflow](./contributing/03-git-workflow.md), [Prow workflow](./contributing/04-prow-workflow.md), and [issues workflow](./governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor. +Before you start contributing, read our [Code of Conduct](./contributing/01-code-of-conduct.md) and learn about our [working model](./governance/01-governance.md) to understand the way the Kyma community works. Get familiar with the [contributing rules](./contributing/02-contributing.md), recommended [Git workflow](./contributing/03-git-workflow.md), and [issues workflow](./governance/03-issues-workflow.md) we use in Kyma so you can apply them later in practice as an active contributor. ## Guidelines diff --git a/docs/governance/01-governance.md b/docs/governance/01-governance.md index 52f569146..12375f45f 100644 --- a/docs/governance/01-governance.md +++ b/docs/governance/01-governance.md @@ -66,7 +66,7 @@ should request a change of their status to emeritus. ### How to suggest a change in a maintainers list? -To suggest a change in the ownership of a given repository part, create a PR with the required changes in the `CODEOWNERS` file in the project's repository. The required number of codeowners needs to approve the PR for the changes to take place. Read the [CODEOWNERS file template](https://github.com/kyma-project/community/blob/main/templates/repository-template/CODEOWNERS) to learn how to set up and modify owners of the given repository folders and files. +To suggest a change in the ownership of a given repository part, create a PR with the required changes in the `CODEOWNERS` file in the project's repository. The required number of codeowners needs to approve the PR for the changes to take place. Read the [CODEOWNERS file template](https://github.com/kyma-project/template-repository/blob/main/CODEOWNERS) to learn how to set up and modify owners of the given repository folders and files. The name of the removed maintainer is added to the [emeritus](https://github.com/kyma-project/community/blob/main/emeritus.md) file with a short message about what areas the person worked on. diff --git a/docs/governance/03-issues-workflow.md b/docs/governance/03-issues-workflow.md index a19e5e2f2..b5fe71a00 100644 --- a/docs/governance/03-issues-workflow.md +++ b/docs/governance/03-issues-workflow.md @@ -70,7 +70,7 @@ When the work is done, the issue is closed. ### Stale issues -To keep the Kyma backlog clean, the bot monitors all repositories in the organization. It marks old, inactive issues with the `stale` (Hex: #E4E669) label and closes them after a given period of time. For configuration details, check the [sample file](https://github.com/kyma-project/kyma/blob/main/.github/stale.yml). +To keep the Kyma backlog clean, the bot monitors all repositories in the organization. It marks old, inactive issues with the `stale` (Hex: #E4E669) label and closes them after a given period of time. Although the bot helps us to keep the backlog clean, we regularly monitor its activities to make sure it is not closing issues that are still valid and important for Kyma. The Kyma team reviews the issues in the [Kyma backlog](https://github.com/kyma-project/kyma/issues) and acts on the issues as follows: - Closed issues: diff --git a/docs/guidelines/content-guidelines/06-links.md b/docs/guidelines/content-guidelines/06-links.md index f47ae0ead..11a92a100 100644 --- a/docs/guidelines/content-guidelines/06-links.md +++ b/docs/guidelines/content-guidelines/06-links.md @@ -28,8 +28,4 @@ To add a reference to a YAML, JSON, SVG, PNG, or JPG file located in the `assets ## Links in documentation toggles -To link to a document in a documentation toggle, the toggle must start with the `
` tag and end with the `
` tag, where **name** is a distinctive ID used for linking. For more information, read a separate [Tabs & toggles](./05-tabs.md) document. - -## Links to the archived documentation - -Use absolute links to link to the [archived version of the website](https://kyma-project-old.netlify.app/docs/root/kyma). Only the 1.24 and 1.23 versions are available. To link to the older versions, use respective tag in [GitHub sources](https://github.com/kyma-project/kyma/tree/main/docs). +To link to a document in a documentation toggle, the toggle must start with the `
` tag and end with the `
` tag, where **name** is a distinctive ID used for linking. For more information, read a separate [Tabs & toggles](./05-tabs-toggles.md) document. diff --git a/docs/guidelines/content-guidelines/10-docs-preview.md b/docs/guidelines/content-guidelines/10-docs-preview.md index f1aa3ca26..78643810a 100644 --- a/docs/guidelines/content-guidelines/10-docs-preview.md +++ b/docs/guidelines/content-guidelines/10-docs-preview.md @@ -15,6 +15,7 @@ To install docsify-cli, run `npm i docsify-cli -g`. To preview content on the Kyma website, save your changes and run the local server. 1. Run `docsify serve docs` in the `/kyma` repository. + 2. Preview `https://kyma-project.io` in your browser on http://localhost:3000. ## Preview module documentation @@ -38,4 +39,5 @@ To preview content on the Kyma website, save your changes and run the local serv 3. Save your changes. 4. Run `docsify serve docs`. + 5. Preview `https://kyma-project.io` in your browser on http://localhost:3000. diff --git a/docs/guidelines/releases-guidelines/01-release-strategy.md b/docs/guidelines/releases-guidelines/01-release-strategy.md index 6cb29a8ce..f5535a4a6 100644 --- a/docs/guidelines/releases-guidelines/01-release-strategy.md +++ b/docs/guidelines/releases-guidelines/01-release-strategy.md @@ -126,7 +126,7 @@ After reaching the end of the development cycle, the Kyma developers create a re - two working days for minor releases - one week for major releases -All release candidates must always be fully tested by all defined automated and manual tests, following the [test strategy](../technical-guidelines/07-test-strategy.md). Manual tests are tracked in [this sheet](https://docs.google.com/spreadsheets/d/1ty3OciQzgzv0GagTG2Dku9os2AfMupbGNf8QxjHaO88/edit) for each release candidate. +All release candidates must always be fully tested by all defined automated and manual tests, following the [test strategy](../technical-guidelines/07-test-strategy.md). During the release process, only [critical issues](#critical-issues) will be considered for cherry-picking. The Release Manager approves the final release to be prepared and published only when all tests have passed, and no critical issues are blocking the release. diff --git a/docs/guidelines/releases-guidelines/02-kyma-release-process.md b/docs/guidelines/releases-guidelines/02-kyma-release-process.md index aef846d60..6dc944fad 100644 --- a/docs/guidelines/releases-guidelines/02-kyma-release-process.md +++ b/docs/guidelines/releases-guidelines/02-kyma-release-process.md @@ -93,15 +93,16 @@ Follow these steps to release another Kyma version. Execute these steps for ever 1. Once the preparation for the release is finished, trigger the [Release Kyma](https://github.com/kyma-project/kyma/actions/workflows/github-release.yaml) GitHub action. Choose the branch that corresponds to the release that you want to trigger. The exact release version is taken from the `VERSION` file. - When you click the **Run workflow** button, the release process waits for the approval from reviewers. - The reviewers list is defined in the ["release" Github Environment](https://github.com/kyma-project/kyma/settings/environments). + When you click the **Run workflow** button, the release process waits for the approval from reviewers. + + The reviewers list is defined in the ["release" Github Environment](https://github.com/kyma-project/kyma/settings/environments). After it is approved, the following will happen: * GitHub release is triggered. * Documentation update on the official Kyma website is triggered. * New release cluster is created for the given Kyma `RELEASE_VERSION`. If you don't have access to the GCP project, post a request in the Slack team channel. > **CAUTION**: The cluster is automatically generated for you, and it is automatically removed after 7 days. - + 2. The Github release post-submit job creates a release in the `kyma-project/kyma` repository, which triggers the [`post-rel{RELEASE_VERSION_SHORT}-kyma-release-upgrade`](https://github.com/kyma-project/test-infra/blob/main/prow/jobs/kyma/kyma-release-upgrade.yaml) pipeline. The purpose of this job is to test upgradability between the latest Kyma release that is not a release candidate and the brand new release published by the release post-submit job. For example, if `1.7.0-rc2` is released, the pipeline will try to upgrade `1.6.0` to `1.7.0-rc2`. diff --git a/docs/guidelines/releases-guidelines/03-kyma-cli-release-process.md b/docs/guidelines/releases-guidelines/03-kyma-cli-release-process.md index 9bf37981a..2736e85ce 100644 --- a/docs/guidelines/releases-guidelines/03-kyma-cli-release-process.md +++ b/docs/guidelines/releases-guidelines/03-kyma-cli-release-process.md @@ -64,7 +64,7 @@ A Kyma CLI release consists of: If it's not due to bugs, simply close your PR and re-run the previous `brew bump-formula-pr` command with `--force` mode. - If you got the message `fatal: a branch named 'bump-kyma-cli-{RELEASE_VERSION}' already exists`, delete this local branch. - If you got the message `Error: You need to bump this formula manually since the new URL and old URL are both: https://github.com/kyma-project/cli/archive/{RELEASE_VERSION}.tar.gz`, restore the change in you local repo. The local repo is under `/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core`(Intel) or `/opt/homebrew/Library/Taps/homebrew/homebrew-core`(Apple Silicon). - - Alternatively, create a PR to the [kyma-cli Homebrew formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/kyma-cli.rb). + - Alternatively, create a PR to the [kyma-cli Homebrew formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/k/kyma-cli.rb). When a Homebrew maintainer approves your PR, the formula is updated. diff --git a/docs/guidelines/releases-guidelines/07-release-subscription.md b/docs/guidelines/releases-guidelines/07-release-subscription.md index 6311b9db3..da36cee54 100644 --- a/docs/guidelines/releases-guidelines/07-release-subscription.md +++ b/docs/guidelines/releases-guidelines/07-release-subscription.md @@ -5,4 +5,4 @@ label: internal GitHub offers an option to subscribe to email notifications on new releases in repositories. To learn how to watch the given repository only for the releases, read the [GitHub article](https://help.github.com/articles/watching-and-unwatching-releases-for-a-repository/). -Alternatively, use free online tools, such as [CodeRelease.io](https://coderelease.io/), [GitPunch](https://gitpunch.com/), or [releases](https://releases.netlify.com/), to get e-mail notifications when the GitHub projects release a new version in the GitHub repositories that you watched and starred. +Alternatively, use free online tools, such as [GitPunch](https://gitpunch.com/), or [releases](https://releases.netlify.com/), to get e-mail notifications when the GitHub projects release a new version in the GitHub repositories that you watched and starred. diff --git a/docs/guidelines/repository-guidelines/01-new-repository-settings.md b/docs/guidelines/repository-guidelines/01-new-repository-settings.md index c5c9eb4ba..7acb0b580 100644 --- a/docs/guidelines/repository-guidelines/01-new-repository-settings.md +++ b/docs/guidelines/repository-guidelines/01-new-repository-settings.md @@ -35,11 +35,11 @@ To see these settings, go to **Branches** in the left menu, under repository **S ![Branch protection rules](./assets/branch-protection-rules.png) -In Kyma, the protection rules are defined in the Prow [`config.yaml`](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml) file generated from rules defined in the [`prow-config.yaml`](https://github.com/kyma-project/test-infra/blob/main/templates/templates/prow-config.yaml) file and handled by a Prow component called [Branch Protector](https://github.com/kyma-project/test-infra/blob/main/docs/prow/prow-architecture.md#branch-protector). +In Kyma, the protection rules are defined in the Prow [`config.yaml`](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml) file handled by a Prow component called [Branch Protector](https://github.com/kyma-project/test-infra/blob/main/docs/prow/prow-architecture.md#branch-protector). If you add a new repository in: - `kyma-project`, you do not need to add a new entry to the Prow `config.yaml` file as the branch protection is already defined for [all repositories](https://github.com/kyma-project/test-infra/blob/main/prow/config.yaml#L380) within this organization. The only exception is if you want to specify additional rules that are not handled by Prow. -- `kyma-incubator`, add a new repository entry to the Prow `config.yaml` file, under **branch-protection.orgs.kyma-incubator.repos**. See [an example](https://github.com/kyma-project/test-infra/blob/main/templates/templates/prow-config.yaml) of such an entry for the `marketplaces` repository. +- `kyma-incubator`, add a new repository entry to the Prow `config.yaml` file, under **branch-protection.orgs.kyma-incubator.repos**. ## Update CLA assistant configuration @@ -47,10 +47,6 @@ Ask a [kyma-project owner](https://github.com/orgs/kyma-project/people) to: - Add the newly created repository to the [Contributor License Agreement](https://cla-assistant.io/) (CLA). - Add the `kyma-bot` username to be exempt from signing the CLA. -## Add a milv file - -If you define any governance-related [Prow job](https://github.com/kyma-project/test-infra/blob/main/prow/jobs/) for the new repository to validate documentation links, you must add a `milv.config.yaml` file at the root of the repository. [See](https://github.com/kyma-project/test-infra/blob/main/milv.config.yaml) an example of the milv file. - ## Custom settings Track all repository changes that deviate from configuration standard described in the guidelines with an [issue](https://github.tools.sap/kyma/test-infra/issues/new?assignees=&labels=config-change&template=bug_report.md&title=). diff --git a/sigs-and-wgs/archive/sig-core/decisions/README.md b/sigs-and-wgs/archive/sig-core/decisions/README.md index 4b9599d3f..11a8ec3af 100644 --- a/sigs-and-wgs/archive/sig-core/decisions/README.md +++ b/sigs-and-wgs/archive/sig-core/decisions/README.md @@ -4,4 +4,4 @@ This directory contains records of decisions made by the Core SIG and the Kyma project members before end of May 2019. -Currently, decisions are made based on issues or pull requests that have the decision flag assigned. The decision-making process is described [here](https://github.com/kyma-project/community/blob/main/governance.md). +Currently, decisions are made based on issues or pull requests that have the decision flag assigned. The decision-making process is described [here](https://github.com/kyma-project/community/blob/main/docs/governance/01-governance.md#decision-making). diff --git a/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md b/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md index 05d35927a..555c05e33 100644 --- a/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md +++ b/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md @@ -43,4 +43,4 @@ Although some of the Kyma team's pull requests were rejected, the team contribut After some discussion, the team managed to introduce [this](https://github.com/coreos/dex/issues/1087) change. Finally, Dex is designed to work with Kubernetes and is also one of the authentication solutions -recommended in the [Kubernetes documentation](https://kubernetes.io/docs/admin/authentication/#configuring-the-api-server). +recommended in the [Kubernetes documentation](https://kubernetes.io/docs). diff --git a/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md b/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md index 03552cb6c..89ef83c15 100644 --- a/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md +++ b/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md @@ -19,7 +19,7 @@ Istio Ingress can then expose GraphQL and developers can define appropriate auth In the current release (0.7.x), **Istio RBAC engine** is implemented as a Mixer adapter. The **Request Context** sent to the **Istio RBAC engine** is provided as an instance of the **Authorization Template**. Information defined in the **Authorization Template** is fetched from [Istio Attributes](https://istio.io/docs/concepts/policy-and-control/attributes.html). -A given Istio deployment has a [fixed vocabulary of attributes that it understands](https://istio.io/docs/reference/config/mixer/attribute-vocabulary.html). +A given Istio deployment has a [fixed vocabulary of attributes that it understands](https://istio.io/v1.0/docs/concepts/policies-and-telemetry/#attribute-vocabulary). A set of **Service Roles** defines the authorization for a service in Istio. A **Service Role** specification includes a list of **Access Rules**. diff --git a/sigs-and-wgs/archive/sig-core/decisions/dr-021-Remove-k8s-api-server-proxies.md b/sigs-and-wgs/archive/sig-core/decisions/dr-021-Remove-k8s-api-server-proxies.md index 356787dff..781ba2527 100644 --- a/sigs-and-wgs/archive/sig-core/decisions/dr-021-Remove-k8s-api-server-proxies.md +++ b/sigs-and-wgs/archive/sig-core/decisions/dr-021-Remove-k8s-api-server-proxies.md @@ -10,7 +10,7 @@ Created on 2021-07-12 by Piotr Bochyński (@pbochynski). | Due date | 2021-07-19 | | Status | Proposed on 2021-07-12, Accepted on 2021-08-04| | Decision type | Binary | -| Affected decisions | [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md), [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-015-Authorization_for_GraphQL.md), [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) | +| Affected decisions | [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md), [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md), [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) | ## Context @@ -42,6 +42,6 @@ The benefits: - faster development and easier maintenance of the Console UI. As a result of this decision, the following decisions are invalid: -- [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md) -- [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-015-Authorization_for_GraphQL.md) -- [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) +- [DR 007: GraphQL as API facade for UI](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-007-GraphQL_as_API_facade_for_UI.md) +- [DR 015: Authorization for GraphQL](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-015-Authorization_for_GraphQL.md) +- [DR 008: DEX as an OIDC authenticator](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/decisions/dr-008-Dex_as_an_OIDC_authenticator.md) diff --git a/sigs-and-wgs/archive/sig-core/proposals/asset-store-proposal.md b/sigs-and-wgs/archive/sig-core/proposals/asset-store-proposal.md index b161dad87..d642380b3 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/asset-store-proposal.md +++ b/sigs-and-wgs/archive/sig-core/proposals/asset-store-proposal.md @@ -123,7 +123,7 @@ spec: ``` The optional information is: -- A ConfigMap reference that points to the ConfigMap that introduces [a new file](https://github.com/kyma-project/kyma/blob/main/resources/service-catalog-addons/charts/instances-ui/templates/configmap.yaml) which is also sent to the bucket along with other files. +- A ConfigMap reference that points to the ConfigMap that introduces a new file which is also sent to the bucket along with other files. - An Asset validation webhook reference to a service that performs the validation of fetched assets before they are uploaded to the bucket. It can be a list of several different validation webhooks and all of them should be processed even if one is failing. The use cases are: - Validation of a specific file against some specification. - Security validation @@ -265,6 +265,6 @@ The Asset Store comes with one out-of-the-box mutating service that enables an e ## Minio local vs cluster modes -Minio as a storage service supports Kyma's manifesto and the "batteries included" rule. It makes the development process easier. Apart from the production usage, Minio should be used in a [Gateway mode](https://github.com/minio/minio/tree/master/docs/gateway). The Gateway mode gives you the flexibility to use asset storage from any major cloud provider, such as Google, Amazon, and Microsoft. It does not require modifications in the Asset Controller as it talks to the Minio/Minio Gateway with the same S3 API. +Minio as a storage service supports Kyma's manifesto and the "batteries included" rule. It makes the development process easier. Apart from the production usage, Minio should be used in a Gateway mode. The Gateway mode gives you the flexibility to use asset storage from any major cloud provider, such as Google, Amazon, and Microsoft. It does not require modifications in the Asset Controller as it talks to the Minio/Minio Gateway with the same S3 API. ![](assets/gateway.svg) diff --git a/sigs-and-wgs/archive/sig-core/proposals/image-name-consolidation.md b/sigs-and-wgs/archive/sig-core/proposals/image-name-consolidation.md index c8f452cc1..38ca28899 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/image-name-consolidation.md +++ b/sigs-and-wgs/archive/sig-core/proposals/image-name-consolidation.md @@ -29,7 +29,7 @@ component-name > The `cmd` directory is not always required, but it is good practice to use it. If a component's source code can be used to create only a single binary, it is also ok to put its `main` function in a file called `main.go` on the root-level of the `components` folder. -Tests are stored in the `test` folder following [this](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/proposals/test-folder-consolidation.md) proposal. +Tests are stored in the `test` folder following [this](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/proposals/test-folder-consolidation.md) proposal. ## Proposal @@ -79,7 +79,7 @@ See the following examples: ### Components Currently, all images follow the proposed pattern and exclusions. -The following table assumes all tests will be renamed according to the naming convention proposed [here](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/sig-core/proposals/test-folder-consolidation.md) +The following table assumes all tests will be renamed according to the naming convention proposed [here](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/proposals/test-folder-consolidation.md). ### Tests | Path | Old image name | New image name | diff --git a/sigs-and-wgs/archive/sig-core/proposals/knative-eventing-default-pubsub.md b/sigs-and-wgs/archive/sig-core/proposals/knative-eventing-default-pubsub.md index ceeda4ce7..4ac25866e 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/knative-eventing-default-pubsub.md +++ b/sigs-and-wgs/archive/sig-core/proposals/knative-eventing-default-pubsub.md @@ -35,7 +35,7 @@ The OOTB Kyma installation will have NATS Streaming set as the default messaging * The operator deploys the cluster channel provisioner and injects the secrets. -* Use [Knative semantics](https://github.com/knative/docs/blob/master/docs/eventing/channels/default-channels.md#setting-the-default-channel-configuration) to specify the default ClusterChannelProvisioner. +* Use Knative semantics to specify the default ClusterChannelProvisioner. ```yaml apiVersion: v1 @@ -74,7 +74,7 @@ data: **Yes, default can be changed**. -* The existing channels/subscriptions still stay the same with the previous PubSub. [Same approach](https://github.com/knative/docs/blob/master/docs/eventing/channels/default-channels.md) as followed by Knative. +* The existing channels/subscriptions still stay the same with the previous PubSub. Same approach as followed by Knative. ## How to support the operator diff --git a/sigs-and-wgs/archive/sig-core/proposals/modularization.md b/sigs-and-wgs/archive/sig-core/proposals/modularization.md index 563969dce..9a954f3c2 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/modularization.md +++ b/sigs-and-wgs/archive/sig-core/proposals/modularization.md @@ -53,7 +53,7 @@ The proposed solution is to provide a flexible and modular installation of fine - Dynamic UI (micro frontends) + back-end - adding new components extends views and also the backed functionalities, such as the supported GraphQL queries. - No custom logic in the installation process (shell scripts) - it should be replaced by the operator pattern. - The minimal set of mandatory components that form the real Kyma "core". The dependency for the core can be mandatory, other dependencies should be optional. -- Kyma core as Gardener add-on. For reference, see [Knative with Gardener](https://github.com/knative/docs/blob/master/docs/install/Knative-with-Gardener.md) and [Gardener Bouquet](https://github.com/gardener/bouquet) documentation. +- Kyma core as Gardener add-on. For reference, see [Knative with Gardener](https://github.com/knative/docs/blob/main/docs/install/knative-offerings.md) and [Gardener Bouquet](https://github.com/gardener/bouquet) documentation. - Split Kyma core chart into more fine grained components, and provide a tooling to install all of them in the same convenient way as before (convention). - Kyma add-ons, brokers, and showcases as Kyma bundles. For reference, see the [Kyma bundles](#kyma-bundles-for-the-service-catalog). - Check dependency tree of components. Flag components as mandatory or optional. diff --git a/sigs-and-wgs/archive/sig-core/proposals/new-architecture-docs.md b/sigs-and-wgs/archive/sig-core/proposals/new-architecture-docs.md index 3e38ad697..df96245c7 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/new-architecture-docs.md +++ b/sigs-and-wgs/archive/sig-core/proposals/new-architecture-docs.md @@ -22,7 +22,7 @@ Proposed on 2018-10-16. ## Solution -Implement the below proposal on top of the new [Asset Store](https://github.com/kyma-project/community/blob/main/sig-and-wg/sig-core/proposals/asset-store-proposal.md). +Implement the below proposal on top of the new [Asset Store](https://github.com/kyma-project/community/blob/main/sigs-and-wgs/archive/sig-core/proposals/asset-store-proposal.md). ![](assets/main-arch.svg) diff --git a/sigs-and-wgs/archive/sig-core/proposals/update-code-and-chart-in-one-pr.md b/sigs-and-wgs/archive/sig-core/proposals/update-code-and-chart-in-one-pr.md index e472a6969..c6b0af31a 100644 --- a/sigs-and-wgs/archive/sig-core/proposals/update-code-and-chart-in-one-pr.md +++ b/sigs-and-wgs/archive/sig-core/proposals/update-code-and-chart-in-one-pr.md @@ -55,7 +55,7 @@ Let's assume that you work on an issue that requires changes in the `helm-broker 3. Create a pull request to test the introduced changes (let's assume that the pull request has number `1234`). As only the `helm-broker` code was modified, the `pre-main-kyma-component-helm-broker` job is executed. All the other jobs are skipped. If the job is successful, the component's image is published under `eu.grc.io/kyma-project/pr/helm-broker:PR-1234`. -4. Test your changes locally on Minikube. In order to use the newly created image, edit [this](https://github.com/kyma-project/kyma/blob/main/resources/helm-broker/values.yaml) `values.yaml` file: +4. Test your changes locally on Minikube. In order to use the newly created image, edit the Helm Broker `values.yaml` file: ``` global: diff --git a/sigs-and-wgs/archive/wg-installation/CLOSURE.md b/sigs-and-wgs/archive/wg-installation/CLOSURE.md index 1f4e21d5f..2559a565f 100644 --- a/sigs-and-wgs/archive/wg-installation/CLOSURE.md +++ b/sigs-and-wgs/archive/wg-installation/CLOSURE.md @@ -8,4 +8,4 @@ The group achieved its goal. Several improvements and design changes were discus - Better handling of Custom Resource Definitions (CRDs) — not managed by Helm - Default local setup based on k3s (much faster than Minikube) -The decisions are now in the implementation phase, but some of the ideas are already applied and bring visible benefits. The best example is the new [integration pipeline](https://status.build.kyma-project.io/job-history/kyma-prow-logs/logs/kyma-integration-k3s) that installs Kyma and executes integration tests in about 7 minutes. +The decisions are now in the implementation phase, but some of the ideas are already applied and bring visible benefits. The best example is the new integration pipeline that installs Kyma and executes integration tests in about 7 minutes. diff --git a/sigs-and-wgs/archive/wg-installation/README.md b/sigs-and-wgs/archive/wg-installation/README.md index e321b11e3..fbd7cd07a 100644 --- a/sigs-and-wgs/archive/wg-installation/README.md +++ b/sigs-and-wgs/archive/wg-installation/README.md @@ -23,7 +23,7 @@ The purpose of this working group is to: ## Meetings -* [Tuesday at 16:00 CEST](https://calendar.google.com/calendar/ical/3abtp9lh0mn3iiov5772jftccc%40group.calendar.google.com/public/basic.ics) +* Tuesday at 16:00 CEST * [Slack](https://kyma-community.slack.com/messages/CD2HJ0E78) * Frequency: weekly * [Meeting notes and agenda](https://docs.google.com/document/d/19lM_wDLXRV-8rQQ7ZxFtasr6kgGRCwUm0kJaAK3NNik) diff --git a/sigs-and-wgs/archive/wg-prow/README.md b/sigs-and-wgs/archive/wg-prow/README.md index b6c8e3ac7..10eeed30f 100644 --- a/sigs-and-wgs/archive/wg-prow/README.md +++ b/sigs-and-wgs/archive/wg-prow/README.md @@ -14,7 +14,7 @@ The purpose of this group is to: Regular WG Meeting: Friday at 13:00 CEST, weekly. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=13:00&tz=CEST%20%28Central%20European%20Summer%20Time%29). * [Zoom](https://zoom.us/j/4794339038) -* [Meeting notes and agenda](https://docs.google.com/document/d/1ljEAoCBJXlxx_ATPyvKZ1KoyFOSIBzEAOkN-2H-HhUY) +* Meeting notes and agenda * [Meeting recordings](https://www.youtube.com/playlist?list=PL7PGl--iaIH9SXFdB4DrraqI7oEer7S3Q) diff --git a/sigs-and-wgs/archive/wg-showcase-application/README.md b/sigs-and-wgs/archive/wg-showcase-application/README.md index 83e530053..4b94f8d02 100644 --- a/sigs-and-wgs/archive/wg-showcase-application/README.md +++ b/sigs-and-wgs/archive/wg-showcase-application/README.md @@ -22,7 +22,7 @@ The purpose of this Working Group (WG) is to build a Unified Demo Project with a ## Meetings -* [Thursday at 16:00 CEST](https://calendar.google.com/calendar/ical/3abtp9lh0mn3iiov5772jftccc%40group.calendar.google.com/public/basic.ics) +* Thursday at 16:00 CEST * [Slack](https://kyma-community.slack.com/archives/C01C40T8CKD) * Frequency: weekly * [Meeting notes and agenda](https://docs.google.com/document/d/1XO7_lWlcJiJLA7ZX_vQv9_0jyIrWNafWdJRwgQwC_y4/edit) diff --git a/templates/resources/sig-wg-readme-template.md b/templates/resources/sig-wg-readme-template.md index e49bb8d81..09230ec34 100644 --- a/templates/resources/sig-wg-readme-template.md +++ b/templates/resources/sig-wg-readme-template.md @@ -1,4 +1,5 @@ -> **NOTE:** Copy this template to your groups's folder and rename it to `README.md`. + +**NOTE:** Copy this template to your groups's folder and rename it to `README.md`. # {SIG Name} Special Interest Group | {WG Name} Working Group @@ -39,3 +40,4 @@ The purpose of this group is to: ## Reference Read the main [`README.md`](../README.md) document to learn about the structure of Kyma SIGs and WGs. + \ No newline at end of file