cwielenb/CNCF-Dataset huggingface dataset:
Project: Vitess (App Definition and Development / Database)
File: ReplicationLagBasedThrottlingOfTransactions.md

Vitess supports throttling of transactions based on replication lag. When this feature is turned on, each VTTablet primary monitors the replication lag from the replicas, and based on the observed replication lag tries to rate-limit the received transactions to keep the replication lag under a configured limit. The decision of whether to throttle a transaction is done in the `BEGIN` statement rather than in the `COMMIT` statement to avoid having a transaction perform a lot of work just to eventually be throttled and potentially rolled-back if the open-transaction timeout is exceeded. If a BEGIN statement is throttled the client receives the gRPC UNAVAILABLE error code. The following VTTablet command line flags control the replication-lag based throttler: enable-tx-throttler* A boolean flag controlling whether the replication-lag-based throttling is enabled. tx-throttler-config* A text-format representation of the protocol buffer that contains configuration options for the throttler. The most important fields in that message are target_replication_lag_sec and max_replication_lag_sec that specify the desired limits on the replication lag. See the comments in the protocol definition file for more details. If this is not specified a configuration will be used. tx-throttler-healthcheck-cells* A comma separated list of datacenter cells. The throttler will only monitor the replicas found in these cells for replication lag. tx-throttler-tablet-types* A comma separated list of tablet types. The throttler will only monitor tablets with these types. Only `replica` and/or `rdonly` types are supported. The default is `replica`. The throttler keeps trying to explore the maximum rate possible while keeping the replication lag under the desired limit; as such the desired replication lag limit may occasionally be slightly violated. Transactions are considered homogeneous. There is currently no support for specifying how `expensive` a transaction is.
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: krew_kubectl_plugins_repositories.md

Artifact Hub is able to process kubectl plugins listed in . Repositories are expected to be hosted in GitHub, GitLab or Bitbucket. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo` `https://gitlab.com/user/repo` `https://bitbucket.org/user/repo` By default the `master` branch is used, but it's possible to specify a different one from the UI. For more information about the structure of the Krew index repository, please see the official documentation. Most of the metadata Artifact Hub needs is extracted from the file. However, there is some extra Artifact Hub specific metadata that you can set using some special annotations in the `plugin manifest` file. For more information, please see the . There is an extra metadata file that you can add to your repository named , which can be used to setup features like or . This file must be located at the root of the repository.
Project: Gefyra (App Definition and Development / Application Definition & Image Build)
File: RELEASE.md

Run in the root directory `python version.py <major, minor, patch>` Commit changes with message: "chore: bump version to <SemVer>" Assign a g tag to the commit according to the semantic version that was just created (e.g. "0.6.15") Push to GitHub (don't forget to push tags, too) Draft a GitHub release based on the tag, auto-create the changelog Publish the release The rest should be automated
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: device.md

Add a host device to the <<container|pod>>. Optional permissions parameter can be used to specify device permissions by combining r for read, w for write, and m for mknod(2). Example: --device=/dev/sdc:/dev/xvdc:rwm. Note: if host-device is a symbolic link then it is resolved first. The <<container|pod>> only stores the major and minor numbers of the host device. Podman may load kernel modules required for using the specified device. The devices that Podman loads modules for when necessary are: /dev/fuse. In rootless mode, the new device is bind mounted in the container from the host rather than Podman creating it within the container space. Because the bind mount retains its SELinux label on SELinux systems, the container can get permission denied when accessing the mounted device. Modify SELinux settings to allow containers to use all device labels via the following command: $ sudo setsebool -P containerusedevices=true
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: 01-index.md

id: index title: Utility APIs sidebar_label: Overview description: Working with Utility APIs in the New Frontend System NOTE: The new frontend system is in alpha and is only supported by a small number of plugins. As described , utility APIs are pieces of shared functionality - interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves that can accept inputs, be declaratively configured in your app-config, or transparently be replaced entirely with custom implementations that fulfill the same contract. For details, . Backstage apps, plugins, and the core Backstage framework can all expose utility APIs for general use. Some are available out of the box, such as the API for reading app configuration. Some are provided by third party plugins, such as the catalog client API that both the catalog itself and your own code can leverage to talk to the catalog backend. Some, you may create yourself and make available inside your Backstage instance for use within your private ecosystem of plugins. describes the process of creating and exposing utility APIs of your own, for sharing functionality or configurability across plugins and apps. For details, . Once utility APIs are created, there are a few ways that they can be accessed to be consumed. Some utility APIs in turn depend on other utility APIs. This powerful composability lets you leverage already-written reusable pieces. In particular, you may want to rely on Backstage's framework-provided APIs e.g. for reading app configuration and many other use cases. Sometimes you request utility APIs inside your React components, e.g. for accessing i18n strings, or emitting analytics events. These are described in detail in For details, . Most utility APIs are usable directly without any configuration. But they are proper extensions, and can therefore have their implementations entirely swapped out by your app for advanced use cases. They can also be built with the ability to configured in your app-config, or to have inputs that extend their functionality. These cases are all described in . If you want to learn how to migrate your own utility APIs from the old frontend system to the new one, that's described in the .
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_fault_network_http.md

title: kbcli fault network http Intercept HTTP requests and responses. ``` -h, --help help for http ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "$HOME/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use ``` - Network chaos. - Abort the HTTP request and response. - Delay the HTTP request and response. - Patch the HTTP request and response. - Replace the HTTP request and response.
Project: Shifu (Provisioning / Automation & Configuration)
File: CHANGELOG-v0.11.0.md

deviceShifu TCP by @FFFFFaraway in https://github.com/Edgenesis/shifu/pull/466 <BugFix>fix field value by @Vacant2333 in https://github.com/Edgenesis/shifu/pull/479 add device name to http header by @geraldkohn in https://github.com/Edgenesis/shifu/pull/470 rebase changes from v0.10.0 to main by @tomqin93 in https://github.com/Edgenesis/shifu/pull/473 Update README-zh.md by @rachelzhang0922 in https://github.com/Edgenesis/shifu/pull/477 update README: capitalization by @QingZ11 in https://github.com/Edgenesis/shifu/pull/478 update indentation for README by @tomqin93 in https://github.com/Edgenesis/shifu/pull/481 add TCP deviceShifu into build pipeline by @tomqin93 in https://github.com/Edgenesis/shifu/pull/483 fix a typo for telemetryService's image tag by @tomqin93 in https://github.com/Edgenesis/shifu/pull/485 @geraldkohn made their first contribution in https://github.com/Edgenesis/shifu/pull/470 @QingZ11 made their first contribution in https://github.com/Edgenesis/shifu/pull/478 Bump k8s.io/api from 0.26.0 to 0.26.1 by @dependabot in https://github.com/Edgenesis/shifu/pull/467 Bump k8s.io/apimachinery from 0.26.0 to 0.26.1 by @dependabot in https://github.com/Edgenesis/shifu/pull/468 Bump k8s.io/client-go from 0.26.0 to 0.26.1 by @dependabot in https://github.com/Edgenesis/shifu/pull/469 Bump github.com/onsi/gomega from 1.24.2 to 1.26.0 by @dependabot in https://github.com/Edgenesis/shifu/pull/474 Bump github.com/gopcua/opcua from 0.3.9 to 0.3.10 by @dependabot in https://github.com/Edgenesis/shifu/pull/475 Bump sigs.k8s.io/controller-runtime from 0.14.1 to 0.14.2 by @dependabot in https://github.com/Edgenesis/shifu/pull/476 Full Changelog: https://github.com/Edgenesis/shifu/compare/v0.10.0...v0.11.0
Project: YugabyteDB (App Definition and Development / Database)
File: txn_lock.md

title: LOCK statement [YSQL] headerTitle: LOCK linkTitle: LOCK description: Use the LOCK statement to lock a table. menu: v2.18: identifier: txn_lock parent: statements type: docs Use the `LOCK` statement to lock a table. {{%ebnf%}} lock_table, lockmode {{%/ebnf%}} {{< note title="Table inheritance is not yet supported" >}} The rule specifies syntax that is useful only when at least one other table inherits one of the tables that the `truncate` statement lists explicitly. See for more detail. Until inheritance is supported, use a bare . {{< /note >}} Specify a table to lock. Only `ACCESS SHARE` lock mode is supported at this time. All other modes listed in lockmode are under development. ``` ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE ```
Project: Falco (Provisioning / Security & Compliance)
File: README.md

Under `unittests/engine` and `unittests/falco` directories, we have different test suites that could be a single file or an entire directory according to the number and the complexity of tests. ```bash cmake -DMINIMALBUILD=On -DBUILDBPF=Off -DBUILDDRIVER=Off -DBUILDFALCOUNITTESTS=On .. make falcounittests sudo ./unittests/falcounit_tests ```
Project: StarRocks (App Definition and Development / Database)
File: timestampdiff.md

displayed_sidebar: "English" Returns the interval from `datetimeexpr2` to `datetimeexpr1`. `datetimeexpr1` and `datetimeexpr2` must be of the DATE or DATETIME type. The unit for the integer result and the interval should be one of the following: MILLISECOND (since 3.2), SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, or YEAR. ```Haskell INT TIMESTAMPDIFF(unit,DATETIME datetimeexpr1, DATETIME datetimeexpr2) ``` `datetime_expr`: the two DATE or DATETIME expressions you want to compare. `unit`: the unit of the time difference. Supported units include MILLISECOND (since 3.2), SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, and YEAR. Returns an INT value. ```plain text MySQL> SELECT TIMESTAMPDIFF(MONTH,'2003-02-01','2003-05-01'); +--+ | timestampdiff(MONTH, '2003-02-01 00:00:00', '2003-05-01 00:00:00') | +--+ | 3 | +--+ MySQL> SELECT TIMESTAMPDIFF(YEAR,'2002-05-01','2001-01-01'); +-+ | timestampdiff(YEAR, '2002-05-01 00:00:00', '2001-01-01 00:00:00') | +-+ | -1 | +-+ MySQL> SELECT TIMESTAMPDIFF(MINUTE,'2003-02-01','2003-05-01 12:05:55'); ++ | timestampdiff(MINUTE, '2003-02-01 00:00:00', '2003-05-01 12:05:55') | ++ | 128885 | ++ MySQL > SELECT TIMESTAMPDIFF(MILLISECOND,'2003-02-01','2003-05-01'); +--+ | timestampdiff(MILLISECOND, '2003-02-01', '2003-05-01') | +--+ | 7689600000 | +--+ ``` TIMESTAMPDIFF
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: v1.17.0.md

title: v1.17.0 weight: 998983000 Upgrade controller-runtime from `0.10.0` to `0.11.0`, k8s from `1.22` to `1.23` and controller-gen from `v0.0.7` to `v0.8.0`. Following the steps to update your project. 1) Update the go.mod file with: ``` go 1.17 require ( github.com/onsi/ginkgo v1.16.5 github.com/onsi/gomega v1.17.0 k8s.io/api v0.23.0 k8s.io/apimachinery v0.23.0 k8s.io/client-go v0.23.0 sigs.k8s.io/controller-runtime v0.11.0 ) ``` 2) Run `go mod tidy` Now, let's update the Makefile targets accordingly: 1) Replace `ENVTESTK8SVERSION = 1.22` with `ENVTESTK8SVERSION = 1.23` 2) Replace `sigs.k8s.io/controller-tools/cmd/controller-gen@v0.7.0` with `sigs.k8s.io/controller-tools/cmd/controller-gen@v0.8.0` 3) Run `make manifests` and `make generate` to ensure that you will update your manifests with the new versions 4) You might want to run `make all` to ensure that all updates were done accordinly and succeffully See for more details. Update the file `config/default/managerauthproxy_patch.yaml` by replacing `"--v=10"` with `"--v=0"` See for more details. Update the file `config/default/managerauthproxy_patch.yaml` by adding: ``` ... resources: limits: cpu: 500m memory: 128Mi requests: cpu: 5m memory: 64Mi ``` See for more details.
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: kubewarden_policies_repositories.md

Kubewarden policies repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path/to/packages provided can contain metadata for one or more packages. Each package version must be on a separate folder, and it's up to you to decide if you want to publish one or multiple versions of your package. The structure of a repository with multiple policies packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml 2.0.0 README.md artifacthub-pkg.yml package2 1.0.0 README.md artifacthub-pkg.yml ``` This structure is flexible, and in some cases it can be greatly simplified. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file and the for more details. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. The allows defining containers images. Kubewarden policies packages are required to provide an image named `policy` that points to the image containing the policy. Packages can optionally provide an alternative location for the policy image by defining a second image named `policy-alternative-location`. Artifact Hub will check if the images provided have been signed with `cosign` and will consider the package to be signed when all images are signed. Once you have added your repository, you are all set up. As you add new versions of your policies packages or even new packages to your git repository, they'll be automatically indexed and listed in Artifact Hub. The following repositories can be used as a reference: <https://github.com/kubewarden/allowed-fsgroups-psp-policy> <https://github.com/kubewarden/allow-privilege-escalation-psp-policy>
Project: Kubescape (Provisioning / Security & Compliance)
File: ADOPTERS.md

List of well-known companies who are publicly acknowledge using and/or contributing to Kubescape are (in alphabetical order): AWS uses Kubescape in the security training material Energi Danmark: Publicly talking about how they use Kubescape in their CI/CD pipeline Gitpod: Used Kubescape in their SOC2 compliance process Intel: using Kubescape for security prioritization Orange Business: talking about Kubescape/ARMO service they are doing Rabobank: talked at KCD Amsterdam about having Kubescape in their technology stack VMWare/Bitnami: listing Kubescape in their public image/helm repository If you want to be listed here and share with others your experience, open a PR and add the bellow table: | Name | Company | Use case | Contact for questions (optional) | | - | - | -- | -- | | Yonathan Amzallag | ARMO | Vulnerability monitoring | yonatana@armosec.io | | Engin Diri | Schwarz IT (SIT) | Ensure continuous compliance for edge k8s cluster | engin.diri@mail.schwarz | | Idan Bidani | Cox Communications | Security analysis for k8s best practices in CI pipelines of 3,000 applications | idan.bidani@cox.com |
Project: Chef InSpec (Provisioning / Security & Compliance)
File: limits_conf.md

+++ title = "limits_conf resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "limits_conf" identifier = "inspec/resources/os/limitsconf.md limitsconf resource" parent = "inspec/resources/os" +++ Use the `limits_conf` Chef InSpec audit resource to test configuration settings in the `/etc/security/limits.conf` file. The `limits.conf` defines limits for processes (by user and/or group names) and helps ensure that the system running those processes remains stable. Each process may be assigned a hard or soft limit. Soft limits are maintained by the shell and defines the number of file handles (or open files) available to the user or group after login Hard limits are maintained by the kernel and defines the maximum number of allowed file handles Entries in the `limits.conf` file are similar to: grantmc soft nofile 4096 grantmc hard nofile 63536 ^^^^^^^^^ ^^^^ ^^^^^^ ^^^^^ domain type item value {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `limits_conf` resource block declares a domain to be tested, along with associated type, item, and value: describe limits_conf('path') do its('domain') { should include ['type', 'item', 'value'] } its('domain') { should eq ['type', 'item', 'value'] } end where `('path')` is the non-default path to the `inetd.conf` file `'domain'` is a user or group name, such as `grantmc` `'type'` is either `hard` or `soft` `'item'` is the item for which limits are defined, such as `core`, `nofile`, `stack`, `nproc`, `priority`, or `maxlogins` `'value'` is the value associated with the `item` The `domain` property tests the domain in the `limits.conf` file, along with associated type, item, and value: its('domain') { should include ['type', 'item', 'value'] } For example: its('grantmc') { should include ['hard', 'nofile', '63536'] } describe limits_conf('path') do its('*') { should include ['soft', 'core', '0'], ['hard', 'rss', '10000'] } its('ftp') { should eq ['hard', 'nproc', '0'] } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: KICS (Provisioning / Security & Compliance)
File: af96d737-0818-4162-8c41-40d969bd65d1.md

title: CMK Rotation Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: af96d737-0818-4162-8c41-40d969bd65d1 Query name: CMK Rotation Disabled Platform: Ansible Severity: <span style="color:#edd57e">Low</span> Category: Observability URL: Customer Master Keys (CMK) must have rotation enabled, which means the attribute 'enablekeyrotation' must be set to 'true' when the key is enabled.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="2" name: Update IAM policy on an existing KMS key community.aws.aws_kms: alias: my-kms-key policy: '{"Version": "2012-10-17", "Id": "my-kms-key-permissions", "Statement": [ { <SOME STATEMENT> } ]}' state: present enabled: true ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="7" name: Update IAM policy on an existing KMS key2 community.aws.aws_kms: alias: my-kms-key policy: '{"Version": "2012-10-17", "Id": "my-kms-key-permissions", "Statement": [ { <SOME STATEMENT> } ]}' state: present enabled: true enablekeyrotation: false ``` ```yaml title="Negative test num. 1 - yaml file" name: Update IAM policy on an existing KMS key3 community.aws.aws_kms: alias: my-kms-key policy: '{"Version": "2012-10-17", "Id": "my-kms-key-permissions", "Statement": [ { <SOME STATEMENT> } ]}' state: present enabled: true enablekeyrotation: true ```
Project: YugabyteDB (App Definition and Development / Database)
File: RELEASING.md

Publishing a new Release =============================================================================== [ ] Check that all* CI jobs run without errors on the `master` branch [ ] Close all remaining issues on the current milestone [ ] Update the [Changelog] [ ] Write the announcement in [NEWS.md] [ ] Rebuild the docker image and upload it (`make dockerimage dockerpush`) [ ] Upload the zipball to PGXN [ ] Check the PGXN install process [ ] Close the current milsetone and open the next one [ ] Rebase the `stable` branch from `master` [ ] Tag the master branch [ ] Open a ticket to the [PostgreSQL YUM repository project] [ ] Bump to the new version number in [anon.control] and [META.json] [ ] Publish the announcement