github/capsule
1
0
Fork 0
mirror of https://github.com/projectcapsule/capsule.git synced 2026-08-18 12:06:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: fix typo (#1945)

Browse Source 
* chore: typo in ruleset description crd

Signed-off-by: sandert-k8s <sandert98@gmail.com>

* chore: fix typo

Signed-off-by: sandert-k8s <sandert98@gmail.com>

---------

Signed-off-by: sandert-k8s <sandert98@gmail.com>
This commit is contained in:
Sander Tervoert
2026-06-03 16:55:59 +02:00
committed by GitHub
parent 3d1158ed23
commit d5cb91e1c1
7 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+1 -1
View File
@@ -39,7 +39,7 @@ Versions follow [Semantic Versioning](https://semver.org/) terminology and are e
Security fixes, may be backported to the three most recent minor releases, depending on severity and feasibility.
Prereleases are marked as `-rc.x` (release candidate) and may refere to any type of version bump.
Prereleases are marked as `-rc.x` (release candidate) and may refer to any type of version bump.
## Pull Requests
DEVELOPMENT.md
+1 -1
View File
@@ -214,7 +214,7 @@ make helm-test
### Documentation
Documentation of the chart is done with [helm-docs](https://github.com/norwoodj/helm-docs). Therefor all documentation relevant changes for the chart must be done in the [README.md.gotmpl](./charts/capsule/README.md.gotmpl) file. You can run this locally with this command (requires running docker daemon):
Documentation of the chart is done with [helm-docs](https://github.com/norwoodj/helm-docs). Therefore all documentation relevant changes for the chart must be done in the [README.md.gotmpl](./charts/capsule/README.md.gotmpl) file. You can run this locally with this command (requires running docker daemon):
```bash
make helm-docs
api/v1beta2/capsuleconfiguration_types.go
+1 -1
View File
@@ -45,7 +45,7 @@ type CapsuleConfigurationSpec struct {
EnableTLSReconciler bool `json:"enableTLSReconciler"` //nolint:tagliatelle
// Define entities which can act as Administrators in the capsule construct
// These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label
// for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefor
// for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefore
// be ignored by capsule.
Administrators rbac.UserListSpec `json:"administrators,omitempty"`
// Configuration for dynamic Validating and Mutating Admission webhooks managed by Capsule.
charts/capsule/README.md
+1 -1
View File
@@ -118,7 +118,7 @@ The following Values have changed key or Value:
| manager.image.tag | string | `""` | Overrides the image tag whose default is the chart appVersion. |
| manager.kind | string | `"Deployment"` | Set the controller deployment mode as `Deployment` or `DaemonSet`. |
| manager.livenessProbe | object | `{"httpGet":{"path":"/healthz","port":10080}}` | Configure the liveness probe using Deployment probe spec |
| manager.options.administrators | list | `[]` | Define entities which can act as Administrators in the capsule construct These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefor be ignored by capsule. May also be handy in GitOps scenarios where certain service accounts need to be able to manage namespaces for all tenants. |
| manager.options.administrators | list | `[]` | Define entities which can act as Administrators in the capsule construct These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefore be ignored by capsule. May also be handy in GitOps scenarios where certain service accounts need to be able to manage namespaces for all tenants. |
| manager.options.allowServiceAccountPromotion | bool | `false` | ServiceAccounts within tenant namespaces can be promoted to owners of the given tenant this can be achieved by labeling the serviceaccount and then they are considered owners. This can only be done by other owners of the tenant. However ServiceAccounts which have been promoted to owner can not promote further serviceAccounts. |
| manager.options.annotations | object | `{}` | Additional annotations to add to the CapsuleConfiguration resource |
| manager.options.cacheInvalidation | string | `"0h30m0s"` | Duration after which the in-memory cache is invalidated (based on usaage) and re-fetched from the API server |
charts/capsule/crds/capsule.clastix.io_capsuleconfigurations.yaml
+1 -1
View File
@@ -52,7 +52,7 @@ spec:
description: |-
Define entities which can act as Administrators in the capsule construct
These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label
for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefor
for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefore
be ignored by capsule.
items:
properties:
charts/capsule/values.schema.json
+1 -1
View File
@@ -361,7 +361,7 @@
"type": "object",
"properties": {
"administrators": {
"description": "Define entities which can act as Administrators in the capsule construct These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefor be ignored by capsule. May also be handy in GitOps scenarios where certain service accounts need to be able to manage namespaces for all tenants.",
"description": "Define entities which can act as Administrators in the capsule construct These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefore be ignored by capsule. May also be handy in GitOps scenarios where certain service accounts need to be able to manage namespaces for all tenants.",
"type": "array"
},
"allowServiceAccountPromotion": {
charts/capsule/values.yaml
+1 -1
View File
@@ -201,7 +201,7 @@ manager:
name: "projectcapsule.dev"
# -- Define entities which can act as Administrators in the capsule construct
# These entities are automatically owners for all existing tenants. Meaning they can add namespaces to any tenant. However they must be specific by using the capsule label
# for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefor
# for interacting with namespaces. Because if that label is not defined, it's assumed that namespace interaction was not targeted towards a tenant and will therefore
# be ignored by capsule. May also be handy in GitOps scenarios where certain service accounts need to be able to manage namespaces for all tenants.
administrators: []
# - kind: "User"