Merge pull request #2402 from cncf/main

Merge `main` into `dev-fr` to enable @guillaumebernard84 as a reviewer

.github/auto-comment-config.yaml

@@ -0,0 +1,7 @@
+label_mappings:
+  - labels: 
+      - hold
+    comment: Wait, please do not proceed with this yet.
+  - labels: 
+      - lang/en
+    comment: To see where this is in the review pipeline and follow the progress, please look at the [definition review board](https://github.com/orgs/cncf/projects/26/views/1).

.github/settings.yml

@@ -171,6 +171,9 @@ collaborators:
   - username: sestegra
     permission: push
 
+  - username: guillaumebernard84
+    permission: push
+
   # l10n ur approvers
   - username: Saim-Safdar
     permission: push
@@ -434,6 +437,7 @@ branches:
          - fydrah
          - Krast76
          - sestegra
+         - guillaumebernard84
         teams: []
       enforce_admins: null
       required_linear_history: null

.github/workflows/auto-comment.yml

@@ -0,0 +1,70 @@
+name: Auto Comment on Labeled PR
+
+on:
+  pull_request_target:
+    types:
+      - labeled
+      - unlabeled
+
+permissions:
+  pull-requests: write
+
+jobs:
+  comment:
+    runs-on: ubuntu-latest
+    steps:
+    # Checkout the repository code to the runner.
+    - name: Checkout code
+      uses: actions/checkout@v3
+
+    # Create a bin directory in the runner's home
+    - name: Create bin directory
+      run: |
+        mkdir -p $HOME/bin
+        echo "$HOME/bin" >> $GITHUB_PATH
+
+    # Install the latest jq and yq from GitHub releases
+    - name: Install jq and yq
+      run: |
+        wget https://github.com/jqlang/jq/releases/latest/download/jq-linux-amd64 -O $HOME/bin/jq
+        chmod +x $HOME/bin/jq
+        wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O $HOME/bin/yq
+        chmod +x $HOME/bin/yq      
+        
+    # Main logic for adding comments based on labels.
+    - name: Comment on PR based on external config
+      run: |
+        # Fetch the labels attached to the PR from the GitHub event JSON.
+        pr_labels=$(jq -r '.pull_request.labels[] | .name' "$GITHUB_EVENT_PATH" | tr '\n' ' ')
+        
+        # Define the path to the external YAML config file.
+        config_file=".github/auto-comment-config.yaml"
+        
+        # Get the number of label-comment mappings defined in the config file.
+        num_mappings=$(yq e '.label_mappings | length' "$config_file")
+        
+        # Loop through each label-comment mapping in the config file.
+        for (( i=0; i<$num_mappings; i++ )); do
+          # Fetch the labels and comment for the current mapping.
+          mapfile -t labels < <(yq e ".label_mappings[$i].labels[]" "$config_file")
+          comment=$(yq e ".label_mappings[$i].comment" "$config_file")
+
+          # Check if all required labels from the current mapping are present in the PR.
+          for label in "${labels[@]}"; do
+            if [[ ! $pr_labels == *"$label"* ]]; then
+              echo "One or more required labels not found. Skipping."
+              continue 2  # Skip to the next iteration of the outer loop.
+            fi
+          done
+          
+          # Fetch the PR number from the GitHub event JSON.
+          pr_number=$(jq -r '.pull_request.number' "$GITHUB_EVENT_PATH")
+          
+          # If all required labels are found, add the comment to the PR.
+          echo "All required labels found. Adding comment."
+          gh pr comment "$pr_number" --body "$comment"
+
+        done
+      env:
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      shell: bash

.github/workflows/check-outdated-content.yaml

@@ -46,16 +46,16 @@ jobs:
         # Set L10n directory
         case "${L10N_BRANCH}" in
           dev-pt)
-          L10N_DIR="./content/pt-br/"
+          L10N_DIR="content/pt-br/"
           ;;
           dev-zh)
-          L10N_DIR="./content/zh-cn/"
+          L10N_DIR="content/zh-cn/"
           ;;
           dev-tw)
-          L10N_DIR="./content/zh-tw/"
+          L10N_DIR="content/zh-tw/"
           ;;
           *)
-          L10N_DIR="./content/${L10N_CODE}/"
+          L10N_DIR="content/${L10N_CODE}/"
           ;;
         esac
         echo "(DEBUG) L10N Directory: ${L10N_DIR}"
@@ -133,16 +133,16 @@ jobs:
             echo "(DEBUG) FILE_DIR: ${FILE_DIR}"
             echo "(DEBUG) FILE_NAME: ${FILE_NAME}"
             echo "(DEBUG) Localized file path: $L10N_FILE_PATH"
-            echo "(DEBUG) Original file path: ./content/en/${FILE_PATH}"
+            echo "(DEBUG) Original file path: content/en/${FILE_PATH}"
 
             # Create subdirectories
             mkdir -p ${OUTPUT_DIR}/${FILE_DIR}
             
             # Actually compare between the old and lastest English content and log diff in the file
-            if [[ -f "./content/en/${FILE_PATH}" ]]; then
+            if [[ -f "content/en/${FILE_PATH}" ]]; then
               # File exists
               # Check changes
-              git diff ${OLD_BRANCH}..${LATEST_BRANCH} -- ./content/en/${FILE_PATH} > temp.diff
+              git diff ${OLD_BRANCH}..${LATEST_BRANCH} -- content/en/${FILE_PATH} > temp.diff
 
               if [[ -s "temp.diff" ]]; then
                 echo "(DEBUG) ${FILE_PATH} is outdated."

CODEOWNERS

@@ -35,8 +35,8 @@
 /i18n/es.toml @raelga @ramrodo @electrocucaracha @krol3 @92nqb
 
 # Approvers for French contents
-/content/fr/ @huats @fydrah @Krast76 @sestegra
-/i18n/fr.toml @huats @fydrah @Krast76 @sestegra
+/content/fr/ @huats @fydrah @Krast76 @sestegra @guillaumebernard84
+/i18n/fr.toml @huats @fydrah @Krast76 @sestegra @guillaumebernard84
 
 # Approvers for Hindi contents
 /content/hi/ @Garima-Negi @sayantani11 @anubha-v-ardhan @jayesh-srivastava

content/es/.wordlist.txt

@@ -180,6 +180,7 @@ md
 menu
 Mercurial
 mesh
+meshes
 methodology
 microservicio
 microservicios

content/es/auto-scaling.md

@@ -5,7 +5,7 @@ category: Propiedad
 tags: ["infrastructure", "", ""]
 ---
 
-El autoescalado es la habilidad de un sistema para [escalar](/scalability) automáticamente, en términos de recursos computacionales.
+El autoescalado es la habilidad de un sistema para [escalar](/es/scalability) automáticamente, en términos de recursos computacionales.
 Con un sistema de autoescalado, los recursos son agregados automáticamente cuando se necesitan y pueden escalar para cumplir con la demanda fluctuante de los usuarios.
 El proceso de autoescalado varía y es configurable para escalar basado en diferentes métricas, como son la memoria o el uso de CPU.
 Los servicios gestionados en la nube son los que están asociados típicamente con esta funcionalidad de autoescalado
@@ -15,7 +15,7 @@ Anteriormente, la infraestructura y las aplicaciones eran diseñadas para consid
 Esta arquitectura implicaba que había más recursos que eran desaprovechados o con cambios rígidos frente a la demanda de los usuarios.
 La rigidez en este caso, incrementa el coste y puede suponer una pérdida de negocios debido a problemas de capacidad.
 
-Aprovechando la nube, la [virtualización](/virtualization) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias,
+Aprovechando la nube, la [virtualización](/es/virtualization) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias,
 las organizaciones pueden construir aplicaciones que escalan de manera acorde a la demanda de los usuarios.
 Se pueden monitorear la demanda de las aplicaciones y de manera automática escalar las mismas, proporcionando una experiencia al usuario final óptima.
 Tomemos el ejemplo del aumento de la audiencia de Netflix todos los viernes por la noche.

content/es/bare-metal-machine.md

@@ -11,7 +11,7 @@ Bare metal se refiere a una computadora física, más específicamente un servid
 La distinción es importante en la informática moderna porque muchos, si no es que la mayoría, de los servidores son [máquinas virtuales](/es/virtual-machine/).
 Un servidor físico suele ser una computadora bastante grande con un potente hardware incorporado.
 La instalación de un sistema operativo y la ejecución de aplicaciones directamente en ese hardware físico,
-sin [virtualización](/virtualization/), se conoce como ejecución "bare metal".
+sin [virtualización](/es/virtualization/), se conoce como ejecución "bare metal".
 
 ## Problema que aborda
 
@@ -29,6 +29,6 @@ bare metal puede ser la solución adecuada.
 En el contexto de las [aplicaciones nativas para la nube](/es/cloud-native-apps/),
 generalmente pensamos en el rendimiento en términos de [escalabilidad](/es/scalability/) para una gran cantidad de eventos simultáneos,
 que pueden mitigarse mediante el [escalado horizontal](/es/horizontal-scaling/) (agregando más máquinas a su grupo de recursos).
-Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/vertical-scaling/) (agregar más potencia a una máquina física existente)
+Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/es/vertical-scaling/) (agregar más potencia a una máquina física existente)
 y/o una respuesta extremadamente rápida de hardware físico, en cuyo caso se adapta mejor el bare metal.
 Bare metal también le permite ajustar el hardware físico y posiblemente incluso los controladores de hardware para ayudarlo a realizar su tarea.

content/es/cloud-computing.md

@@ -23,5 +23,5 @@ La computación en la nube permite a las organizaciones subcontratar una parte d
 
 Los proveedores de la nube ofrecen a las organizaciones la capacidad de alquilar recursos informáticos bajo demanda y pagar por el uso.
 Esto permite dos innovaciones principales:
-las organizaciones pueden probar cosas sin perder tiempo planificando y gastando dinero o recursos en nueva infraestructura física y pueden [escalar](/scalability/) según sea necesario y bajo demanda.
+las organizaciones pueden probar cosas sin perder tiempo planificando y gastando dinero o recursos en nueva infraestructura física y pueden [escalar](/es/scalability/) según sea necesario y bajo demanda.
 La computación en la nube permite a las organizaciones adoptar tanta o tan poca infraestructura como necesiten.

content/es/cloud-native-apps.md

@@ -9,15 +9,15 @@ tags: ["application", "fundamental", ""]
 
 Las aplicaciones nativas para la nube están diseñadas específicamente para aprovechar las innovaciones en [computación en la nube](/es/cloud_computing/).
 Estas aplicaciones se integran fácilmente con sus respectivas arquitecturas en la nube,
-aprovechando los recursos de la nube y las capacidades de [escalado](/scalability/).
+aprovechando los recursos de la nube y las capacidades de [escalado](/es/scalability/).
 También se refiere a las aplicaciones que aprovechan las innovaciones en infraestructura impulsadas por la computación en la nube.
 Las aplicaciones nativas para la nube de hoy en día incluyen aplicaciones que se ejecutan en el centro de datos de un proveedor de la nube y en plataformas nativas de la nube on-premises.
 
 ## Problema que aborda
 
 Tradicionalmente, los entornos on-premises proporcionaban recursos informáticos de una manera bastante personalizada.
-Cada centro de datos tenía servicios que [acoplaban estrechamente](/tightly-coupled-architectures/) aplicaciones a entornos específicos,
-a menudo dependiendo en gran medida del aprovisionamiento manual de infraestructura, como [máquinas virtuales](/virtual_machine/) y servicios.
+Cada centro de datos tenía servicios que [acoplaban estrechamente](/es/tightly-coupled-architectures/) aplicaciones a entornos específicos,
+a menudo dependiendo en gran medida del aprovisionamiento manual de infraestructura, como [máquinas virtuales](/es/virtual-machine/) y servicios.
 Esto, a su vez, restringió a los desarrolladores y sus aplicaciones a ese centro de datos en específico.
 Las aplicaciones que no fueron diseñadas para la nube no pudieron aprovechar las capacidades de resiliencia y escalabilidad de un entorno de nube.
 Por ejemplo, las aplicaciones que requieren una intervención manual para iniciarse correctamente no pueden escalarse automáticamente,

content/es/container-image.md

@@ -21,10 +21,10 @@ Cualquier configuración errónea entre los entornos es problemática, a menudo
 Un entorno de aplicación tiene que ser fácil de replicar, además de estar bien definido;
 en caso contrario, la posibilidad de bugs y errores relacionados con el entorno aumenta.
 Cuando los entornos de aplicación no están configurados de manera adecuada o son inexactos,
-el escalado [horizontal](/es/horizontal-scaling/) y [vertical](/vertical-scaling/) de las aplicaciones se complica y reduce su efectividad.
+el escalado [horizontal](/es/horizontal-scaling/) y [vertical](/es/vertical-scaling/) de las aplicaciones se complica y reduce su efectividad.
 
 ## ¿Cómo ayuda?
 
 Las imágenes empaquetan una aplicación con todas las dependencias necesarias para ejecutarse, como el servidor de aplicación.
 Esto otorga consistencia en todos los entornos, incluyendo los dispositivos locales de desarrollo.
-Una imagen puede dar lugar a cualquier número de contenedores, según sea necesario, permitiendo una mayor [escalabilidad](/scalability/).
+Una imagen puede dar lugar a cualquier número de contenedores, según sea necesario, permitiendo una mayor [escalabilidad](/es/scalability/).

content/es/continuous-delivery.md

@@ -34,4 +34,4 @@ Por lo general, el desarrollo basado en troncos (trunk-based development) se usa
 ## Términos relacionados
 
 * [Integración Continua](/es/continuous-integration/)
-* [Despliegue Continuo](/continuous_deployment/)
+* [Despliegue Continuo](/es/continuous-deployment/)

content/es/devops.md

@@ -13,7 +13,7 @@ DevOps requiere grupos de ingenieros que trabajen en componentes pequeños (en l
 
 ## Problema que aborda
 
-Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/es/monolithic-apps/) con arquitecturas [estrechamente acopladas](/tightly-coupled-architectures/),
+Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/es/monolithic-apps/) con arquitecturas [estrechamente acopladas](/es/tightly-coupled-architectures/),
 el trabajo generalmente se distribuía entre varios equipos.
 Esta fragmentación del desarrollo dio lugar a numerosos traspasos y largos plazos de entrega.
 Cada vez que un componente o alguna actualización estaba lista, se colocaba en una cola para el siguiente equipo.

content/es/horizontal-scaling.md

@@ -8,7 +8,7 @@ tags: ["infrastructure", "", ""]
 ## ¿Qué es?
 
 Escalado horizontal es una técnica donde la capacidad del sistema es incrementada agregando más [nodos](/es/nodes)
-en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/vertical-scaling/)).
+en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/es/vertical-scaling/)).
 Como ejemplo, digamos que tenemos un sistema con 4 GB de memoria y queremos incrementar su capacidad a 16 GB,
 escalar horizontalmente significa agregar 4 x 4 GB en vez de cambiar a un sistema de 16 GB.
 
@@ -20,7 +20,7 @@ en vez de expandir la capacidad de cada uno individualmente.
 ## Problema que aborda
 
 Cuando la demanda a una aplicación crece más allá de la capacidad de la misma y de su instancia,
-necesitamos encontrar una manera de [escalar](/scale) (agregar capacidad) al sistema.
+necesitamos encontrar una manera de [escalar](/es/scalability/) (agregar capacidad) al sistema.
 Podemos hacerlo agregando más nodos al sistema (escalado horizontal)
 o más recursos computacionales a los nodos existentes (escalado vertical).
 

content/es/hypervisor.md

@@ -7,10 +7,10 @@ tags: ["application", "", ""]
 
 ## ¿Qué es?
 
-Un hipervisor utiliza el concepto de [virtualización](/virtualization/)
+Un hipervisor utiliza el concepto de [virtualización](/es/virtualization/)
 aprovechando los recursos de la llamada [máquina bare metal](/es/bare-metal-machine/)
 (CPU, memoria, recursos de red, y almacenamiento), dividiéndolos en partes más pequeñas,
-y ubicando recursos suficientes para crear [máquinas virtuales](/virtual-machine/)
+y ubicando recursos suficientes para crear [máquinas virtuales](/es/virtual-machine/)
 hasta que el servidor base alcanza su límite de funcionamiento.
 
 ## Problema que aborda

content/es/immutable-infrastructure.md

@@ -6,7 +6,7 @@ tags: ["infrastructure", "property", ""]
 ---
 
 Infraestructura inmutable se refiere a la infraestructura informática
-([máquinas virtuales](/virtual-machine/), [contenedores](/es/container/), dispositivos de red)
+([máquinas virtuales](/es/virtual-machine/), [contenedores](/es/container/), dispositivos de red)
 que no se puede cambiar una vez implementada.
 Esto se puede hacer cumplir mediante un proceso automatizado que sobreescriba los cambios no autorizados o
 a través de un sistema que no permita cambios en primer lugar.

content/es/infrastructure-as-a-service.md

@@ -8,7 +8,7 @@ tags: ["infrastructure", "", ""]
 ## ¿Qué es?
 
 Infraestructura como Servicio, o IaaS, es un modelo de servicio de [computación en la nube](/es/cloud_computing/) que
-ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/virtualization/)
+ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/es/virtualization/)
 suministrados bajo demanda en un modelo de pago por uso.
 Los proveedores de la nube poseen y operan el hardware y el software,
 a disposición de los consumidores en despliegues de nube pública, privada o híbrida.

content/es/infrastructure-as-code.md

@@ -14,13 +14,13 @@ por lo general usando scripts con la consola u otras herramientas de configuraci
 ## Problema que aborda
 
 Construir aplicaciones de forma nativa para la nube requiere que la infraestructura sea desechable y reproducible.
-Además requiere [escalar](/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana.
+Además requiere [escalar](/es/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana.
 El aprovisionamiento manual no puede cumplir los requerimientos de respuesta y escalado de las [aplicaciones nativas para la nube](/es/cloud-native-apps/).
 Los cambios manuales no son reproducibles, rápidamente se enfrentan a limites de escalabilidad, e introducen errores de configuración.
 
 ## ¿Cómo ayuda?
 
-Representados los recursos del [centro de datos](/data-center/) tales como servidores, balanceadores de carga y sub-redes como código,
+Representados los recursos del [centro de datos](/es/data-center/) tales como servidores, balanceadores de carga y sub-redes como código,
 les permite a los equipos de infraestructura poseer una fuente única de verdad para todas las configuraciones y
-también les permite administrar sus [centro de datos](/data-center/) en flujos de [CI](/es/continuous-integration/)/[CD](/es/continuous-delivery/)
+también les permite administrar sus [centro de datos](/es/data-center/) en flujos de [CI](/es/continuous-integration/)/[CD](/es/continuous-delivery/)
 implementando un sistema de control de versiones y estrategias de despliegue.

content/es/kubernetes.md

@@ -23,7 +23,7 @@ La demanda de recursos de cómputo incrementa día con día y las organizaciones
 ## ¿Cómo ayuda?
 
 De manera parecida a las herramientas tradicionales de [infraestructura como código](/es/infrastructure-as-code/), Kubernetes ayuda con la automatización pero tiene la ventaja de trabajar con contenedores.
-Los contenedores son más resistentes a fallas por diferencias en entornos a comparación con las [máquinas virtuales](/virtual-machine/) o físicas.
+Los contenedores son más resistentes a fallas por diferencias en entornos a comparación con las [máquinas virtuales](/es/virtual-machine/) o físicas.
 
 Aún más, Kubernetes funciona declarativamente, lo que significa que, en lugar de que los operadores proporcionen las instrucciones sobre cómo realizar una acción, ellos describen, por lo general en archivos de manifiesto (por ejemplo, YAML), lo que quieren que se logre;
 Kubernetes se encargará del "cómo" por sí mismo.

content/es/loosely-coupled-architecture.md

@@ -7,7 +7,7 @@ tags: ["fundamental", "architecture", "property"]
 
 
 La arquitectura débilmente acoplada es un tipo de arquitectura en donde los componentes individuales de una aplicación se construyen de manera independiente unos de los otros 
-(es el paradigma opuesto a la [arquitectura fuertemente acoplada](/tightly-coupled-architectures/)). 
+(es el paradigma opuesto a la [arquitectura fuertemente acoplada](/es/tightly-coupled-architectures/)). 
 Cada componente, a veces denominado [microservicio](/es/microservices/), 
 está diseñado para realizar una función específica de manera que pueda ser utilizado por cualquier número de servicios. 
 Este patrón es generalmente más lento de implementar que la arquitectura estrechamente acoplada,