cwielenb/CNCF-Dataset huggingface dataset:
Project: CloudARK KubePlus (App Definition and Development / Application Definition & Image Build)
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 ivan+abuse@flanders.co.nz. 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: kube-hunter (Provisioning / Security & Compliance)
File: KHV049.md

vid: KHV049 title: kubectl proxy Exposed categories: [Information Disclosure] severity: high An open kubectl proxy was detected. `kubectl proxy` is a convenient tool to connect from a local machine into an application running in Kubernetes or to the Kubernetes API. This is common practice to browse for example the Kubernetes dashboard. Leaving an open proxy can be exploited by an attacker to gain access into your entire cluster. Expose your applications in a permanent, legitimate way, such as via Ingress. Close open proxies immediately after use.
Project: KICS (Provisioning / Security & Compliance)
File: 89fe890f-b480-460c-8b6b-7d8b1468adb4.md

title: IAM Audit Not Properly Configured hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 89fe890f-b480-460c-8b6b-7d8b1468adb4 Query name: IAM Audit Not Properly Configured Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Observability URL: Audit Logging Configuration is defective<br> ```tf title="Positive test num. 1 - tf file" hl_lines="19 9 3 23" resource "googleprojectiamauditconfig" "positive1" { project = "your-project-id" service = "somespecificservice" auditlogconfig { logtype = "ADMINREAD" } auditlogconfig { logtype = "DATAREAD" exempted_members = [ "user:joebloggs@hashicorp.com" ] } } resource "googleprojectiamauditconfig" "positive2" { project = "your-project-id" service = "allServices" auditlogconfig { logtype = "INVALIDTYPE" } auditlogconfig { logtype = "DATAREAD" exempted_members = [ "user:joebloggs@hashicorp.com" ] } } ``` ```tf title="Negative test num. 1 - tf file" resource "googleprojectiamauditconfig" "negative1" { project = "your-project-id" service = "allServices" auditlogconfig { logtype = "ADMINREAD" } auditlogconfig { logtype = "DATAREAD" } } ```
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno_create_values.md

Create a Kyverno values file. Create a Kyverno values file. ``` kyverno create values [flags] ``` ``` kyverno create values -g request.mode=dev -n prod,env=prod --rule policy,rule,env=demo --resource policy,resource,env=demo ``` ``` -g, --global strings Global value -h, --help help for values -n, --ns-selector stringArray Namespace selector -o, --output string Output path (uses standard console output if not set) --resource stringArray Policy resource values --rule stringArray Policy rule values ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Helps with the creation of various Kyverno resources.
Project: ArangoDB (App Definition and Development / Database)
File: std_error_code.md

+++ title = "std::error_code" description = "Overview of std::error_code" weight = 40 +++ Type `std::error_code` has been designed to be sufficiently small and trivial to be cheaply passed around, and at the same time be able to store sufficient information to represent any error situation from any library/sub-system in the world without a clash. Its representation is basically: ```c++ class error_code { error_category* domain; // domain from which the error originates int value; // numeric value of error within the domain }; ``` Here, `domain` indicates the library from which the error originates. It is a pointer to a global object representing a given library/domain. Different libraries will be represented by different pointers to different globals. Each domain is expected to be represented by a global object derived from `std::error_category`. The uniqueness of the domain pointer value is guaranteed by the uniqueness of addresses of different global objects. Now, `value` represents a numeric value of a particular error situation within the domain. Thus, different domains can use the same numeric value `1` to indicate different error situations, but two `std::error_code` objects will be different because the pointers representing domains will be different. `std::error_code` comes with additional tools: a facility for defining custom domains with their set of error codes, and a facility for building predicates that allow classifying errors. Once created and passed around (either inside a thrown exception or returned from functions by value) there is never a need to change the value of `error_code` object at any level. But at different levels one can use different predicates for classifying error situations appropriately to the program layer. When a new library needs to represent its own set of error situations in an `error_code` it first has to declare the list of numeric value as an enumeration: ```c++ enum class ConvertErrc { StringTooLong = 1, // 0 should not represent an error EmptyString = 2, IllegalChar = 3, }; ``` Then it has to put some boiler-plate code to plug the new enumeration into the `std::errorcode` system. Then, it can use the enum as an `errorcode`: ```c++ std::error_code ec = ConvertErrc::EmptyString; assert(ec == ConvertErrc::EmptyString); ``` Member `value` is mapped directly from the numeric value in the enumeration, and member `domain` is mapped from the type of the enumeration. Thus, this is a form of type erasure, but one that does allow type `std::error_code` to be trivial and standard-layout.
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.0.11.2.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Infinite loop in chooseTarget | Major | . | dhruba borthakur | dhruba borthakur | | | map/reduce is corrupting data between map and reduce | Blocker | . | Owen O'Malley | Devaraj Das | | | ArithmeticException when number of racks is zero | Major | . | James P. White | Hairong Kuang |
Project: YugabyteDB (App Definition and Development / Database)
File: yba_completion_zsh.md

Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(yba completion zsh) To load completions for every new session, execute once: yba completion zsh > "${fpath[1]}/_yba" yba completion zsh > $(brew --prefix)/share/zsh/site-functions/_yba You will need to start a new shell for this setup to take effect. ``` yba completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Generate the autocompletion script for the specified shell
Project: Apollo (Provisioning / Automation & Configuration)
File: apollo-benchmark.md

Many people are concerned about the performance and reliability of Apollo. The following data is collected from a single machine in Ctrip's internal production environment. The monitoring tool is . 4C12G ``` -Xms6144m -Xmx6144m -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=384m -XX:NewSize=4096m -XX:MaxNewSize=4096m -XX:SurvivorRatio=8 -XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=9 -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+ UseCMSInitiatingOccupancyOnly -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled -XX: CMSFullGCsBeforeCompaction=9 -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+ CMSPermGenSweepingEnabled -XX:CMSInitiatingPermOccupancyFraction=70 -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+ PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError -XX:- OmitStackTraceInFastThrow -Duser.timezone=Asia/Shanghai -Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8 -Djava.security.egd= file:/dev/./urandom ``` 1.8.0_60 0.9.0 5600 10W+ `QPS`: 160 `Average response time`: 0.1ms `95 line response time`: 0.3ms `999 line response time`: 2.5ms Note: config service has config cache enabled, for more information you can refer to `YGC`: average 2Min once, one time 300ms `OGC`: average 1H once, one time consuming 380ms LoadAverage: 0.5 System CPU utilization: 6% Process CPU utilization: 8%
Project: KICS (Provisioning / Security & Compliance)
File: 59312e8a-a64e-41e7-a252-618533dd1ea8.md

title: Output Without Description hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 59312e8a-a64e-41e7-a252-618533dd1ea8 Query name: Output Without Description Platform: Terraform Severity: <span style="color:#5bc0de">Info</span> Category: Best Practices URL: All outputs should contain a valid description.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" output "cluster_name" { value = "example" } resource "awsekscluster" "positive1" { dependson = [awscloudwatchloggroup.example] } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="3" output "cluster_name" { value = "example" description = " " } resource "awsekscluster" "positive1" { dependson = [awscloudwatchloggroup.example] } ``` ```tf title="Positive test num. 3 - tf file" hl_lines="3" output "cluster_name" { value = "example" description = "" } resource "awsekscluster" "positive1" { dependson = [awscloudwatchloggroup.example] } ``` ```tf title="Negative test num. 1 - tf file" output "cluster_name" { value = "example" description = "cluster name" } resource "awsekscluster" "negative1" { dependson = [awscloudwatchloggroup.example] enabledclusterlog_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"] } ```
Project: VMClarity (Provisioning / Security & Compliance)
File: RELEASE.md

This document outlines the process for creating a new release for VMClarity using the . All code block examples provided below correspond to an update to version `v0.7.0`, please update accordingly. Create a new branch for the release version update. ```sh git checkout -b release/v0.7.0 ``` Modify the `versions.yaml` file to update the version for VMClarity's module-set. Keep in mind that the same version is applied to all modules. ```diff vmclarity: version: v0.6.0 version: v0.7.0 ``` Commit the changes with a suitable message. ```sh git add versions.yaml git commit -m "release: update module set to version v0.7.0" ``` Run the version verification command to check for any issues. ```sh make multimod-verify ``` Run the following command to update all `go.mod` files to the new release version. ```sh make multimod-prerelease ``` Review the changes made in the last commit to ensure correctness. Push the branch to the GitHub repository. ```sh git push origin release/v0.7.0 ``` Create a pull request for these changes with a title like "release: prepare version v0.7.0". After the pull request is approved and merged, update your local main branch. ```sh git checkout main git pull origin main ``` To trigger the release workflow, create and push to the repository a release tag for the last commit. ```sh git tag -a v0.7.0 git push origin v0.7.0 ``` Please note that the release tag is not necessarily associated with the "release: prepare version v0.7.0" commit. For example, if any bug fixes were required after this commit, they can be merged and included in the release. Wait until the release workflow is completed successfully. Navigate to the and verify the draft release description as well as the assets listed. Once the draft release has been verified, click on `Edit` release and then on `Publish Release`.
Project: Kubescape (Provisioning / Security & Compliance)
File: CONTRIBUTING.md

First, it is awesome that you are considering contributing to Kubescape! Contributing is important and fun and we welcome your efforts. When contributing, we categorize contributions into two: Small code changes or fixes, whose scope is limited to a single or two files Complex features and improvements, with potentially unlimited scope If you have a small change, feel free to fire up a Pull Request. When planning a bigger change, please first discuss the change you wish to make via an issue, so the maintainers are able to help guide you and let you know if you are going in the right direction. Please follow our in all of your interactions within the project. Please follow the . Ensure any install or build dependencies are removed before the end of the layer when doing a build. Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters. Open Pull Request to the `master` branch. We will merge the Pull Request once you have the sign-off. All commits to the project must be "signed off", which states that you agree to the terms of the . This is done by adding a "Signed-off-by:" line in the commit message, with your name and email address. Commits made through the GitHub web application are automatically signed off. First, configure your name and email address in Git global settings: ``` $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ``` You can now sign off per-commit, or configure Git to always sign off commits per repository. Add to your Git command line. For example: ```git commit -s -m "Fix issue 64738"``` This is tedious, and if you forget, you'll have to . There are many ways to achieve this with Git hooks, but the simplest is to do the following: ``` cd your-repo curl -Ls https://gist.githubusercontent.com/dixudx/7d7edea35b4d91e1a2a8fbf41d0954fa/raw/prepare-commit-msg -o .git/hooks/prepare-commit-msg chmod +x .git/hooks/prepare-commit-msg ``` When contributing, you could consider using , in order to improve logs readability and help us to automatically generate `CHANGELOG`s. Format: `<type>(<scope>): <subject>` `<scope>` is optional ``` feat(cmd): add kubectl plugin ^--^ ^-^ ^-^ | | | | | +-> subject: summary in present tense. | | | +-> scope: point of interest | +-> type: chore, docs, feat, fix, refactor, style, or test. ``` More Examples: `feat`: new feature for the user, not a new feature for build script `fix`: bug fix for the user, not a fix to a build script `docs`: changes to the documentation `style`: formatting, missing semi colons, etc; no production code change `refactor`: refactoring production code, eg. renaming a variable `test`: adding missing tests, refactoring tests; no production code change `chore`: updating grunt tasks etc; no production code change Check out .
Project: Meshery (Provisioning / Automation & Configuration)
File: cert-manager-csi-driver-cacerts.md

layout: integration title: Cert Manager Csi Driver Cacerts subtitle: Collaborative and visual infrastructure as code for Cert Manager Csi Driver Cacerts image: /assets/img/integrations/cert-manager-csi-driver-cacerts/icons/color/cert-manager-csi-driver-cacerts-color.svg permalink: extensibility/integrations/cert-manager-csi-driver-cacerts docURL: https://docs.meshery.io/extensibility/integrations/cert-manager-csi-driver-cacerts description: integrations-category: Security & Compliance integrations-subcategory: Security & Compliance registrant: Artifact Hub components: name: ca-provider-class colorIcon: assets/img/integrations/cert-manager-csi-driver-cacerts/components/ca-provider-class/icons/color/ca-provider-class-color.svg whiteIcon: assets/img/integrations/cert-manager-csi-driver-cacerts/components/ca-provider-class/icons/white/ca-provider-class-white.svg description: featureList: [ "Simplifies the process of obtaining, renewing and using those certificates.", "Supports issuing certificates from a variety of sources.", "Ensures certificates remain valid and up to date." ] howItWorks: "Cloud native certificate management" howItWorksDetails: "X.509 certificate management for Kubernetes and OpenShift" language: en list: include type: extensibility category: integrations
Project: Chef Infra (Provisioning / Automation & Configuration)
File: bumping_minor_or_major_versions.md

After performing the monthly minor release of Chef, we should wait several days, and then bump the version for the next month's release. Why wait? We don't want to bump the version until we are sure we do not need to perform an emergency release for a regression. Once we're fairly confident we won't be performing a regression release, we want all new builds for the current channel to have the next month's version. This makes it very clear what version of Chef users are testing within the current channel. Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on main will be for the upcoming major release, and anything going into the stable release will need to be backported. See for more information on how we branch and backport to stable. See for the major version bump process. Chef's Expeditor tool includes functionality to bump the minor or major version of the product. By using Expeditor to bump versions, we can perform a bump without directly editing the version files. A version bump is performed when a PR is merged with either of these two labels applied: Expeditor: Bump Version Minor Expeditor: Bump Version Major
Project: StarRocks (App Definition and Development / Database)
File: CANCEL_REFRESH_MATERIALIZED_VIEW.md

displayed_sidebar: "English" Cancels a refresh task for an asynchronous materialized view. :::tip This operation requires the REFRESH privilege on the target materialized view. ::: ```SQL CANCEL REFRESH MATERIALIZED VIEW [<databasename>.]<materializedview_name> ``` | Parameter | Required | Description | | - | | | | database_name | No | Name of the database where the materialized view resides. If this parameter is not specified, the current database is used. | | materializedviewname | Yes | Name of the materialized view. | Example 1: Cancel the refresh task for the ASYNC refresh materialized view `lo_mv1`. ```SQL CANCEL REFRESH MATERIALIZED VIEW lo_mv1; ```