Merge pull request #1 from cncf/main

Merging CNCF/main to the local dev-tu

.github/settings.yml

@@ -168,9 +168,6 @@ collaborators:
   - username: huats
     permission: push
 
-  - username: fydrah
-    permission: push
-
   - username: Krast76
     permission: push
 
@@ -180,6 +177,9 @@ collaborators:
   - username: guillaumebernard84
     permission: push
 
+  - username: seb-835
+    permission: push
+
   # l10n ur approvers
   - username: Saim-Safdar
     permission: push
@@ -220,7 +220,7 @@ collaborators:
   - username: aliok
     permission: push
 
-  - username: halil-bugol
+  - username: symys
     permission: push
 
   - username: rwxdash
@@ -448,10 +448,10 @@ branches:
         # fr approvers
         users:
          - huats
-         - fydrah
          - Krast76
          - sestegra
          - guillaumebernard84
+         - seb-835
         teams: []
       enforce_admins: null
       required_linear_history: null
@@ -524,7 +524,7 @@ branches:
         # tr approvers
         users:
          - aliok
-         - halil-bugol
+         - symys
          - rwxdash
          - eminalemdar
         teams: []

.github/workflows/check-links.yml

@@ -0,0 +1,18 @@
+name: Links
+
+on:
+  pull_request:
+
+jobs:
+  build-and-check-links:
+    name: CHECK LINKS
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: .nvmrc
+          cache: npm
+          cache-dependency-path: package.json
+      - run: npm install --omit=optional
+      - run: npm run check:links

.github/workflows/es-spellcheck.yml

@@ -29,6 +29,6 @@ jobs:
           set -o errexit
           diff content/es/.wordlist.txt <(LC_ALL= sort -f content/es/.wordlist.txt)
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.36.0
+        uses: rojopolis/spellcheck-github-actions@0.38.0
         with:
           config_path: content/es/.spellcheck.yml

.github/workflows/post-outdated-content-report.yaml

@@ -50,7 +50,7 @@ jobs:
 #     - name: Download output
 #       uses: actions/download-artifact@v3
     - name: Download output
-      uses: dawidd6/action-download-artifact@v3
+      uses: dawidd6/action-download-artifact@v6
       with:
         github_token: ${{secrets.GITHUB_TOKEN}}
         workflow: check-outdated-content.yaml

.github/workflows/spellcheck.yml

@@ -25,4 +25,4 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: GitHub Spellcheck Action
-        uses: rojopolis/spellcheck-github-actions@0.36.0
+        uses: rojopolis/spellcheck-github-actions@0.38.0

.gitignore

@@ -1,10 +1,12 @@
 
-public/
-resources/
-node_modules/
-.hugo_build.lock
 .DS_Store
+.hugo_build.lock
+/public
+/resources
+node_modules/
+package-lock.json
 pagefind
+tmp/
 
 # Local Netlify folder
 .netlify

.htmltest.yml

@@ -0,0 +1,8 @@
+# cSpell:ignore pagefind regexs
+DirectoryPath: public
+# IgnoreDirectoryMissingTrailingSlash: true # FIXME
+IgnoreInternalEmptyHash: true # FIXME
+IgnoreDirs:
+  - ^(bn|de|es|fr|hi|it|ko|pt.*?|ru|tr|ur|zh.*?)/
+IgnoreURLs: # list of regexs of paths or URLs to be ignored
+  - ^/pagefind

.nvmrc

@@ -0,0 +1 @@
+lts/*

CODEOWNERS

@@ -35,8 +35,8 @@
 /i18n/es.toml @raelga @ramrodo @electrocucaracha @krol3 @92nqb
 
 # Approvers for French contents
-/content/fr/ @huats @fydrah @Krast76 @sestegra @guillaumebernard84
-/i18n/fr.toml @huats @fydrah @Krast76 @sestegra @guillaumebernard84
+/content/fr/ @huats @Krast76 @sestegra @guillaumebernard84 @seb-835
+/i18n/fr.toml @huats @Krast76 @sestegra @guillaumebernard84 @seb-835
 
 # Approvers for Hindi contents
 /content/hi/ @Garima-Negi @jayesh-srivastava @abhay-raj19 @aj11anuj @kumarankit999 @bishal7679
@@ -63,8 +63,8 @@
 /i18n/ru.toml @shurup @kirkonru @tym83
 
 # Approvers for Turkish contents
-/content/tr/ @aliok @halil-bugol @rwxdash @eminalemdar
-/i18n/tr.toml @aliok @halil-bugol @rwxdash @eminalemdar
+/content/tr/ @aliok @symys @rwxdash @eminalemdar
+/i18n/tr.toml @aliok @symys @rwxdash @eminalemdar
 
 # Approvers for Urdu contents
 /content/ur/ @Saim-Safdar @waleed318

Makefile

@@ -1,5 +1,27 @@
+HTMLTEST_DIR=tmp
+HTMLTEST?=htmltest # Specify as make arg if different
+HTMLTEST_ARGS?=--skip-external
+
+# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy
+ifeq (, $(shell which $(HTMLTEST)))
+override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest
+ifeq (, $(shell which $(HTMLTEST)))
+GET_LINK_CHECKER_IF_NEEDED=get-link-checker
+endif
+endif
+
+check-links: $(GET_LINK_CHECKER_IF_NEEDED)
+	$(HTMLTEST) $(HTMLTEST_ARGS)
+
+clean:
+	rm -rf $(HTMLTEST_DIR) public/* resources
+
+get-link-checker:
+	rm -Rf $(HTMLTEST_DIR)/bin
+	curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin
+
 serve:
-	hugo server \
+	npx hugo server \
 		--disableFastRender \
 		--buildDrafts \
 		--buildFuture \
@@ -13,16 +35,15 @@ serve:
 		--gc
 
 production-build:
-	git submodule update --init --recursive
-	hugo \
-		--minify
+	npm run get:submodule
+	npx hugo --minify
 	npx -y pagefind --site public
 
 preview-build:
 	git submodule update --init --recursive
-	hugo \
+	npx hugo \
 		--baseURL $(DEPLOY_PRIME_URL) \
 		--buildDrafts \
 		--buildFuture \
 		--minify
-	npx -y pagefind --site public
+	npx -y pagefind --site public

README.md

@@ -13,19 +13,19 @@ If you'd like to help with the glossary we'd love to have your contributions! Pl
 ## Acknowledgements
 
 The Cloud Native Glossary was initiated by the CNCF Marketing Committee
-(Business Value Subcommittee) and includes contributions from 
-[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), 
-[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), 
-[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), 
-[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), 
-[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), 
-[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), 
-and many more contributors. 
+(Business Value Subcommittee) and includes contributions from
+[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/),
+[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
+[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk),
+[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/),
+[Katelin Ramer](https://www.linkedin.com/in/katelinramer/),
+[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca),
+and many more contributors.
 For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors).
 
-The Glossary is maintained by 
+The Glossary is maintained by
 [Seokho Son](https://www.linkedin.com/in/seokho-son/),
-[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), 
+[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/),
 [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/),
 [Nate W.](https://www.linkedin.com/in/nate-double-u/),
 and [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/).
@@ -43,10 +43,8 @@ All code contributions are under the Apache 2.0 license. Documentation is distri
 
 To improve the Cloud Native Glossary site itself, install a local copy with these instructions. Note you must have [npm](https://www.npmjs.com/) and [Hugo](https://gohugo.io/) installed.
 
-```
+```sh
 git clone https://github.com/cncf/glossary.git
-cd glossary
-git submodule update --init --recursive
 npm install
 ```
 

content/en/cloud-native-apps.md

@@ -14,7 +14,7 @@ Cloud native applications today include apps that run in a cloud provider’s da
 ## Problem it addresses
 
 Traditionally, on-premise environments provided compute resources in a fairly bespoke way. 
-Each datacenter had services that [tightly coupled](/tightly-coupled-architectures/) applications to specific environments, 
+Each datacenter had services that [tightly coupled](/tightly-coupled-architecture/) applications to specific environments, 
 often relying heavily on manual provisioning for infrastructure, like [virtual machines](/virtual-machine/) and services. 
 This, in turn, constrained developers and their applications to that specific datacenter. 
 Applications that weren't designed for the cloud couldn't take advantage of a cloud environment’s resiliency and scaling capabilities. 

content/en/container-orchestration.md

@@ -4,19 +4,19 @@ status: Completed
 category: Concept
 ---
 
-[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments. 
-It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring. 
+[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments.
+It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring.
 Orchestration is a metaphor:
-The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. 
+The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should.
 
-## Problem it addresses 
+## Problem it addresses
 
-Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually.
-Container orchestration allows users to automate all these management tasks. 
+Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually.
+Container orchestration allows users to automate all these management tasks.
 
 ## How it helps
 
-Container orchestration tools allow users to determine a system's state. 
+Container orchestration tools allow users to determine a system's state.
 First, they declare how it should look like (e.g., x containers, y pods, etc.).
-The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). 
+The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes).
 This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities.

content/en/containerization.md

@@ -5,10 +5,7 @@ category: Technology
 tags: ["application", "", ""]
 ---
 
-Containerization is the process of bundling an application and its dependencies into a container image. 
-The container build process requires adherence to the [Open Container Initiative](https://opencontainers.org) (OCI) standard. 
-As long as the output is a container image that adheres to this standard, which containerization tool is used doesn't matter.
-
+Containerization is the process of packaging of application code including libraries and dependencies required to run the code into a single lightweight executable—called [container image](/container-image/). 
 ## Problem it addresses 
 
 Before [containers](/container/) became prevalent, organizations relied on [virtual machines](/virtual-machine/) (VMs) to 

content/en/devops.md

@@ -11,7 +11,7 @@ DevOps calls for groups of engineers that work on small components (versus an en
 
 ## Problem it addresses
 
-Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architectures/) [monolithic apps](/monolithic-apps/), 
+Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architecture/) [monolithic apps](/monolithic-apps/), 
 work was generally fragmented between multiple groups. 
 This led to numerous handoffs and long lead times. 
 Each time a component or update was ready, it was placed in a queue for the next team. 

content/en/loosely-coupled-architecture.md

@@ -5,15 +5,15 @@ category: Property
 tags: ["fundamental", "architecture", "property"]
 ---
 
-Loosely coupled architecture is an architectural style 
-where the individual components of an application are built independently from one another 
-(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). 
-Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function 
-in a way that can be used by any number of other services. 
-This pattern is generally slower to implement than tightly coupled architecture 
+Loosely coupled architecture is an architectural style
+where the individual components of an application are built independently from one another
+(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)).
+Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function
+in a way that can be used by any number of other services.
+This pattern is generally slower to implement than tightly coupled architecture
 but has a number of benefits, particularly as applications scale.
 
-Loosely coupled applications allow teams to develop features, deploy, and scale independently, 
-which allows organizations to iterate quickly on individual components. 
-Application development is faster and teams can be structured around their competency, 
-focusing on their specific application. 
+Loosely coupled applications allow teams to develop features, deploy, and scale independently,
+which allows organizations to iterate quickly on individual components.
+Application development is faster and teams can be structured around their competency,
+focusing on their specific application.

content/en/microservices-architecture.md

@@ -5,31 +5,31 @@ tags: ["architecture", "fundamental", ""]
 ---
 
 A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality.
-These services work together closely, appearing to the end user as a single entity. 
-Take Netflix as an example. 
-Its interface allows you to access, search, and preview videos. 
+These services work together closely, appearing to the end user as a single entity.
+Take Netflix as an example.
+Its interface allows you to access, search, and preview videos.
 These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser.
 
 This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below).
 
 ## Problem it addresses
 
-Applications are made up of different parts, each responsible for a specific capability. 
-Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. 
-Going back to our Netflix example. 
-Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.  
-The surge in signups demands more signup capacity. 
-Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. 
+Applications are made up of different parts, each responsible for a specific capability.
+Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts.
+Going back to our Netflix example.
+Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.
+The surge in signups demands more signup capacity.
+Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources.
 
-Monolithic architectures also make it easy for developers to succumb to design pitfalls. 
-Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns. 
-Monoliths also often require developers to understand the entire codebase before deploying any changes. 
-Microservices architecture is a response to these challenges.  
+Monolithic architectures also make it easy for developers to succumb to design pitfalls.
+Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns.
+Monoliths also often require developers to understand the entire codebase before deploying any changes.
+Microservices architecture is a response to these challenges.
 
 
 ## How it helps
 
-Separating functionality into different microservices makes them easier to deploy, update, and scale independently. 
-It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. 
-While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. 
+Separating functionality into different microservices makes them easier to deploy, update, and scale independently.
+It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app.
+While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude.
 Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage.

content/en/security-chaos-engineering.md

@@ -29,5 +29,5 @@ Engineering teams will progressively improve the understanding for security conc
 within complex infrastructure, platforms, and distributed systems. 
 SCE improves the cyber resiliency of the entire product, uncovers hidden security issues, 
 exposes the classical blind spots, and prepares teams for critical edge cases. 
-This approach helps SREs, [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers 
+This approach helps [SREs](/site-reliability-engineering/), [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers 
 create confidence in the system, increase cyber resiliency and improve observability.

content/en/stateful-apps.md

@@ -5,12 +5,12 @@ category: Property
 tags: ["fundamental", "application", "property"]
 ---
 
-When we speak of stateful (and [stateless](/stateless-apps/)) apps, 
-state refers to any data the app needs to store to function as designed. 
-Any kind of online shop that remembers your cart is a stateful app for example. 
+When we speak of stateful (and [stateless](/stateless-apps/)) apps,
+state refers to any data the app needs to store to function as designed.
+Any kind of online shop that remembers your cart is a stateful app for example.
 
-Today, most applications we use are at least partly stateful. In cloud native environments though, 
-stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. 
+Today, most applications we use are at least partly stateful. In cloud native environments though,
+stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic.
 They can be scaled up and down, restarted, and moved around but still need to be able to access their state.
 
 Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases.