cwielenb/CNCF-Dataset huggingface dataset:
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_kubeblocks_preflight.md

title: kbcli kubeblocks preflight Run and retrieve preflight checks for KubeBlocks. ``` kbcli kubeblocks preflight [flags] ``` ``` kbcli kubeblocks preflight kbcli kubeblocks preflight --verbose kbcli kubeblocks preflight preflight-check.yaml kbcli kubeblocks preflight preflight-check.yaml --interactive=true ``` ``` --collect-without-permissions always run preflight checks even if some required permissions that preflight does not have (default true) --collector-image string the full name of the collector image to use --collector-pullpolicy string the pull policy of the collector image --debug enable debug logging --format string output format, one of json, yaml. only used when interactive is set to false, default format is yaml (default "yaml") -h, --help help for preflight -n, --namespace string If present, the namespace scope for this CLI request -o, --output string specify the output file path for the preflight checks --selector string selector (label query) to filter remote collection nodes on. --since string force pod logs collectors to return logs newer than a relative duration like 5s, 2m, or 3h. --since-time string force pod logs collectors to return logs after a specific date (RFC3339) --verbose print more verbose logs, default value is false ``` ``` --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 --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 ``` - KubeBlocks operation commands.
Project: RBAC Lookup (Provisioning / Security & Compliance)
File: code-of-conduct.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [INSERT EMAIL ADDRESS]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Trivy (Provisioning / Security & Compliance)
File: trivy_module.md

Manage modules ``` --enable-modules strings [EXPERIMENTAL] module names to enable -h, --help help for module --module-dir string specify directory to the wasm modules that will be loaded (default "$HOME/.trivy/modules") ``` ``` --cache-dir string cache directory (default "/path/to/cache") -c, --config string config path (default "trivy.yaml") -d, --debug debug mode --generate-default-config write the default config to trivy-default.yaml --insecure allow insecure server connections -q, --quiet suppress progress bar and log output --timeout duration timeout (default 5m0s) -v, --version show version ``` - Unified security scanner - Install a module - Uninstall a module
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: deploy.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: deploy-workflowstep namespace: examples spec: components: name: nginx-deploy-workflowstep type: webservice properties: image: nginx policies: name: topology-hangzhou-clusters type: topology properties: clusterLabelSelector: region: hangzhou name: topology-local type: topology properties: clusters: ["local"] namespace: examples-alternative workflow: steps: type: deploy name: deploy-local properties: policies: ["topology-local"] type: deploy name: deploy-hangzhou properties: auto: false policies: ["topology-hangzhou-clusters"] ```
Project: KICS (Provisioning / Security & Compliance)
File: 3790d386-be81-4dcf-9850-eaa7df6c10d9.md

title: PostgreSQL Log Checkpoints Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 3790d386-be81-4dcf-9850-eaa7df6c10d9 Query name: PostgreSQL Log Checkpoints Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Make sure that for Postgre SQL Database Server, parameter 'log_checkpoints' is set to 'ON'<br> ```tf title="Positive test num. 1 - tf file" hl_lines="19 12 5" resource "azurermpostgresqlconfiguration" "positive1" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "off" } resource "azurermpostgresqlconfiguration" "positive2" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "Off" } resource "azurermpostgresqlconfiguration" "positive3" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "OFF" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermpostgresqlconfiguration" "negative1" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "on" } resource "azurermpostgresqlconfiguration" "negative2" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "On" } resource "azurermpostgresqlconfiguration" "negative3" { name = "log_checkpoints" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "ON" } ```
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: init-containers.md

can be provided for all the types of vertices. The following example shows how to add an init-container to a `udf` vertex. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: vertices: name: my-udf initContainers: name: my-init image: busybox:latest command: ["/bin/sh", "-c", "echo \"my-init is running!\" && sleep 60"] udf: container: image: my-function:latest ``` The following example shows how to use init-containers and together to provide a `udf` container files on startup. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: vertices: name: my-udf volumes: name: my-udf-data emptyDir: {} initContainers: name: my-init image: amazon/aws-cli:latest command: ["/bin/sh", "-c", "aws s3 sync s3://path/to/my-s3-data /path/to/my-init-data"] volumeMounts: mountPath: /path/to/my-init-data name: my-udf-data udf: container: image: my-function:latest volumeMounts: mountPath: /path/to/my-data name: my-udf-data ```
Project: ClickHouse (App Definition and Development / Database)
File: v21.6.8.62-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix sharding_key from column w/o function for remote() (before `select from remote('127.1', system.one, dummy)` leads to `Unknown column: dummy, there are only columns .` error). (). Backported in : Fix rare server crash because of `abort` in ZooKeeper client. Fixes . (). Backported in : Fix `joinGet` with LowCarinality columns, close . (). Backported in : Fix potential crash if more than one `untuple` expression is used. (). Backported in : Remove excessive newline in `threadname` column in `system.stacktrace` table. This fixes . (). Manual backport of in 21.6 ().
Project: ArangoDB (App Definition and Development / Database)
File: disabling_implicit_constructor.md

+++ title = "`basic_result(X &&) = delete`" description = "Disabling implicit constructor used to give useful diagnostic error when trying to use implicit constructors when `predicate::implicitconstructorsenabled` is false." categories = ["constructors", "disabling-constructors"] weight = 170 +++ Disabling implicit constructor used to give useful diagnostic error when trying to use implicit constructors when `predicate::implicitconstructorsenabled` is false. Requires: `predicate::implicitconstructorsenabled` is false. Complexity: N/A.
Project: Checkov (Provisioning / Security & Compliance)
File: argo_workflows.md

layout: default title: argo_workflows resource scans nav_order: 1 | | Id | Type | Entity | Policy | IaC | Resource Link | |-||-|-||-|--| | 0 | CKVARGO1 | argo_workflows | spec | Ensure Workflow pods are not using the default ServiceAccount | Argo Workflows | | | 1 | CKVARGO2 | argo_workflows | spec | Ensure Workflow pods are running as non-root user | Argo Workflows | |
Project: KubeZoo (Provisioning / Automation & Configuration)
File: README.md

English | KubeZoo is a lightweight gateway service that leverages the existing namespace model and add multi-tenancy capability to existing Kubernetes. KubeZoo provides view-level isolation among tenants by capturing and transforming the requests and responses. Please refer to for details. <div align="center"> <!--[if IE]> <img src="docs/img/kubezoo-overview.png" width=80% title="KubeZoo Overview" loading="eager" /> <![endif]--> <picture> <source srcset="docs/img/kubezoo-overview-dark.png" width=80% title="KubeZoo Overview" media="(prefers-color-scheme: dark)"> <img src="docs/img/kubezoo-overview.png" width=80% title="KubeZoo Overview" loading="eager" /> </picture> </div> There exists models for Kubernetes, i.e., Namespace as a Service (NaaS), Cluster as a Service (CaaS), Control Planes as a service (CPaaS). Each of them can be applied to address different use cases. However, our cases have some specific requirements and constraints that can not be met by the existing models, Many Small Tenants* - there usually exist hundreds of tenants who only need to run small batch workloads containing few pods for tens of minutes. Short Turnaround Time* - users/tenants are usually impatient, who desire to have their service to be ready in minutes. Tight Manpower* - managing thousands of clusters/control-planes can be labour-intensive and infeasible for medium-sized dev team. To address these cases, we present a new tenancy model, i.e., Kubernetes API as a Service (KAaaS), which provides competent isolation with negligible overheads and operation costs. KubeZoo implements this model with all tenants sharing both the control-plane and data-plane, which is suitable for the scenarios where thousands of small tenants need to share an underlying Kubernetes cluster. <div align="center"> <img src="docs/img/comparison.png" width=80% title="Comparison of Different Solutions"> </div> For more details lease refer . Please check the before installing KubeZoo. KubeZoo supports Kubernetes versions up to 1.24. Using higher Kubernetes versions may cause compatibility issues. KubeZoo can be installed using any of the following methods: | Methods | Instruction | Estimated time | | | | -- | | Deploy KubeZoo from scratch | | < 2 minutes | If you are willing to be a contributor for the KubeZoo project, please refer to our document for details. We have also prepared a developer to help the code contributors. If you have any questions or want to contribute, you are welcome to communicate most things via GitHub issues or pull requests. Or Contact to KubeZoo is under the Apache 2.0 license. See the file for details. Certain implementations in KubeZoo rely on the existing code from Kubernetes and the credits go to the original Kubernetes authors.
Project: YugabyteDB (App Definition and Development / Database)
File: savepoints.md

title: Savepoints linkTitle: Savepoints description: Savepoints in YSQL menu: v2.18: identifier: advanced-features-savepoints parent: advanced-features weight: 235 type: docs This document provides an overview of YSQL savepoints, and demonstrates how to use them to checkpoint your progress within a transaction. The `SAVEPOINT` command establishes a new savepoint in the current transaction. A savepoint is a special mark inside a transaction that allows you to roll back all commands that are executed after it was established, restoring the transaction state to what it was at the time of the savepoint, all without abandoning the transaction. Savepoints are implemented in PostgreSQL using subtransactions. The relevant savepoint commands are: creates a savepoint. forgets about a savepoint. Note that you can use the same savepoint name more than once, so if there was an earlier savepoint with the same name, the name will now refer to that earlier savepoint. (In other words, the new savepoint gets popped off the stack of savepoints for that name.) rolls back to the database state as of the given savepoint, discarding all changes created after that savepoint, including the creation of new savepoints. Preserves the referenced savepoint, so that after one rollback it can be rolled back to again. {{% explore-setup-single %}} Create a sample table. ```plpgsql CREATE TABLE sample(k int PRIMARY KEY, v int); ``` Begin a transaction and insert some rows. ```plpgsql BEGIN TRANSACTION; INSERT INTO sample(k, v) VALUES (1, 2); SAVEPOINT test; INSERT INTO sample(k, v) VALUES (3, 4); ``` Now, check the rows in this table. ```plpgsql SELECT * FROM sample; ``` ```output k | v -+- 1 | 2 3 | 4 (2 rows) ``` Rollback to savepoint `test` and check the rows again. Note that the second row no longer appears. ```plpgsql ROLLBACK TO test; SELECT * FROM sample; ``` ```output k | v -+- 1 | 2 (1 row) ``` You can even add a new row at this point. If you then commit the transaction, only the first and third rows inserted persist: ```plpgsql INSERT INTO sample(k, v) VALUES (5, 6); COMMIT; SELECT * FROM SAMPLE; ``` ```output k | v -+- 5 | 6 1 | 2 (2 rows) ``` Refer to and for more examples.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: PULL_REQUEST_TEMPLATE.md

<!-- Please describe what you added, and add a screenshot if possible. That makes it easier to understand the change so we can :shipit: faster. --> <! Please include the following in your Pull Request when applicable: --> ) [ ] Added or updated documentation [ ] Tests for new functionality and regression tests for bug fixes [ ] Screenshots attached (for UI changes) )
Project: sso (Provisioning / Key Management)
File: generate_request_signature.md

`sso-generate-request-signature` is a command-line tool that is provided alongside `ssoproxy` to facilitate upstream testing of SSO's proxied request signatures, or of libraries that attempt to validate signatures. Note that running `sso-generate-request-signature` requires some of the same configuration to be in place as running `sso-proxy` would, i.e. a `REQUESTSIGNERKEY` environment variable. Assuming that exists, the tool can be run with three optional flags, followed by as many request headers as desired in `<name>:<value>` format: `-url`: the path of the URL of the request to calculate the signature on (default: "") `-method`: the method of the request (default: "GET") (note: the method is not used in the signature calculation) `-body`: for PUT or POST requests, a string representing the body of the request to calculate a signature on (default: "") `sso-generate-request-signature -url "/foo" -method "POST" -body "{}" x-header-1:bar x-header-2:baz` `sso-generate-request-signature -url "/bar"`
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_redis_instances.md

+++ title = "googleredisinstances resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleredisinstances" identifier = "inspec/resources/gcp/googleredisinstances.md googleredisinstances resource" parent = "inspec/resources/gcp" +++ A `googleredisinstances` is used to test a Google Instance resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googleredisinstances(project: 'chef-gcp-inspec', region: 'us-central1') do its('tiers') { should include 'STANDARD_HA' } its('memorysizegbs') { should include '1' } its('alternativelocationids') { should include 'us-central1-f' } its('redisversions') { should include 'REDIS3_2' } its('display_names') { should include 'InSpec test instance' } its('reservedipranges') { should include '192.168.0.0/29' } end ``` Properties that can be accessed from the `googleredisinstances` resource: See the resource for more information. `alternativelocationids` : an array of `googleredisinstance` alternativelocationid `authorized_networks` : an array of `googleredisinstance` authorized_network `connect_modes` : an array of `googleredisinstance` connect_mode `create_times` : an array of `googleredisinstance` create_time `currentlocationids` : an array of `googleredisinstance` currentlocationid `display_names` : an array of `googleredisinstance` display_name `hosts` : an array of `googleredisinstance` host `labels` : an array of `googleredisinstance` labels `redis_configs` : an array of `googleredisinstance` redis_configs `location_ids` : an array of `googleredisinstance` location_id `names` : an array of `googleredisinstance` name `memorysizegbs` : an array of `googleredisinstance` memorysizegb `ports` : an array of `googleredisinstance` port `redis_versions` : an array of `googleredisinstance` redis_version `reservedipranges` : an array of `googleredisinstance` reservediprange `tiers` : an array of `googleredisinstance` tier `regions` : an array of `googleredisinstance` region This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method.
Project: Beam (App Definition and Development / Streaming & Messaging)
File: primerai.md

title: "PrimerAI" icon: /images/logos/powered-by/primerai.png hasLink: "https://primer.ai/" <!-- Licensed 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. -->
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_remove_cluster.md

title: "Command - devspace remove cluster" sidebar_label: devspace remove cluster Removes a connected cluster ``` devspace remove cluster [flags] ``` ``` Removes a connected cluster Example: devspace remove cluster my-cluster ``` ``` -h, --help help for cluster --provider string The cloud provider to use -y, --yes Ignores all questions and deletes the cluster with all services and spaces ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile string The devspace profile to use (if there is any) --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) ```
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: restart-mongodb-cluster.md

title: Restart a MongoDB cluster description: How to restart a MongoDB cluster keywords: [mongodb, restart a cluster] sidebar_position: 4 sidebar_label: Restart You can restart all pods of the cluster. When an exception occurs in a database, you can try to restart it. Restart a cluster with `kbcli cluster restart` command and enter the cluster name again. ```bash kbcli cluster restart mongodb-cluster > OpsRequest mongodb-cluster-restart-pzsbj created successfully, you can view the progress: kbcli cluster describe-ops mongodb-cluster-restart-pzsbj -n default ``` Validate the restarting with the request code randomly generated, in this guide, it is `pzsbj`, see step 1. ```bash kbcli cluster describe-ops mongodb-cluster-restart-pzsbj -n default ```