cwielenb/CNCF-Dataset huggingface dataset:
Project: external-secrets (Provisioning / Security & Compliance)
File: datafrom-rewrite.md

When calling out an ExternalSecret with `dataFrom.extract` or `dataFrom.find`, it is possible that you end up with a kubernetes secret that has conflicts in the key names, or that you simply want to remove a common path from the secret keys. In order to do so, it is possible to define a set of rewrite operations using `dataFrom.rewrite`. These operations can be stacked, hence allowing complex manipulations of the secret keys. Rewrite operations are all applied before `ConversionStrategy` is applied. This method implements rewriting through the use of regular expressions. It needs a `source` and a `target` field. The source field is where the definition of the matching regular expression goes, where the `target` field is where the replacing expression goes. Some considerations about the implementation of Regexp Rewrite: The input of a subsequent rewrite operation are the outputs of the previous rewrite. If a given set of keys do not match any Rewrite operation, there will be no error. Rather, the original keys will be used. If a `source` is not a compilable `regexp` expression, an error will be produced and the external secret goes into a error state. The following ExternalSecret: ```yaml {% include 'datafrom-rewrite-remove-path.yaml' %} ``` Will get all the secrets matching `path/to/my/secrets/*` and then rewrite them by removing the common path away. In this example, if we had the following secrets available in the provider: ``` path/to/my/secrets/username path/to/my/secrets/password ``` the output kubernetes secret would be: ```yaml apiVersion: v1 kind: Secret type: Opaque data: username: ... password: ... ``` The following ExternalSecret: ```yaml {% include 'datafrom-rewrite-conflict.yaml' %} ``` Will allow two secrets with the same JSON keys to be imported into a Kubernetes Secret without any conflict. In this example, if we had the following secrets available in the provider: ```json { "my-secrets-dev": { "password": "bar", }, "my-secrets-prod": { "password": "safebar", } } ``` the output kubernetes secret would be: ```yaml apiVersion: v1 kind: Secret type: Opaque data: dev_password: YmFy #bar prod_password: c2FmZWJhcg== #safebar ``` The following ExternalSecret: ```yaml {% include 'datafrom-rewrite-invalid-characters.yaml' %} ``` Will remove invalid characters from the secret key. In this example, if we had the following secrets available in the provider: ```json { "development": { "foo/bar": "1111", "foo$baz": "2222" } } ``` the output kubernetes secret would be: ```yaml apiVersion: v1 kind: Secret type: Opaque data: foo_bar: MTExMQ== #1111 foo_baz: MjIyMg== #2222 ``` Regexp Rewrite is based on golang `regexp`, which in turns implements `RE2` regexp language. There a a series of known limitations to this implementation, such as: Lack of ability to do lookaheads or lookbehinds; Lack of negation expressions; Lack of support for conditional branches; Lack of support for possessive repetitions. A list of compatibility and known limitations considering other commonly used regexp frameworks (such as PCRE and PERL) are listed .
Project: Pinniped (Provisioning / Key Management)
File: SCOPE.md

The Pinniped project is guided by the following principles. Pinniped lets you plug any external identity providers into Kubernetes. These integrations follow enterprise-grade security principles. Pinniped is easy to install and use on any Kubernetes cluster via distribution-specific integration mechanisms. Pinniped uses a declarative configuration via Kubernetes APIs. Pinniped provides optimal user experience when authenticating to many clusters at one time. Pinniped provides enterprise-grade security posture via secure defaults and revocable or very short-lived credentials. Where possible, Pinniped will contribute ideas and code to upstream Kubernetes. When contributing to Pinniped, please consider whether your contribution follows these guiding principles. The following items are out of scope for the Pinniped project. Authorization. Standalone identity provider for general use. Machine-to-machine (service) identity. Running outside of Kubernetes.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: cache.md

id: cache title: Cache Service sidebar_label: Cache description: Documentation for the Cache service This service lets your plugin interact with a cache. It is bound to your plugin too, so that you will only set and get values in your plugin's private namespace. The following example shows how to get a cache client in your `example` backend plugin and setting and getting values from the cache. ```ts import { coreServices, createBackendPlugin, } from '@backstage/backend-plugin-api'; createBackendPlugin({ pluginId: 'example', register(env) { env.registerInit({ deps: { cache: coreServices.cache, }, async init({ cache }) { const { key, value } = { key: 'test:key', value: 'bob' }; await cache.set(key, value, { ttl: 1000 }); // .. some other stuff. await cache.get(key); // 'bob' }, }); }, }); ```
Project: ArangoDB (App Definition and Development / Database)
File: std_unchecked.md

+++ title = "`stdunchecked<T, E = std::errorcode>`" description = "A type alias to a `basicresult` configured with `std::errorcode` and `policy::all_narrow`." +++ A type alias to a {{% api "basicresult<T, E, NoValuePolicy>" %}} configured with {{% api "std::errorcode" %}} and `policy::`{{% api "all_narrow" %}}. This type alias always references the `std` edition of things, unlike {{% api "unchecked<T, E = varies>" %}} which references either this alias or {{% api "boostunchecked<T, E = boost::system::errorcode>" %}}. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/std_result.hpp>`
Project: Distribution (Provisioning / Container Registry)
File: compatibility.md

description: describes get by digest pitfall keywords: registry, manifest, images, tags, repository, distribution, digest title: Registry compatibility If a manifest is pulled by digest from a registry 2.3 with Docker Engine 1.9 and older, and the manifest was pushed with Docker Engine 1.10, a security check causes the Engine to receive a manifest it cannot use and the pull fails. Historically, the registry has supported a single manifest type known as Schema 1. With the move toward multiple architecture images, the distribution project introduced two new manifest types: Schema 2 manifests and manifest lists. Registry 2.3 supports all three manifest types and sometimes performs an on-the-fly transformation of a manifest before serving the JSON in the response, to preserve compatibility with older versions of Docker Engine. This conversion has some implications for pulling manifests by digest and this document enumerates these implications. Manifests are stored and retrieved in the registry by keying off a digest representing a hash of the contents. One of the advantages provided by CAS is security: if the contents are changed, then the digest no longer matches. This prevents any modification of the manifest by a MITM attack or an untrusted third party. When a manifest is stored by the registry, this digest is returned in the HTTP response headers and, if events are configured, delivered within the event. The manifest can either be retrieved by the tag, or this digest. For registry versions 2.2.1 and below, the registry always stores and serves Schema 1 manifests. Engine 1.10 first attempts to send a Schema 2 manifest, falling back to sending a Schema 1 type manifest when it detects that the registry does not support the new version. The Engine constructs a Schema 2 manifest which the registry persists to disk. When the manifest is pulled by digest or tag with Docker Engine 1.10, a Schema 2 manifest is returned. Docker Engine 1.10 understands the new manifest format. When the manifest is pulled by tag with Docker Engine 1.9 and older, the manifest is converted on-the-fly to Schema 1 and sent in the response. The Docker Engine 1.9 is compatible with this older format. When the manifest is pulled by digest with Docker Engine 1.9 and older, the same rewriting process does not happen in the registry. If it did, the digest would no longer match the hash of the manifest and would violate the constraints of CAS. For this reason if a manifest is pulled by digest from a registry 2.3 with Docker Engine 1.9 and older, and the manifest was pushed with Docker Engine 1.10, a security check causes the Engine to receive a manifest it cannot use and the pull fails. The Docker Engine constructs a Schema 1 manifest which the registry persists to disk. When the manifest is pulled by digest or tag with any Docker version, a Schema 1 manifest is returned.
Project: Sonobuoy (Provisioning / Security & Compliance)
File: sonobuoy_results.md

Inspect plugin results. ``` sonobuoy results archive.tar.gz [flags] ``` ``` -h, --help help for results -m, --mode string Modifies the format of the output. Valid options are report, detailed, readable, or dump. (default "report") -n, --node string Traverse results starting at the node with the given name. Defaults to the real root. -p, --plugin string Which plugin to show results for. Defaults to printing them all. -s, --skip-prefix When printing items linking to files, only print the file contents. ``` ``` --level level Log level. One of {panic, fatal, error, warn, info, debug, trace} (default info) ``` - Generate reports on your Kubernetes cluster by running plugins
Project: SPIRE (Provisioning / Key Management)
File: plugin_agent_keymanager_disk.md

The `disk` plugin generates a key pair for the agent's identity, storing the private key on disk. If the agent is restarted, the key will be loaded from disk. If the agent is unavailable for long enough for its certificate to expire, attestation will need to be re-performed. | Configuration | Description | ||--| | directory | The directory in which to store the private key. | A sample configuration: ```hcl KeyManager "disk" { plugin_data = { directory = "/opt/spire/data/agent" } } ```
Project: zot (Provisioning / Container Registry)
File: README_userprefs.md

`userprefs` component provides an endpoint for adding user preferences for repos. It is available only to authentificated users. Unauthentificated users will be denied access. | Supported queries | Input | Output | Description | | | | | | | | None | None | Sets the repo starred property to true if it is false, and to false if it is true | | | None | None | Sets the repo bookmarked property to true if it is false, and to false if it is true | The userprefs endpoint accepts as a query parameter what `action` to perform and then all other required parameters for the specified action. | Action | Parameter | Parameter Type | Parameter Description | | | | | | | toggleStar | repo | string | The repo name which should be starred | A request to togle a star on a repo would look like this: ``` (PUT) http://localhost:8080/v2/_zot/ext/userprefs?action=toggleStar&repo=repoName ``` | Action | Parameter | Parameter Type | Parameter Description | | | | | | | toggleBookmark | repo | string | The repo name which should be bookmarked | A request to togle a bookmark on a repo would look like this: ``` (PUT) http://localhost:8080/v2/_zot/ext/userprefs?action=toggleBookmark&repo=repoName ```
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_core.TabState.md

/ / TabState .TabState State that we want to keep per tab new TabState(`uuid`, `desiredStatusStripeDecoration?`, `parent?`) | Name | Type | | :- | : | | `uuid` | `string` | | `_desiredStatusStripeDecoration` | | | `_parent?` | | `Private` \_state: `Record`<`string`, `Record`<`string`, `any`\>\> = `{}` state map outer key is `TabStateRegistrar.name`, inner key is `TabStateRegistrar.apiVersion` e.g. { 'plugins/plugin-core': {'v1': {'cwd': '/'}}} `Private` captures: `CaptureFn`[] = `[]` functions to capture the states of tab closed: `boolean` is the tab closed? ready: `boolean` = `false` is the tab ready for command execution? `Private` restores: `RestoreFn`[] = `[]` functions to restore the states of the tab `Private` switchTos: `SwitchToFn`[] = `[]` functions to capture this tab state and restore another tab state `Readonly` uuid: `string` `get` desiredStatusStripeDecoration(): `set` desiredStatusStripeDecoration(`decor`): `void` | Name | Type | | : | : | | `decor` | | `void` `get` state(): `Record`<`string`, `Record`<`string`, `any`\>\> `Record`<`string`, `Record`<`string`, `any`\>\> capture(): `void` Capture contextual global state `void` `Private` checkExistence(`name`, `apiVersion`): `boolean` | Name | Type | | :-- | :- | | `name` | `string` | | `apiVersion` | `string` | `boolean` cloneWithUUID(`uuid`): Clone the captured state | Name | Type | | :-- | :- | | `uuid` | `string` | getState(`name`, `apiVersion`, `key`): `any` | Name | Type | | :-- | :- | | `name` | `string` | | `apiVersion` | `string` | | `key` | `string` | `any` register(`name`, `apiVersion`, `capture`, `restore`, `switchTo`): `void` | Name | Type | | :-- | :-- | | `name` | `string` | | `apiVersion` | `string` | | `capture` | `CaptureFn` | | `restore` | `RestoreFn` | | `switchTo` | `SwitchToFn` | `void` restore(): `Promise`<`void`\> Restore tab state `Promise`<`void`\> setState(`name`, `apiVersion`, `key`, `value`): `Promise`<`void`\> | Name | Type | | :-- | :- | | `name` | `string` | | `apiVersion` | `string` | | `key` | `string` | | `value` | `any` | `Promise`<`void`\> switchTo(`nextTabState`): `Promise`<`void`\> Capture contextual global state and then restore `nextTabState` | Name | Type | | :- | : | | `nextTabState` | | `Promise`<`void`\> updateStatusStripe(): `void` Enforce our desired status stripe decorations `void`
Project: Athenz (Provisioning / Key Management)
File: email_notifications.md

Athenz can send email notifications for events such as a role member with access that about to expire. Athenz supports Amazon Simple Email Service (Amazon SES) out of the box. This requires Athenz to be deployed on AWS. Users may use other Email Providers by following the steps to Enable Email Notifications for ZMS server by editing the zms.properties file: ``` athenz.zms.notificationservicefactory_class=com.yahoo.athenz.common.server.notification.impl.NotificationServiceFactoryImpl athenz.notificationemaildomain_from=from.domain.com athenz.notificationemailfrom=sender.name athenz.notificationemaildomain_to=to.domain.com athenz.notificationworkflowurl=https://your.athenz.ui/athenz/workflow athenz.notificationathenzui_url=https://your.athenz.ui/athenz ``` To use other providers, create a Jar file on the Athenz classpath with implementations for the following Interface: ``` com.yahoo.athenz.common.server.notification.NotificationServiceFactory - A factory that creates a Notification Service based on a Notifications Provider. ``` You may use the existing com.yahoo.athenz.common.server.notification.impl.EmailNotificationService and inject a new provider or implement a compleley new Notifications Provider that will notify users by means other than email. If you do plan on sending email notifications, implement the following interface: ``` com.yahoo.athenz.common.server.notification.EmailProvider ``` For example, to enable Email Notifications with your provider, you may implement com.yahoo.athenz.common.server.notification.NotificationServiceFactory like so: ```java package your.packge; import com.yahoo.athenz.common.server.notification.impl.EmailNotificationService; public class YourNotificationServiceFactory implements NotificationServiceFactory { @Override public NotificationService create() { return new EmailNotificationService(new YourEmailProvider()); } } ``` Once the jar is ready, change the value of athenz.zms.notificationservicefactory_class in the zms.properties file to your factory class: ``` athenz.zms.notificationservicefactory_class=your.packge.YourNotificationServiceFactory ``` We can also send notifications to more than one service by specifying all service factories. For example, if we would like notifications to be sent via `your.packge.YourNotificationServiceFactory` and `their.packge.TheirNotificationServiceFactory`, specify both values in the property using `,` as a delimiter: ``` athenz.zms.notificationservicefactory_class=your.packge.YourNotificationServiceFactory, their.packge.TheirNotificationServiceFactory ```
Project: YugabyteDB (App Definition and Development / Database)
File: tscard.md

title: TSCARD linkTitle: TSCARD description: TSCARD menu: preview: parent: api-yedis weight: 2420 aliases: /preview/api/redis/tscard /preview/api/yedis/tscard type: docs `TSCARD key` This command returns the number of entires in the given time series. If the given `key` is associated with non-time series data, an error is raised. If the given `key` is not associated with any data, 0 is returned. Returns the number of entries in the given time series. ```sh $ TSADD ts_key 10 v1 20 v2 30 v3 40 v4 50 v5 ``` ``` "OK" ``` ```sh $ TSCARD ts_key ``` ``` (integer) 5 ``` ```sh $ TSADD ts_key1 10 v1 20 v2 30 v3 ``` ``` "OK" ``` ```sh $ TSCARD ts_key1 ``` ``` (integer) 3 ``` Non-existent key returns 0. ```sh $ TSCARD ts_key2 ``` ``` (integer) 0 ``` , , , , ,
Project: Curiefense (Provisioning / Security & Compliance)
File: install-OpenShift.md

Note: Be aware of the when installing Istio. To install with Helm, you must first create the namespace that you wish to install in if the namespace does not exist already. The default namespace used is `istio-system` and can be created as follows: ```console kubectl create namespace istio-system ``` The installation process using the Helm charts is as follows: 1) `base` chart creates cluster-wide CRDs, cluster bindings and cluster resources. It is possible to change the namespace from `istio-system` but it is not recommended. ```console helm install istio-base -n istio-system manifests/charts/base ``` 2) `istio-cni` chart installs the CNI plugin. This should be installed after the `base` chart and prior to `istiod` chart. Need to add `--set istio_cni.enabled=true` to the `istiod` install to enable its usage. ```console helm install istio-cni -n kube-system manifests/charts/istio-cni --set cni.cniBinDir="/var/lib/cni/bin" --set cni.cniConfDir="/etc/cni/multus/net.d" --set cni.chained=false --set cni.cniConfFileName="istio-cni.conf" --set cni.excludeNamespaces[0]="istio-system" --set cni.excludeNamespaces[1]="kube-system" --set cni.repair.enabled=false --set cni.logLevel=info ``` 3) `istio-control/istio-discovery` chart installs a revision of istiod. ```console helm install -n istio-system istio-17 manifests/charts/istio-control/istio-discovery --set istio_cni.enabled=true --set global.jwtPolicy=first-party-jwt --set sidecarInjectorWebhook.injectedAnnotations."k8s\.v1\.cni\.cncf\.io/networks"="istio-cni" ``` 4) `gateways` charts install a load balancer with `ingress` and `egress`. Ingress secrets and access should be separated from the control plane. ```console helm install -n istio-system istio-ingress manifests/charts/gateways/istio-ingress --set global.jwtPolicy=first-party-jwt ``` Egress secrets and access should be separated from the control plane. ```console helm install -n istio-system istio-egress manifests/charts/gateways/istio-egress --set global.jwtPolicy=first-party-jwt ```
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.181.md

layout: release date: 2023-11-25 tag: v0.6.181 [policy] Add Sibling Policy @theBeginner86 (#9410) [Helm] Update MeshSync chart @MUzairS15 (#9421) [Playground] Add troubleshooting steps for playground environment. @MUzairS15 (#9422) [ADDED] system model command @zakisk (#8284) fix: Prevent Manually Added Content in CLI Docs to be Overwritten @aboobakersiddiqr63 (#9125) Meshmodel Postgres & Kubernetes Component @ptdatta (#8767) Enhance dashboard UI @sudhanshutech (#9428) [Connections] - Enhancements to connections @senali-d (#9441) Fix registry models sorting @ptdatta (#9420) Analytics logo added @ritiksaxena124 (#9425) [Icon] Analytics Category @leecalcote (#9424) [UI] Fixed registry not sorting models alphabetically @Shiva953 (#9406) Add icons for whoAmI @Akshun-01 (#9329) [Connections] Status transitions @senali-d (#9405) [bug] Add missing optional chaining in Dashboard @theBeginner86 (#9411) [bug] Add missing optional chaining in Dashboard @theBeginner86 (#9411) Chore: Remove kuttl library @leecalcote (#9450) Fixed a typo @vikram-kangotra (#9447) [Server] Add `annotations` as query param to meshmodel APIs. @MUzairS15 (#9443) fix: Prevent Manually Added Content in CLI Docs to be Overwritten @aboobakersiddiqr63 (#9125) [Docs] Architecture update @leecalcote (#9419) update @leecalcote (#9417) [Docs] WASM Filter Mgmt update @leecalcote (#9416) [Docs] SMI Removal @leecalcote (#9415) [Docs] Managing Events with Notification Center @leecalcote (#9414) [Docs] Models uplift @leecalcote (#9412) Thank you to our contributors for making this release possible: @Akshun-01, @MUzairS15, @Shiva953, @aabidsofi19, @aboobakersiddiqr63, @alphaX86, @leecalcote, @ptdatta, @ritiksaxena124, @senali-d, @sudhanshutech, @theBeginner86, @vikram-kangotra and @zakisk
Project: Apache Heron (App Definition and Development / Streaming & Messaging)
File: cluster-config-stream.md

id: version-0.20.0-incubating-cluster-config-stream title: Stream Manager sidebar_label: Stream Manager original_id: cluster-config-stream <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> You can configure the [Stream Manager](heron-architecture#stream-manager) (SM) in a topology using the parameters below, including how the SM handles [back pressure](#back-pressure-parameters). Parameter | Meaning | Default :-- |:- |:- `heron.streammgr.network.backpressure.threshold` | The number of times the SM should wait to see a buffer full while enqueueing data before declaring the start of backpressure | `3` `heron.streammgr.network.backpressure.highwatermark.mb` | The high water mark on the number of megabytes that can be left outstanding on a connection | `50` `heron.streammgr.network.backpressure.lowwatermark.md` | The low water mark on the number of megabytes that can be left outstanding on a connection | `30` `heron.streammgr.network.options.maximum.packet.mb` | The maximum packet size, in megabytes, for the SM's network options | `100` Parameter | Meaning | Default :-- |:- |:- `heron.streammgr.xormgr.rotatingmap.nbuckets` | TODO | `3` Parameter | Meaning | Default :-- |:- |:- `heron.streammgr.packet.maximum.size.bytes` | Maximum size (in bytes) of packets sent out from the SM | `102400` `heron.streammgr.cache.drain.frequency.ms` | The frequency (in milliseconds) at which the SM's tuple cache is drained | `10` `heron.streammgr.cache.drain.size.mb` | The size threshold (in megabytes) at which the SM's tuple cache is drained | `100` `heron.streammgr.client.reconnect.interval.sec` | The reconnect interval to other SMs for the SM client (in seconds) | `1` `heron.streammgr.client.reconnect.tmanager.interval.sec` | The reconnect interval to the Topology Manager for the SM client (in seconds) | `10` `heron.streammgr.tmanager.heartbeat.interval.sec` | The interval (in seconds) at which a heartbeat is sent to the Topology Manager | `10` `heron.streammgr.connection.read.batch.size.mb` | The maximum batch size (in megabytes) at which the SM reads from the socket | `1` `heron.streammgr.connection.write.batch.size.mb` | The maximum batch size (in megabytes) to write by the stream manager to the socket | `1`