Skip to content

Commit 8c815d7

Browse files
authored
Merge pull request #3458 from xrstf/fix-typos
fix a bunch of typos
2 parents e747d52 + 656ae61 commit 8c815d7

File tree

29 files changed

+85
-62
lines changed

29 files changed

+85
-62
lines changed

.typos.toml

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# configuration for https://github.com/crate-ci/typos
2+
3+
[default.extend-words]
4+
Informable = "Informable"
5+
Creater = "Creater"
6+
7+
[default.extend-identifiers]
8+
ANDed = "ANDed"
9+
p0lyn0mial = "p0lyn0mial"
10+
HashiCorp = "HashiCorp"
11+
12+
[default]
13+
extend-ignore-identifiers-re = [
14+
"\\bTLS_[A-Z0-9_]+(_anon_[A-Z0-9_]+)?\\b",
15+
]
16+
17+
[files]
18+
extend-exclude = [
19+
"config/crds",
20+
"contrib/crds",
21+
"sdk/apis/third_party",
22+
"sdk/testing/third_party",
23+
]

GOVERNANCE.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -133,7 +133,7 @@ to the private Maintainer mailing list or alias in the code-of-conduct file.-->
133133
kcp has adopted the CNCF [Code of Conduct](./code-of-conduct.md). Reporting of
134134
Code of Conduct violations happen through the [CNCF Code of Conduct committee](./code-of-conduct.md#reporting)
135135
and kcp maintainers pledge to work with the committee to resolve any incidents
136-
occuring in the kcp community.
136+
occurring in the kcp community.
137137

138138
## Security Response Team
139139

Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -347,7 +347,7 @@ test-e2e-sharded-minimal: build-all
347347
$(if $(value WAIT),|| { echo "Terminated with $$?"; wait "$$PID"; },)
348348

349349
# This is just easy target to run 2 shard test server locally until manually killed.
350-
# You can targer test to it by running:
350+
# You can target test to it by running:
351351
# go test ./test/e2e/apibinding/... --kcp-kubeconfig=$(pwd)/.kcp/admin.kubeconfig --shard-kubeconfigs=root=$(pwd)/.kcp-0/admin.kubeconfig -run=^TestAPIBinding$
352352
test-run-sharded-server: WORK_DIR ?= $(PWD)
353353
test-run-sharded-server: LOG_DIR ?= $(WORK_DIR)/.kcp

docs/content/concepts/authorization/authorizers.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -138,7 +138,7 @@ A service-account defined in a different workspace is NOT given access to it.
138138

139139
#### System CRD Authorizer
140140

141-
This small authorizer simply prevents updates to the `status` subresource on APIExports or APIBindings. Note that this authorizer does not validate changes to the CustomResourceDefitions themselves, but to objects from those CRDs instead.
141+
This small authorizer simply prevents updates to the `status` subresource on APIExports or APIBindings. Note that this authorizer does not validate changes to the CustomResourceDefinitions themselves, but to objects from those CRDs instead.
142142

143143
#### Maximal Permission Policy Authorizer
144144

docs/content/concepts/sharding/shards.md

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -21,13 +21,13 @@ cluster holds administrational objects. Among them are shard objects.
2121
The set of shards in a kcp installation is defined by `Shard` objects in
2222
`core.kcp.io/v1alpha1`.
2323

24-
A shard object specifies the network addresses, one for external access (usually
24+
A shard object specifies the network addresses, one for external access (usually
2525
some worldwide load balancer) and one for direct access (shard to shard).
2626

2727
## Logical Clusters and Workspace Paths
2828

2929
Logical clusters are defined through the existence of a `LogicalCluster` object
30-
"in themselves", similar to a `.` directory defining the existence of a directory
30+
"in themselves", similar to a `.` directory defining the existence of a directory
3131
in Unix.
3232

3333
Every logical cluster name `name` is a *logical cluster path*. Every logical
@@ -54,8 +54,8 @@ for the parent (`home` in this case) to exist.
5454
## Front Proxy
5555

5656
A front-proxy is aware of all logical clusters, their shard they live on,
57-
their canonical paths and all `Workspaces`s. Non canonical paths can be
58-
reconstructed from the canonical path prefixes and the worksapce names.
57+
their canonical paths and all `Workspaces`s. Non canonical paths can be
58+
reconstructed from the canonical path prefixes and the workspace names.
5959

6060
Requests to `/cluster/<path>` are forwarded to the shard via inverse proxying.
6161

@@ -70,7 +70,7 @@ or multiple per region or cloud provider.
7070
## Consistency Domain
7171

7272
Every logical cluster provides a Kubernetes-compatible API root endpoint under
73-
`/cluster/<path>` including its own discovery endpoint and their own set of
73+
`/cluster/<path>` including its own discovery endpoint and their own set of
7474
API groups and resources.
7575

7676
Resources under such an endpoints satisfy the same consistency properties as with
@@ -84,12 +84,12 @@ i.e. resource versions cannot be compared.
8484

8585
The only exception to the upper rule are objects under a "wildcard endpoint"
8686
`/clusters/*/apis/<group>/<v>/[namespaces/<ns>]/resource:<identity-hash>` per
87-
shard. It serves the objects of the given resource on that shard across
87+
shard. It serves the objects of the given resource on that shard across
8888
logical-clusters. The annotation `kcp.io/cluster` tells the consumer which
8989
logical cluster each object belongs to.
9090

9191
The wildcard endpoint is privileged (requires `system:masters` group membership).
92-
It is only accessible when talking directly to a shard, not through a
92+
It is only accessible when talking directly to a shard, not through a
9393
front-proxy.
9494

9595
Note: for unprivileged access, virtual view apiservers can offer a highly
@@ -115,7 +115,7 @@ the shard hosting the `Workspace` object will access another shard to create the
115115
`LogicalCluster` object initially. It does that by choosing a random logical
116116
cluster name (optimistically) and choosing a shard that name maps to (through
117117
consistent hashing). It then tries to create the `LogicalCluster`. On conflict,
118-
it can check whether the existing object belong the given `Workspace` object or
118+
it can check whether the existing object belong the given `Workspace` object or
119119
not. If not, another name and shard is chosen, until scheduling succeeds. During
120120
initialization the controller on the `Workspace` hosting shard will keep watching
121121
the logical cluster on the other shard, with some exponential backoff. In other
@@ -125,8 +125,8 @@ the other shard.
125125
Another example is API binding, but it is different than workspace scheduling:
126126
a binding controller running on the shard hosting the `APIBinding` object will
127127
be aware of all `APIExport`s in the kcp installation through caching replication
128-
(see next section). What is special is that this controller has all the
129-
information necessary to bind a new API and to keep bound APIs working even if
128+
(see next section). What is special is that this controller has all the
129+
information necessary to bind a new API and to keep bound APIs working even if
130130
the shard of the `APIExport` is unavailable.
131131

132132
Note: usually it a bad idea to create logic dependent on the parent workspace. If
@@ -138,12 +138,12 @@ parent is not accessible.
138138

139139
The cache server is a special API server that can hold replicas of objects that
140140
must be available globally in an eventual consistent way. E.g. the `APIExport`s
141-
and `APIResourceSchemas` are replicated that way and made available to the
141+
and `APIResourceSchemas` are replicated that way and made available to the
142142
corresponding controllers via informers.
143143

144144
The cache server holds objects by logical clusters, and it can hold objects from
145145
many or all shards in a kcp installation, served through wildcard informers.
146-
The resource versions of those objects have no meaning beyond driving the cache
146+
The resource versions of those objects have no meaning beyond driving the cache
147147
informers running in the shards.
148148

149149
Cache servers can be 1:1 with shards, or there can be shared cache servers, e.g.
@@ -155,22 +155,22 @@ Controllers that make use of cached objects, will usually have informers against
155155
local objects and against the same objects in the cache server. If the former
156156
returns a "NotFound" error, the controllers will look up in the cache informers.
157157

158-
The cache server technique is only useful for APIs whose object cardinality
158+
The cache server technique is only useful for APIs whose object cardinality
159159
across all shards does not go beyond the cardinality sensibly storable in a
160160
kube-based apiserver.
161161

162162
Note that objects like `Workspace`s and `LogicalCluster`s fall not into that
163163
category. This means that in particular the logical cluster canonical path
164164
cannot be derived from cached `LogicalCluster`s. Instead, the cached objects
165165
must hold their own `kcp.io/path` annotation in order to be indexable by that
166-
value. This is crucial to implement cross-logical-cluster references by
166+
value. This is crucial to implement cross-logical-cluster references by
167167
canonical path.
168168

169169
Note: the `APIExport` example assumes that there are never more than e.g. 10,000
170-
API exports in a kcp installation. If that is not an acceptable constraint,
170+
API exports in a kcp installation. If that is not an acceptable constraint,
171171
other partitioning mechanism would be need to hold the number of `APIExport`
172172
objects per cache server below the critical number. E.g. there could be cache
173-
servers per big tenant, and that would hold only public exports and
173+
servers per big tenant, and that would hold only public exports and
174174
tenant-internal exports. A more complex caching hierarchy would make sure the
175175
right objects are replicated, while the "really public" exports would only be a
176176
small number.
@@ -182,9 +182,9 @@ server replication is costly, this set is as minimal as possible. For example,
182182
certain RBAC objects are replicated in case they are needed to successfully
183183
authorize bindings of an API, or to use a workspace type.
184184

185-
By the nature of replication, objects in the cache server can be old and
185+
By the nature of replication, objects in the cache server can be old and
186186
incomplete. For instance, the non-existence of an object in the cache server
187-
does not mean it does not exist in its respective shard. The replication
187+
does not mean it does not exist in its respective shard. The replication
188188
could be just delayed or the object was not identified to be worth to replicate.
189189

190190
## Bootstrapping

docs/content/concepts/workspaces/workspace-types.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -133,8 +133,8 @@ kcp startup:
133133
- Workspace CRD
134134
- WorkspaceType CRD
135135
- Shard CRD
136-
- Partion CRD
137-
- PartionSet CRD
136+
- Partition CRD
137+
- PartitionSet CRD
138138

139139
The root workspace is the only one that holds `Shard` objects. Shards
140140
are used to schedule a new Workspace to, i.e. to select in which etcd the
@@ -153,7 +153,7 @@ that are scoped to the local shard (e.g. `lease` objects for kcp internal contro
153153
leader election is enabled). It is accessible via `/clusters/system:admin`.
154154

155155
# Workspace Type Extensions and Constraints
156-
kcp offers extensions and constraints that enable you inherit functionality from other
156+
kcp offers extensions and constraints that enable you inherit functionality from other
157157
workspace types and create custom workspace hierarchies for your organizational structure.
158158

159159
A `WorkspaceType` can extend one or more other `WorkspaceTypes` using the `spec.extend.with`
@@ -188,7 +188,7 @@ spec:
188188
- name: standard
189189
path: root:base
190190
```
191-
## Workspace Constraint Mechanisms
191+
## Workspace Constraint Mechanisms
192192
KCP provides two primary constraint mechanisms for workspace types:
193193
* `limitAllowedChildren`: Controls which workspace types can be created as children.
194194
* `limitAllowedParents`: Controls which workspace types can serve as parents.

docs/content/contributing/index.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ Please read the following guide if you're interested in contributing to kcp.
88
## Code of Conduct
99

1010
Please be aware that this project is governed by the [CNCF Code of Conduct](https://github.com/kcp-dev/kcp/blob/main/code-of-conduct.md),
11-
which boils down to "let's be excelent to each other". Code of Conduct violations can be reported to the
11+
which boils down to "let's be excellent to each other". Code of Conduct violations can be reported to the
1212
[CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/), which can be reached via [[email protected]](mailto:[email protected]).
1313

1414
## Certificate of Origin
@@ -82,4 +82,4 @@ The `kcp` project uses `OWNERS` files to denote the collaborators who can assist
8282
are two roles: reviewer and approver. Merging a PR requires sign off from both a reviewer and an approver.
8383

8484
In general, maintainers strive to pick up PRs for review when they can. If you feel like your PR has been missed,
85-
do not hesistate to ping maintainers directly or ask on the project communication channels about your PR.
85+
do not hesitate to ping maintainers directly or ask on the project communication channels about your PR.

pkg/admission/workspace/admission.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -106,7 +106,7 @@ func (o *workspace) Admit(ctx context.Context, a admission.Attributes, _ admissi
106106
ws.Annotations[tenancyv1alpha1.ExperimentalWorkspaceOwnerAnnotationKey] = userInfo
107107
}
108108

109-
// copy required groups from LogicalCluster to new child-Worksapce
109+
// copy required groups from LogicalCluster to new child-workspace
110110
if _, found := ws.Annotations[authorization.RequiredGroupsAnnotationKey]; !found || !isSystemPrivileged {
111111
logicalCluster, err := o.logicalClusterLister.Cluster(clusterName).Get(corev1alpha1.LogicalClusterName)
112112
if err != nil {

pkg/authorization/workspace_content_authorizer_test.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -192,7 +192,7 @@ func TestWorkspaceContentAuthorizer(t *testing.T) {
192192
wantReason: "delegating due to logical cluster admin access",
193193
},
194194
{
195-
testName: "system:kcp:logical-cluster-admin can always pass with exeception if scoped",
195+
testName: "system:kcp:logical-cluster-admin can always pass with exception if scoped",
196196

197197
requestedWorkspace: "root:non-existent",
198198
requestingUser: &user.DefaultInfo{Name: "lcluster-admin", Extra: map[string][]string{

pkg/network/dialer.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ func DefaultTransportWrapper(rt http.RoundTripper) http.RoundTripper {
4848

4949
// This function may be called from different goroutines on the same
5050
// `rt` at the same time, causing a data race.
51-
// To preven this race .DialContext is swapped atomically.
51+
// To prevent this race .DialContext is swapped atomically.
5252
defaultDialContext := DefaultDialContext()
5353
trDialContext := unsafe.Pointer(&tr.DialContext)
5454
atomic.StorePointer(&trDialContext, unsafe.Pointer(&defaultDialContext))

0 commit comments

Comments
 (0)