cwielenb/CNCF-Dataset huggingface dataset:
Project: Cadence Workflow (Provisioning / Automation & Configuration)
File: roadmap.md

The following is a high-level quarterly roadmap of the project. Scalable tasklist MySQL support Workflow history archival Workflow visibility archival Postgres SQL support Service availability and reliability improvements Graceful domain failover design UI bug fixes and performance improvements Kafka deprecation for Cadence replication Graceful domain failover Multi-tenancy task prioritization and resource isolation UI and CLI feature parity GRPC support Parent-child affinity Task priority Reset 2.0 (more flexibility and handle child) Safe workflow code rollout
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_organization_iam_binding.md

+++ title = "googleorganizationiam_binding resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleorganizationiam_binding" identifier = "inspec/resources/gcp/googleorganizationiambinding.md googleorganizationiambinding resource" parent = "inspec/resources/gcp" +++ A `googleorganizationiam_binding` is used to test a Google Organization Iam Bindings ```ruby describe googleorganizationiam_binding(name: "name", role: "roles/editor") do it { should exist } its('members') { should include 'user:testuser@example.com' } end ``` Properties that can be accessed from the `googleorganizationiam_binding` resource: `role` : Role that is assigned to members. For example, roles/viewer, roles/editor, or roles/owner. `members` : Specifies the identities requesting access for a Cloud Platform resource. Ensure the is enabled for the current project.
Project: KICS (Provisioning / Security & Compliance)
File: 3fa5900f-9aac-4982-96b2-a6143d9c99fb.md

title: Role Definition Allows Custom Role Creation hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 3fa5900f-9aac-4982-96b2-a6143d9c99fb Query name: Role Definition Allows Custom Role Creation Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Role Definition should not allow custom role creation (Microsoft.Authorization/roleDefinitions/write)<br> ```tf title="Positive test num. 1 - tf file" hl_lines="7" resource "azurermroledefinition" "example2" { roledefinitionid = "00000000-0000-0000-0000-000000000000" name = "my-custom-role-definition" scope = data.azurerm_subscription.primary.id permissions { actions = ["Microsoft.Authorization/roleDefinitions/write"] not_actions = [] } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="7" resource "azurermroledefinition" "example" { name = "my-custom-role" scope = data.azurerm_subscription.primary.id description = "This is a custom role created via Terraform" permissions { actions = ["*"] not_actions = [] } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermroledefinition" "example3" { roledefinitionid = "00000000-0000-0000-0000-000000000000" name = "my-custom-role-definition" scope = data.azurerm_subscription.primary.id permissions { actions = ["Microsoft.Authorization/roleDefinitions/read"] not_actions = [] } } ```
Project: KICS (Provisioning / Security & Compliance)
File: e0099af2-fe17-411f-9991-0de28fe15f3c.md

title: Event Rate Limit Admission Control Plugin Not Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e0099af2-fe17-411f-9991-0de28fe15f3c Query name: Event Rate Limit Admission Control Plugin Not Set Platform: Kubernetes Severity: <span style="color:#edd57e">Low</span> Category: Availability URL: When using kube-apiserver command, the --enable-admission-plugins flag should have 'EventRateLimit' plugin and the plugin should be correctly configured in AdmissionControl Config file<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--enable-admission-plugins=AlwaysAdmit"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--enable-admission-plugins=EventRateLimit", "--admission-control-config-file=path/to/plugin/config/file.yaml"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver","--enable-admission-plugins=EventRateLimit", "--admission-control-config-file=path/to/plugin/config/file.yaml"] args: [] restartPolicy: OnFailure ```
Project: Trivy (Provisioning / Security & Compliance)
File: rust.md

Trivy supports , which is the Rust package manager. The following scanners are supported for Cargo. | Package manager | SBOM | Vulnerability | License | | | :: | :--: | :--: | | Cargo | | | - | In addition, it supports binaries built with . | Artifact | SBOM | Vulnerability | License | | -- | :: | :--: | :--: | | Binaries | | | - | The following table provides an outline of the features Trivy offers. | Package manager | File | Transitive dependencies | Dev dependencies | | Position | |--||:--:|:--|::|:--:| | Cargo | Cargo.lock | | Excluded[^1] | | | | Artifact | Transitive dependencies | Dev dependencies | Dependency graph | Position | | -- | :: | : | :--: | :: | | Binaries | | Excluded | - | - | Trivy searches for `Cargo.lock` to detect dependencies. Trivy also supports dependency trees; however, to display an accurate tree, it needs to know whether each package is a direct dependency of the project. Since this information is not included in `Cargo.lock`, Trivy parses `Cargo.toml`, which should be located next to `Cargo.lock`. If you want to see the dependency tree, please ensure that `Cargo.toml` is present. Scan `Cargo.lock` and `Cargo.toml` together also removes developer dependencies. Trivy scans binaries built with . If such a binary exists, Trivy will identify it as being built with cargo-audit and scan it.
Project: YugabyteDB (App Definition and Development / Database)
File: retool.md

title: Use Retool with YugabyteDB YSQL headerTitle: Retool linkTitle: Retool description: Use Retool to work with distributed SQL databases in YugabyteDB. menu: preview_integrations: identifier: retool parent: development-platforms weight: 910 type: docs is a service for creating internal tools powered by your data. It provides the ability to connect and query your data sources in order to build rich user interfaces. Retool provides support for multiple data sources, including PostgreSQL. Because YugabyteDB is PostgreSQL-compatible, Retool can connect to YugabyteDB as a PostgreSQL resource. Your YugabyteDB cluster should be up and running. Refer to . To connect to YugabyteDB, create a new PostgreSQL resource in Retool as follows: Supply a name for your resource. Add the host address of your YugabyteDB instance. Change the port from `5432` to `5433`. Change the database name to that of your YugabyteDB instance. Provide the password for your YugabyteDB instance. Optionally, to connect via SSL, provide the CA certificate. If your cluster is in YugabteDB Managed, be sure to add the listed IP addresses to the cluster . With a valid PostgreSQL resource, you can now query your YugabyteDB instance in Retool.
Project: Pachyderm (App Definition and Development / Streaming & Messaging)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: '' <!-- This form is for bug reports ONLY! If you're looking for help, please check: Docs: https://docs.pachyderm.com/latest/ Slack: http://slack.pachyderm.io/ --> What happened?: What you expected to happen?: How to reproduce it (as minimally and precisely as possible)?: Anything else we need to know?: Environment?: Kubernetes version (use `kubectl version`): Pachyderm CLI and pachd server version (use `pachctl version`): Cloud provider (e.g. aws, azure, gke) or local deployment (e.g. minikube vs dockerized k8s): If you deployed with helm, the values you used (`helm get values pachyderm`): OS (e.g. from /etc/os-release): Others:
Project: kaniko (App Definition and Development / Application Definition & Image Build)
File: EXTENDING.md

`go-git` was built in a highly extensible manner, which enables some of its functionalities to be changed or extended without the need of changing its codebase. Here are the key extensibility features: Dot git storers are the components responsible for storing the Git internal files, including objects and references. The built-in storer implementations include and . The `memory` storer stores all the data in memory, and its use look like this: ```go r, err := git.Init(memory.NewStorage(), nil) ``` The `filesystem` storer stores the data in the OS filesystem, and can be used as follows: ```go r, err := git.Init(filesystem.NewStorage(osfs.New("/tmp/foo")), nil) ``` New implementations can be created by implementing the . Git repository worktrees are managed using a filesystem abstraction based on . The Git operations will take place against the specific filesystem implementation. Initialising a repository in Memory can be done as follows: ```go fs := memfs.New() r, err := git.Init(memory.NewStorage(), fs) ``` The same operation can be done against the OS filesystem: ```go fs := osfs.New("/tmp/foo") r, err := git.Init(memory.NewStorage(), fs) ``` New filesystems (e.g. cloud based storage) could be created by implementing `go-billy`'s . Git supports various transport schemes, including `http`, `https`, `ssh`, `git`, `file`. `go-git` defines the to represent them. The built-in implementations can be replaced by calling `client.InstallProtocol`. An example of changing the built-in `https` implementation to skip TLS could look like this: ```go customClient := &http.Client{ Transport: &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, }, } client.InstallProtocol("https", githttp.NewClient(customClient)) ``` Some internal implementations enables code reuse amongst the different transport implementations. Some of these may be made public in the future (e.g. `plumbing/transport/internal/common`). Several different operations across `go-git` lean on caching of objects in order to achieve optimal performance. The caching functionality is defined by the . Two built-in implementations are `cache.ObjectLRU` and `cache.BufferLRU`. However, the caching functionality can be customized by implementing the interface `cache.Object` interface. `go-git` uses the `crypto.Hash` interface to represent hash functions. The built-in implementations are `github.com/pjbgf/sha1cd` for SHA1 and Go's `crypto/SHA256`. The default hash functions can be changed by calling `hash.RegisterHash`. ```go func init() { hash.RegisterHash(crypto.SHA1, sha1.New) } ``` New `SHA1` or `SHA256` hash functions that implement the `hash.RegisterHash` interface can be registered by calling `RegisterHash`.
Project: StarRocks (App Definition and Development / Database)
File: array_remove.md

displayed_sidebar: "English" Removes an element from an array. ```Haskell arrayremove(anyarray, any_element) ``` `any_array`: the array to be searched. `any_element`: an expression that matches the element in an array. Returns the array from which specified element has been removed. ```plaintext mysql> select array_remove([1,2,3,null,3], 3); ++ | array_remove([1,2,3,NULL,3], 3) | ++ | [1,2,null] | ++ 1 row in set (0.01 sec) ``` ARRAY_REMOVE, ARRAY
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-machine-ssh.1.md

% podman-machine-ssh 1 podman\-machine\-ssh - SSH into a virtual machine podman machine ssh [options] [name] [command [arg ...]] SSH into a Podman-managed virtual machine and optionally execute a command on the virtual machine. Unless using the default virtual machine, the first argument must be the virtual machine name. The optional command to execute can then follow. If no command is provided, an interactive session with the virtual machine is established. The exit code from ssh command is forwarded to the podman machine ssh caller, see . The default machine name is `podman-machine-default`. If a machine name is not specified as an argument, then `podman-machine-default` will be SSH'd into. Rootless only. Print usage statement. Username to use when SSH-ing into the VM. The exit code from `podman machine ssh` gives information about why the command failed. When `podman machine ssh` commands exit with a non-zero code, the exit codes follow the `chroot` standard, see below: 125 The error is with podman _itself_ $ podman machine ssh --foo; echo $? Error: unknown flag: --foo 125 126 Executing a contained command and the command cannot be invoked $ podman machine ssh /etc; echo $? Error: fork/exec /etc: permission denied 126 127 Executing a contained command and the command cannot be found $ podman machine ssh foo; echo $? Error: fork/exec /usr/bin/bogus: no such file or directory 127 Exit code contained command exit code $ podman machine ssh /bin/sh -c 'exit 3'; echo $? 3 To get an interactive session with the default Podman machine: SSH into the default Podman machine. ``` $ podman machine ssh ``` Run command inside the default Podman machine via ssh. ``` $ podman machine ssh myvm ``` Run command inside the specified Podman machine via ssh. ``` $ podman machine ssh myvm rpm -q podman ``` , March 2021, Originally compiled by Ashley Cui <acui@redhat.com>
Project: RBAC Manager (Provisioning / Security & Compliance)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: [triage, enhancement] assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Confidential Containers (Provisioning / Security & Compliance)
File: enclave-cc.md

`enclave-cc` provides process-based isolation using SGX. This guide assumes that you already have a Kubernetes cluster and have deployed the operator as described in the Installation section of the . Note Before configuring KBC, please refer to the to deploy KBS cluster. Note The KBC configuration changes to the enclave-cc custom resource yaml must be made before deploying it. Enclave CC supports cc-kbc and sample-kbc, in order to use them, users will have to properly configure a `decryptconfig.conf`, in order to set the `KBC` (`cckbc` or `samplekbc`) `IP`,`PORT`, and the `SECURITYVALIDATE` (`false` or `true`). ```json { "key_provider": "provider:attestation-agent:KBC::IP:PORT", "securityvalidate": SECURITYVALIDATE } ``` The following is an example of `cc_kbc`: ```json { "keyprovider": "provider:attestation-agent:cckbc::http://127.0.0.1:8080", "security_validate": true } ``` The following is an example of `sample_kbc`: ```json { "keyprovider": "provider:attestation-agent:samplekbc::127.0.0.1:50000", "security_validate": false } ``` Once that's set according to the users needs, the user will then have to run: `cat decrypt_config.conf | base64 -w 0` in order to get the data encoded and set it accordingly . As an example, we setup a sample hello world workload with an encrypted and cosign signed container image using the `enclave-cc` runtime class for process based TEEs. This encrypted image is only used for testing. If you want to use it in your own production use cases, please refer to the to create a new encrypted image and deploy it. The deployment below assumes the hardware SGX mode build is installed by the operator. To try on a non-TEE system, please use simulate SGX mode build. The example uses a trivial hello world C application: ```yaml apiVersion: v1 kind: Pod metadata: name: enclave-cc-pod spec: containers: image: ghcr.io/confidential-containers/test-container-enclave-cc:encrypted name: hello-world workingDir: "/run/rune/boot_instance/" resources: limits: sgx.intel.com/epc: 600Mi env: name: OCCLUMRELEASEENCLAVE value: "1" command: /run/rune/boot_instance/build/bin/occlum-run /bin/hello_world runtimeClassName: enclave-cc ``` Note When the hardware SGX mode payload is used in an SGX enabled cluster, `sgx.intel.com/epc: 600Mi` resource request must be added to the pod spec. Again, create a pod YAML file as previously described (this time we named it `enclave-cc-pod.yaml`) . Create the workload: ```sh kubectl apply -f enclave-cc-pod.yaml ``` Output: ``` pod/enclave-cc-pod created ``` Ensure the pod was created successfully (in running state): ```sh kubectl get pods ``` Output: ``` NAME READY STATUS RESTARTS AGE enclave-cc-pod 1/1 Running 0 22s ``` Check the pod is running as expected: ```sh kubectl logs enclave-cc-pod | head -5 ``` Output: ``` ["init"] Hello world! Hello world! ``` We can also verify the host does not have the image for others to use: ```sh crictl -r unix:///run/containerd/containerd.sock image ls | grep helloworld_enc ```
Project: YugabyteDB (App Definition and Development / Database)
File: failed_tablets.md

title: Recover YB-TServer from crash loop linkTitle: Recover YB-TServer from crash loop description: Recover YB-TServer from crash loop menu: preview: parent: troubleshoot-cluster weight: 866 type: docs When a YB-TServer process or node has failed, YugabyteDB automatically triggers a remote bootstrap for most types of tablet data corruption or failures. However, in some cases the automatic bootstrap may not solve the problem, resulting in a crash loop. This can happen when a condition leads to a code path encoded as a crash (for example, `CHECK` or `FATAL`) or when the cause of a crash is unknown (for example, code errors that lead to `SIGSEGV`). In all of these cases, the root cause would likely repeat itself when the process is restarted. Moreover, when using YugabyteDB Anywhere, crashed processes are automatically restarted to ensure minimum downtime. Since servers stuck in a crash loop typically cannot stay up long enough to be safely issued runtime commands against them, manual intervention by the administrator is required to bring a YB-TServer back to a healthy state. To do this, the administrator needs to find all the faulty tablets, look for their data on disk (possibly spread across multiple disks, depending on your `fsdatadirs`), and then remove it. The following are the steps to address this scenario: Stop the YB-TServer process to prevent new restarts during operations. For YugabyteDB Anywhere, execute the `yb-server-ctl tserver stop` command. Find the tablets that are encountering these problems. You may to get the UUID of tablets. In the described scenario, the UUID of the tablet is `FOO` and the `--fsdatadirs` flag is `/mnt/disk1`. Find and remove all the tablet files, as follows: ```bash find /mnt/disk1 -name 'FOO' | xargs rm -rf ``` Repeat the preceding command for each disk in `--fsdatadirs`. Restart the YB-TServer process. In YugabyteDB Anywhere, execute the `yb-server-ctl tserver start` command. When completed, the YB-TServer should be able to start, stay alive, and rejoin the cluster, while the centralized load balancer re-replicates or redistributes copies of any affected tablets.
Project: Stolon (App Definition and Development / Database)
File: stolonctl.md

`stolonctl` is the stolon client which controls the stolon cluster(s). Since `stolonctl`needs to communicate with the cluster backend store, it requires providing the requested cluster name (`--cluster-name`), its store backend type (`--store-backend`), and how to reach the store, such as: For etcdv2, etcdv3 or consul as store, a comma separated list of endpoints (`--store-endpoints`). For kubernetes as store, the kind of kubernetes resources (`--kube-resource-kind`). See below. `stolonctl` example for checking the status of a cluster named "stolon-cluster" using "etcdv3" as a store backend: ``` $ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379,http://etcd-1:2379,http://etcd-2:2379 status ``` Note: To avoid repeating the arguments on every command (or inside scripts), all the options can be exported as environment variables. Their name will be the same as the option name converted in uppercase, with `` replacing `-` and prefixed with `STOLONCTL`. For example: ``` STOLONCTLSTOREBACKEND STOLONCTLSTOREENDPOINTS STOLONCTLCLUSTERNAME ``` `stolonctl` behaves like when choosing how to access the kubernetes API server(s): When run inside a pod it uses the pod service account to connect to the k8s API servers. When run externally it honors the $KUBECONFIG environment variable to connect. It is thus possible to use the default `~/.kube/config` file or an overriden kube-config file path, context and namespace to set the `stolonctl` options `--kubeconfig`, `--kube-context` and `--kube-namespace`. `stolonctl` example for checking the status of a cluster named "kube-stolon" using "kubernetes" as a store backend and "configmap" as the resource kind where the `stolonctl` command is invoked via one of the stolon proxy pods: ``` $kubectl exec -i -t stolon-proxy-669f7b54fd-9psm2 -- stolonctl --cluster-name=kube-stolon --store-backend=kubernetes --kube-resource-kind=configmap status ``` Same `stolonctl` command as a one shot: ``` kubectl run -i -t stolonctl --image=sorintlab/stolon:master-pg9.6 --restart=Never --rm -- /usr/local/bin/stolonctl --cluster-name=kube-stolon --store-backend=kubernetes --kube-resource-kind=configmap status ```
Project: TDengine (App Definition and Development / Database)
File: 13-tmq.md

title: Data Subscription SQL Reference sidebar_label: Data Subscription description: This document describes the SQL statements related to the data subscription component of TDengine. The information in this document is related to the TDengine data subscription feature. ```sql CREATE TOPIC [IF NOT EXISTS] topic_name AS subquery; ``` You can use filtering, scalar functions, and user-defined scalar functions with a topic. JOIN, GROUP BY, windows, aggregate functions, and user-defined aggregate functions are not supported. The following rules apply to subscribing to a column: The returned field is determined when the topic is created. Columns to which a consumer is subscribed or that are involved in calculations cannot be deleted or modified. If you add a column, the new column will not appear in the results for the subscription. If you run `SELECT \*`, all columns in the subscription at the time of its creation are displayed. This includes columns in supertables, standard tables, and subtables. Supertables are shown as data columns plus tag columns. ```sql DROP TOPIC [IF EXISTS] topic_name; ``` If a consumer is subscribed to the topic that you delete, the consumer will receive an error. ```sql SHOW TOPICS; ``` The preceding command displays all topics in the current database. You can create consumer groups only through the TDengine Client driver or the API provided by a client library. ```sql DROP CONSUMER GROUP [IF EXISTS] cgroupname ON topicname; ``` This deletes the cgroupname in the topicname. ```sql SHOW CONSUMERS; ``` The preceding command displays all consumer groups in the current database.