Charlie is now Chihiro.

Signed-off-by: [email protected]

Author: kflynn

site-src/concepts/api-overview.md

@@ -7,7 +7,7 @@ This document provides an overview of Gateway API.
 There are 3 primary roles in Gateway API, as described in [roles and personas]:
 
 - **Ian** (he/him): Infrastructure Provider
-- **Charlie** (they/them): Cluster Operator
+- **Chihiro** (they/them): Cluster Operator
 - **Ana** (she/her): Application Developer
 
 [roles and personas]:/concepts/roles-and-personas
@@ -176,7 +176,7 @@ different relationships that Gateways and Routes can have:
 
 ### Example
 
-[Charlie] has deployed a Gateway `shared-gw` in the `infra` Namespace to be
+[Chihiro] has deployed a Gateway `shared-gw` in the `infra` Namespace to be
 used by different application teams for exposing their applications outside
 the cluster. Teams A and B (in Namespaces `A` and `B` respectively) attach
 their Routes to this Gateway. They are unaware of each other and as long as
@@ -190,7 +190,7 @@ Namespace.
 <!-- source: https://docs.google.com/presentation/d/1neBkFDTZ__vRoDXIWvAcxk2Pb7-evdBT6ykw_frf9QQ/edit?usp=sharing -->
 ![route binding](/images/gateway-route-binding.png)
 
-[Charlie]:/concepts/roles-and-personas#charlie
+[Chihiro]:/concepts/roles-and-personas#Chihiro
 
 ### How it Works
 

site-src/concepts/roles-and-personas.md

@@ -37,9 +37,9 @@ The Gateway API defines three roles and personas:
   will often work for a cloud provider (AWS, Azure, GCP, ...) or for a PaaS
   provider.
 
-* **Charlie**<a name="charlie"></a> (they/them) is a _cluster operator_,
+* **Chihiro**<a name="Chihiro"></a> (they/them) is a _cluster operator_,
   responsible for managing clusters to ensure that they meet the needs of
-  their several users. Charlie will typically be concerned with policies,
+  their several users. Chihiro will typically be concerned with policies,
   network access, application permissions, etc. Again, they are beholden to no
   single user of any cluster; rather, they need to make sure that the clusters
   serve all users as needed.
@@ -60,7 +60,7 @@ Depending on the environment, multiple roles can map to the same user:
   and may actually happen in a small startup running Kubernetes on bare metal.
 
 - A more typical small startup would use clusters from a cloud provider. In
-  this situation, Ana and Charlie may be embodied in the same person, with Ian
+  this situation, Ana and Chihiro may be embodied in the same person, with Ian
   being an employee (or automated process!) within the cloud provider.
 
 - In a much larger organization, we would expect each persona above to be

site-src/concepts/security-model.md

@@ -18,7 +18,7 @@ Gateway API has 3 primary API resources:
 There are 3 primary roles in Gateway API, as described in [roles and personas]:
 
 - **Ian** (he/him): Infrastructure Provider
-- **Charlie** (they/them): Cluster Operator
+- **Chihiro** (they/them): Cluster Operator
 - **Ana** (she/her): Application Developer
 
 [roles and personas]:/concepts/roles-and-personas

site-src/concepts/use-cases.md

@@ -7,14 +7,15 @@ examples that can be helpful to demonstrate how the API can be used.
 
 In all cases, it's very important to bear in mind the [roles and personas]
 used in the Gateway API. The use cases presented here are deliberately
-described in terms of [Ana], [Charlie], and [Ian]: they are the ones for whom the
-API must be usable. (It's also important to remember that even though these
-roles might be filled by the same person, especially in smaller organizations,
-they all have distinct concerns that we need to consider separately.)
+described in terms of [Ana], [Chihiro], and [Ian]: they are the ones for whom
+the API must be usable. (It's also important to remember that even though
+these roles might be filled by the same person, especially in smaller
+organizations, they all have distinct concerns that we need to consider
+separately.)
 
 [roles and personas]:/concepts/roles-and-personas
 [Ana]:/concepts/roles-and-personas#ana
-[Charlie]:/concepts/roles-and-personas#charlie
+[Chihiro]:/concepts/roles-and-personas#chihiro
 [Ian]:/concepts/roles-and-personas#ian
 
 ## The Use Cases
@@ -39,21 +40,21 @@ Kubernetes. Her application will be used by clients outside the cluster, and
 while Ana has created the application, setting up the cluster is not in her
 wheelhouse.
 
-1. Ana goes to Charlie to ask them to set up a cluster. Ana tells Charlie that
+1. Ana goes to Chihiro to ask them to set up a cluster. Ana tells Chihiro that
    her clients will expect her APIs to be available using URLs rooted at
    `https://ana.application.com/`.
 
-2. Charlie goes to Ian and requests a cluster.
+2. Chihiro goes to Ian and requests a cluster.
 
 3. Ian provisions a cluster running a gateway controller with a [GatewayClass]
    resource named `basic-gateway-class`. The gateway controller manages the
    infrastructure associated with routing traffic from outside the cluster to
    inside the cluster.
 
-4. Ian gives Charlie credentials to the new cluster, and tells Charlie that
+4. Ian gives Chihiro credentials to the new cluster, and tells Chihiro that
    they can use GatewayClass `basic-gateway-class` to set things up.
 
-5. Charlie applies a [Gateway] named `ana-gateway` to the cluster, telling it
+5. Chihiro applies a [Gateway] named `ana-gateway` to the cluster, telling it
    to listen on port 443 for TLS traffic, and providing it a TLS certificate
    with a Subject CN of `ana.application.com`. They associate this Gateway with the `basic-gateway-class` GatewayClass.
 
@@ -63,10 +64,10 @@ wheelhouse.
    443, and starts watching for routing resources associated with
    `ana-gateway`.
 
-7. Charlie gets the IP address of `ana-gateway` and creates a DNS record
+7. Chihiro gets the IP address of `ana-gateway` and creates a DNS record
    outside the cluster for `ana.application.com` to match.
 
-8. Charlie tells Ana that she's good to go, using the Gateway named
+8. Chihiro tells Ana that she's good to go, using the Gateway named
    `ana-gateway`.
 
 9. Ana writes and applies [HTTPRoute] resources to configure which URL paths
@@ -77,7 +78,7 @@ wheelhouse.
 10. At this point, when requests arrive at the load balancer, they are routed
     to Ana's application according to her routing specification.
 
-This allows Charlie to enforce centralized policies [such as
+This allows Chihiro to enforce centralized policies [such as
 TLS](/guides/tls#downstream-tls) at the Gateway, while simultaneously allowing
 Ana and her colleagues control over the application's [routing
 logic](/guides/http-routing) and rollout plans (e.g. [traffic splitting
@@ -98,20 +99,20 @@ Ana and her team are managing a storefront application in the `store`
 Namespace, while Allison and her team are managing a website in the `site`
 Namespace.
 
-- Ian and Charlie work together to provide a cluster, `GatewayClass`, and
+- Ian and Chihiro work together to provide a cluster, `GatewayClass`, and
   `Gateway`, as above.
 
 - Ana and Allison independently deploy workloads and HTTPRoutes bound to the
   same `Gateway` resource.
 
-Again, this separation of concerns allows Charlie to enforce centralized
+Again, this separation of concerns allows Chihiro to enforce centralized
 policies [such as TLS](/guides/tls#downstream-tls) can be enforced at the
 Gateway. Meanwhile, Ana and Allison run their applications [in their own
 Namespaces](/guides/multiple-ns), but attach their Routes to the same shared
 Gateway, allowing them to independently control their [routing
 logic](/guides/http-routing), [traffic splitting
 rollout](/guides/traffic-splitting), etc., while not worrying about the things
-that Charlie and Ian are handling.
+that Chihiro and Ian are handling.
 
 [HTTPRoute]:/api-types/httproute
 [GatewayClass]:/api-types/gatewayclass
@@ -134,7 +135,7 @@ protect her workload by rejecting calls to her workload with incorrect
 URL paths, and by enforcing timeouts whenever anyone makes a request of her
 workload.
 
-- Charlie and Ian have already provided a cluster with a running service mesh.
+- Chihiro and Ian have already provided a cluster with a running service mesh.
   Ana doesn't need to make any requests of them.
 
 - Ana writes an HTTPRoute that defines acceptable routes and timeouts and has
@@ -147,7 +148,7 @@ workload.
 
 In this case, the separation of concerns across roles allows Ana to take
 advantage of the service mesh, with custom routing logic, without any
-bottlenecks in requests to Charlie or Ian.
+bottlenecks in requests to Chihiro or Ian.
 
 [east/west]:/concepts/glossary#eastwest-traffic
 [GAMMA]:/concepts/gamma/
@@ -165,7 +166,7 @@ This is effectively a combination of the [multiple applications behind a
 single Gateway](#multiple-applications-behind-a-single-gateway) and [basic
 east/west](#basic-eastwest-use-case) use cases:
 
-- Charlie and Ian will provision a cluster, a [GatewayClass], and a [Gateway].
+- Chihiro and Ian will provision a cluster, a [GatewayClass], and a [Gateway].
 
 - Ana and Allison will deploy their applications in the appropriate
   Namespaces.
@@ -175,7 +176,7 @@ east/west](#basic-eastwest-use-case) use cases:
 There are two very important changes in this scenario, though, since a mesh is
 involved:
 
-1. If Charlie has deployed a [gateway controller] that defaults to [Service
+1. If Chihiro has deployed a [gateway controller] that defaults to [Service
    routing], they will probably need to reconfigure it for [endpoint routing].
    (This is an ongoing area of work for [GAMMA], but the expectation is that
    endpoint routing will be recommended.)
@@ -186,7 +187,7 @@ involved:
    HTTPRoutes that bind to both the Gateway and a Service.
 
 As always, the ultimate point of separating concerns in this way is that it
-permits Charlie to enforce centralized policies [such as
+permits Chihiro to enforce centralized policies [such as
 TLS](/guides/tls#downstream-tls) at the Gateway, while allowing Ana and
 Allison to retain independent control of [routing
 logic](/guides/http-routing), [traffic splitting

site-src/index.md

@@ -151,9 +151,9 @@ The roles used for the Gateway API's design are defined by three personas:
   to serve multiple tenants. He is not beholden to any single tenant; rather,
   he worries about all of them collectively.
 
-- **Charlie** (they/them) is a _cluster operator_. Their role is to manage a
+- **Chihiro** (they/them) is a _cluster operator_. Their role is to manage a
   single cluster, ensuring that it meets the needs of its several users.
-  Again, Charlie is beholden to no single user of their cluster; they need to
+  Again, Chihiro is beholden to no single user of their cluster; they need to
   make sure that the cluster serves all of them as needed.
 
 - **Ana** (she/her) is an _application developer_. Ana is in a unique position
@@ -165,7 +165,7 @@ The roles used for the Gateway API's design are defined by three personas:
 (These three are discussed in more detail in [Roles and
 Personas](/concepts/roles-and-personas).)
 
-It should be clear that while Ana, Charlie, and Ian do not necessarily see
+It should be clear that while Ana, Chihiro, and Ian do not necessarily see
 eye-to-eye about everything, they need to work together to keep things running
 smoothly. This is the core challenge of the Gateway API in a nutshell.
 
@@ -177,7 +177,7 @@ and implementations while remaining a portable and standard API.
 
 The use cases presented are deliberately cast in terms of the roles presented
 above. Ultimately the Gateway API is meant for use by humans, which means that
-it must fit the uses to which each of Ana, Charlie, and Ian will put it.
+it must fit the uses to which each of Ana, Chihiro, and Ian will put it.
 
 [use-cases]:/concepts/use-cases