Update glossary with descriptions from Istio Vocabulary doc.#580
Update glossary with descriptions from Istio Vocabulary doc.#580rshriram merged 10 commits intoistio:masterfrom smawson:glossary
Conversation
Update my branch
Also cleaned up a few other items such as the Pilot entry.
|
Jenkins job istio.github.io/presubmit passed |
| --- | ||
| Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and | ||
| credential management. Learn more about Istio-Auth [here](../concepts/network-and-auth/auth.html). | ||
| Provides strong service-to-service authentication using mutual TLS, with built-in identity and credential management. |
There was a problem hiding this comment.
Instead of "Provides", perhaps "Supports"?
There was a problem hiding this comment.
Tried it and it felt wrong. I think we need to rewrite auth here and give a better description, I'll talk to Wencheng. For now will leave as-is.
| type: markdown | ||
| --- | ||
| The agent that creates a service by writing source code. | ||
| The agent that creates a **Service** and manages which **Service Consumers** may use it. |
There was a problem hiding this comment.
The operator is really the one that decides who can use the service, so I'd strike that second part of the sentence.
There was a problem hiding this comment.
We're talking about different roles here, it is the same person, but in their provider role that they are deciding who can access, not as operator. Or at least that's what we usually mean by the producer/consumer/operator split. We could maybe just delete producer/consumer from the glossary since they're more about API management than service management?
There was a problem hiding this comment.
Yeah, I think removing these for the time being would be good. We'll have a better grip on things for 0.3
| service has a default version consisting of all its instances. | ||
| Distinct variants of a **Service**, typically backed by a different version of a **Workload** binary. | ||
| Common scenarios where multiple **Service Versions** may be used include A/B testing, canary rollouts, etc. | ||
| Each **Service** has a default **Service Version** consisting of all its **Service Endpoints**. |
There was a problem hiding this comment.
I'm puzzled by what this means. I don't think we can say that a "version consists of endpoints". Maybe just drop the "consisting of all its Service Endpoints" part?
| use to refer to the functionality being called. Service instances are | ||
| pods/VMs/containers that implement the service. | ||
| A delineated group of related behaviors within a **Service Mesh**. Services are named using a **Service Name**, | ||
| and Istio policies such as load balancing and routing are applied to **Service Names**. |
There was a problem hiding this comment.
"applied to" isn't right. "applied to services using service names". Or maybe just "applied using service names"
| pods/VMs/containers that implement the service. | ||
| A delineated group of related behaviors within a **Service Mesh**. Services are named using a **Service Name**, | ||
| and Istio policies such as load balancing and routing are applied to **Service Names**. | ||
| A **Service** is typically materialized by one or more **Service Endpoints**. |
There was a problem hiding this comment.
, and may consists of multiple co-existent service versions.
| @@ -0,0 +1,7 @@ | |||
| --- | |||
| title: Workload | |||
| Istio service-to-service authentication is used to produce the **Workload Principal**. | ||
| By default **Workload Principals** are compliant with the SPIFFE ID format. | ||
| * Multiple **Workloads** may share the same **Workload Principal**, but each **Workload** has a single canonical **Workload Principal**. | ||
| * **Worklooad Principals** are accessible in Istio configuration as the `source.user` and `destination.user` attributes. |
There was a problem hiding this comment.
Shame we can be consistent here with "user" vs "principal".
There was a problem hiding this comment.
Also typo.. Worklooad (double o)
There was a problem hiding this comment.
Yeah we want to change this in an upcoming release but didn't want to do it right before 0.2.
Plan is to rename to source.principal and destination.principal, and we'll also have request.auth.principal for auth credentials.
| --- | ||
| A unique name for a **Workload**, identifying it within the **Service Mesh**. | ||
| Unlike **Service Name** and **Workload Principal**, **Workload Name** is not a strongly verified property and should not be used when enforcing ACLs. | ||
| * **Workload Names** are accessible in Istio configuration as the `source.name` and `destination.name` attributes. |
There was a problem hiding this comment.
Shame this isn't source.workload.name and destination.workload.name.
There was a problem hiding this comment.
If it matters, we've been using source.uid and destination.uid to denote the workload IDs.
There was a problem hiding this comment.
So what's the relationship between source.name and source.uid? Should we have a glossary entry for Workload Id? Given workload id, why do we need workload name?
There was a problem hiding this comment.
Added a glossary entry for Workload ID.
Both are useful, since workload name is a natural grouping of workload IDs and more useful in dashboards.
Maps to source.uid and destination.uid.
|
Jenkins job istio.github.io/presubmit passed |
5 participants
Also cleaned up a few other items while I was at it.