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

<!-- Thank you for contributing to openGemini! --> <!-- Mark the checkbox [X] or [x] if you agree with the item. --> <!-- Please create an issue first to describe the problem. There MUST be one line starting with "Issue Number: " and linking the relevant issues via the "close","fix", "resolve" or "ref". --> Issue Number: close/fix/resolve/ref #xxx Please describe how it works Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration [ ] Test A [ ] Test B [ ] Test cases to be added [ ] No code [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] I have added tests that prove my fix is effective or that my feature works [ ] New and existing unit tests pass locally with my changes [ ] Any dependent changes have been merged and published in downstream modules
Project: KICS (Provisioning / Security & Compliance)
File: a21c8da9-41bf-40cf-941d-330cf0d11fc7.md

title: Azure Active Directory Authentication hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a21c8da9-41bf-40cf-941d-330cf0d11fc7 Query name: Azure Active Directory Authentication Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Access Control URL: Azure Active Directory must be used for authentication for Service Fabric<br> ```tf title="Positive test num. 1 - tf file" hl_lines="19" resource "azurermservicefabric_cluster" "positive1" { name = "example-servicefabric" resourcegroupname = azurermresourcegroup.example.name location = azurermresourcegroup.example.location reliability_level = "Bronze" upgrade_mode = "Manual" clustercodeversion = "7.1.456.959" vm_image = "Windows" management_endpoint = "https://example:80" node_type { name = "first" instance_count = 3 is_primary = true clientendpointport = 2020 httpendpointport = 80 } azureactivedirectory { clusterapplicationid = "id" clientapplicationid = "id" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" resource "azurermservicefabric_cluster" "positive2" { name = "example-servicefabric" resourcegroupname = azurermresourcegroup.example.name location = azurermresourcegroup.example.location reliability_level = "Bronze" upgrade_mode = "Manual" clustercodeversion = "7.1.456.959" vm_image = "Windows" management_endpoint = "https://example:80" node_type { name = "first" instance_count = 3 is_primary = true clientendpointport = 2020 httpendpointport = 80 } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermservicefabric_cluster" "negative" { name = "example-servicefabric" resourcegroupname = azurermresourcegroup.example.name location = azurermresourcegroup.example.location reliability_level = "Bronze" upgrade_mode = "Manual" clustercodeversion = "7.1.456.959" vm_image = "Windows" management_endpoint = "https://example:80" node_type { name = "first" instance_count = 3 is_primary = true clientendpointport = 2020 httpendpointport = 80 } azureactivedirectory { tenant_id = "id" clusterapplicationid = "id" clientapplicationid = "id" } } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: keda.md

layout: integration title: Keda subtitle: Collaborative and visual infrastructure as code for Keda image: /assets/img/integrations/keda/icons/color/keda-color.svg permalink: extensibility/integrations/keda docURL: https://docs.meshery.io/extensibility/integrations/keda description: integrations-category: Serverless integrations-subcategory: Installable Platform registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: pkg_ids.md

+++ title = "Package Identifiers" description = "How to call a package in Chef Habitat Builder, Studio, and plan files" gh_repo = "habitat" [menu] [menu.habitat] title = "Package Identifiers" identifier = "habitat/reference/pkg_ids Package ID" parent = "habitat/reference" +++ A Chef Habitat artifact the binary distribution for a given package built with Chef Habitat. A Chef Habitat artifact is a signed tarball with a `.hart` file extension. Chef Habitat artifacts are composed of a software library or application, the configuration information for that software, and lifecycle hooks. They are created from a the plan file, a `plan.sh` on Linux systems or a `plan.ps1` on Windows systems, and are built with Chef Habitat tools. Chef Habitat artifacts can be exported to a specific format, such as when creating a Docker image. When referring to Chef Habitat artifacts from either Builder or the Studio, you can refer to them in two ways: Fully-qualified package identifier (FQPI) - Uses four components in the following format: `origin/name/version/release`. For example, `core/glibc/2.22/20160310192356`. Short package identifier - Uses two components in the following format `origin/name`. For example, `core/redis` or `core/openssl`. Use the three-component form `origin/name/version`, such as `core/redis/5.0.4`, when you need a specific version of an artifact. `Origin`: A name that defines a set of related Chef Habitat packages and the artifacts they generate. For example, "sample", "core", or "mycompany". `Name`: The name of the application or service. For example, "postgres". `Version`: The version number designation by the author(s) of the application or service. For example, "3.1.1", or "20160118". `Release`: The unique Chef Habitat id for a given version based on the timestamp pattern YYYYMMDDhhmmss. For example, "20160204220358" would be a Chef Habitat artifact built at 22:03:58 on February 4th, 2016. If the Chef Habitat artifact identifier isn't fully qualified (having fewer than four components), and exactly one artifact is required, then the missing components are assumed to be the most recent values. For example: `core/glibc` assumes that version and release values are for the latest version of core/glibc. `core/glibc/2.22` assumes that the version of core/glibc is 2.22 and that the release is for the most recent value of core/glibc/2.22. `core/glibc/2.22/20160310192356` only refers to the specific Chef Habitat artifact 20160310192356.
Project: Memphis (App Definition and Development / Streaming & Messaging)
File: pkcs12.md

Refresh PKCS12 files when test certificates and keys (PEM files) are refreshed (e.g. expiry workflow) `client.p12` is a p12/pfx packaging of `client.pem` and `client-key.pem` `openssl pkcs12 -export -inkey ./client-key.pem -in ./client.pem -out client.p12` Note: set the PKCS12 bundle password to `s3cr3t` as required by provisioning scripts Windows cert store supports p12/pfx bundle for certificate-with-key import. Windows cert store tests will execute a Powershell script to import relevant PKCS12 bundle into the Windows store before the test. Equivalent to: `powershell.exe -command "& '..\test\configs\certs\tlsauth\certstore\import-<client,server>-p12.ps1'"` The `delete-cert-from-store.ps1` script deletes imported certificates from the Windows store (if present) that can cause side-effects and impact the validity of different use tests. Note: Tests are configured for "current user" store context. Execute tests with appropriate Windows permissions (e.g. as Admin) if adding tests with "local machine" store context specified.
Project: StarRocks (App Definition and Development / Database)
File: KILL.md

displayed_sidebar: "English" Terminates a connection or a query currently being performed by threads executing within StarRocks. :::tip This operation does not require privileges. ::: ```SQL KILL [ CONNECTION | QUERY ] <processlist_id> ``` | Parameter | Description | | | | | Modifier:<ul><li>CONNECTION</li><li>QUERY</li></ul> | <ul><li>With a `CONNECTION` modifier, the KILL statement terminates the connection associated with the given `processlist_id`, after terminating any statement the connection is executing.</li><li>With a `QUERY` modifier, the KILL statement terminates the statement the connection is currently executing, but leaves the connection itself intact.</li><li>If no modifier is present, the default is `CONNECTION`.</li></ul> | | processlist_id | The ID of the thread you want to terminate. You can get the IDs of the threads that are being executed using . | ```Plain mysql> SHOW FULL PROCESSLIST; ++++--++++-+--+--+ | Id | User | Host | Db | Command | ConnectionStartTime | Time | State | Info | IsPending | ++++--++++-+--+--+ | 20 | root | xxx.xx.xxx.xx:xxxxx | sr_hub | Query | 2023-01-05 16:30:19 | 0 | OK | show full processlist | false | ++++--++++-+--+--+ 1 row in set (0.01 sec) mysql> KILL 20; Query OK, 0 rows affected (0.00 sec) ```
Project: ArangoDB (App Definition and Development / Database)
File: tryv.md

+++ title = "`BOOSTOUTCOMETRYV(expr)/BOOSTOUTCOMETRY(expr)`" description = "Evaluate an expression which results in an understood type, continuing execution if successful, immediately returning `tryoperationreturn_as(X)` from the calling function if unsuccessful." +++ Evaluate an expression which results in a type matching the following customisation points, continuing execution if successful, immediately returning {{% api "tryoperationreturn_as(X)" %}} from the calling function if unsuccessful: `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationhasvalue(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationreturnas(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationextractvalue(X)" %}} Default overloads for these customisation points are provided. See . The difference between the `BOOSTOUTCOMETRYV(expr)` and `BOOSTOUTCOMETRY(expr)` editions is that the latter will set a variable if two or more macro arguments are present (see {{% api "BOOSTOUTCOMETRY(var, expr)" %}}). The former requires the `T` to be `void`. Hints are given to the compiler that the expression will be successful. If you expect failure, you should use {{% api "BOOSTOUTCOMETRYVFAILURELIKELY(expr)" %}} instead. An internal temporary to hold the value of the expression is created, which generally invokes a copy/move. Overridable: Not overridable. Definition: Firstly the expression's temporary is bound to a uniquely named, stack allocated, `auto &&`. If that reference's bound object's `tryoperationhasvalue()` is false, immediately execute `return tryoperationreturnas(propagated unique reference);`, propagating the rvalue/lvalue/etc-ness of the original expression. Header: `<boost/outcome/try.hpp>`
Project: APIClarity (Provisioning / Security & Compliance)
File: README.md

Modules give developers the ability to add functionality to the API Clarity UI without having to understand the internals of the API Clarity codebase. Modules can be added to the API Inventory details view and API Event details view. You're plugin will show up as a tab. See the demoModule for a simple example of this. Modules can have their own dependencies. By adding a `package.json` to your module and listing dependencies, the API Clarity build process will install your dependencies. Create a new directory under `ui/src/modules`. Export your module. You'll need to export it as an object with the following properties: ```json export default { name: 'Demo Module', // this name will be used as the tab name in API Clarity component: DemoModule, // your component endpoint: '/demomodule', // the endpoint will be used by the router type: MODULETYPES.EVENTDETAILS // the type indicates where your module is to appear in the UI. }; ``` The Module types are defined within `ui/src/module/MODULETYPES.js`. The types are `EVENTDETAILS` and `INVENTORYDETAILS`. If `type` is not exported (or using one that isn't defined within `MODULETYPES`) with your module, it will not be displayed in the UI. Import your module in `ui/src/modules/index.js`. Then add your imported module to the modules array.
Project: Percona Server for MySQL (App Definition and Development / Database)
File: CONTRIBUTING.md

libcbor is maintained by in his spare time on a best-effort basis. Community contributions are welcome as long as they align with the and and follow the guidelines described belows. Bug reports and questions: Bug reports and specific technical questions are always welcome. Feel free to open an . Incremental improvements: Bug fixes (including build scripts, examples, test, typos, CI/CD config, etc.) and documentation improvements (fixes of typos, inaccuracies, out of date content, etc.) are always welcome. Feel free to open a . New features: I am looking to keep the scope of libcbor small. If you would like to add a feature, please open an issue with your proposal (or reach out to me privately) to discuss if the feature fits into libcbor before opening a PR. Major changes: Please open an issue with your proposal (or reach out to me privately) to discuss if the improvement fits into cbor before opening a PR. Ensure that all CI checks pass Check that the PR is complete and of good quality Include a descriptive summary of the change. If the PR addresses an open issue, please link it. Code changes: Add tests If necessary: Update documentation, including any links Code changes: Update . Do not change the version number. I work on libcbor on a best effort basis. The typical response time is a few days. If you do not receive a response in a few weeks, feel free to ping the PR or issue.
Project: kube-hunter (Provisioning / Security & Compliance)
File: KHV030.md

vid: KHV030 title: Possible DNS Spoof categories: [Identity Theft] severity: high Your Kubernetes DNS setup is vulnerable to spoofing attacks which impersonate your DNS for malicious purposes. In this case the exploited vulnerability was ARP spoofing, but other methods could be used as well. Consider using DNS over TLS. CoreDNS (the common DNS server for Kubernetes) supports this out of the box, but your client applications might not.
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.5.2.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Disable SSLv3 in HttpFS | Blocker | webhdfs | Robert Kanter | Robert Kanter | | | SSLFactory shouldn't allow SSLv3 | Blocker | . | Wei Yan | Wei Yan | | | Patch up Jetty to disable SSLv3 | Blocker | security | Karthik Kambatla | Mike Yoder | | | Renable SSLv2Hello in HttpFS | Blocker | webhdfs | Robert Kanter | Robert Kanter | | | create-release script should run git clean first | Blocker | scripts | Karthik Kambatla | Karthik Kambatla |
Project: KICS (Provisioning / Security & Compliance)
File: 48bbe0fd-57e4-4678-a4a1-119e79c90fc3.md

title: Storage Share File Allows All ACL Permissions hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 48bbe0fd-57e4-4678-a4a1-119e79c90fc3 Query name: Storage Share File Allows All ACL Permissions Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Azure Storage Share File should not allow all ACL (Access Control List) permissions - r (read), w (write), d (delete), and l (list).<br> ```tf title="Positive test num. 1 - tf file" hl_lines="10" resource "azurermstorageshare" "example" { name = "sharename" storageaccountname = azurermstorageaccount.example.name quota = 50 acl { id = "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI" access_policy { permissions = "rwdl" start = "2022-07-02T09:38:21.0000000Z" expiry = "2021-07-02T10:38:21.0000000Z" } } } resource "azurermstorageshare_file" "example" { name = "my-awesome-content.zip" storageshareid = azurermstorageshare.example.id source = "some-local-file.zip" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermstoragetable" "table_resource2" { name = "mytablename" storageaccountname = "mystoragexxx" acl { id = "someid-1XXXXXXXXX" access_policy { expiry = "2022-10-03T05:05:00.0000000Z" permissions = "r" start = "2021-05-28T04:05:00.0000000Z" } } } ```
Project: kpt (Provisioning / Automation & Configuration)
File: 08-publishing-a-package.md

A kpt package is published as a Git subdirectory containing KRM resources. Publishing a package is just a normal Git push. This also means that any existing Git directory of KRM resources is a valid kpt package. As an example, let's re-publish the local `wordpress` package to your own repo. Start by initializing the the `wordpress` directory as a Git repo if you haven't already done so: ```shell $ cd wordpress; git init; git add .; git commit -m "My wordpress package" ``` Tag the commit: ```shell $ git tag v0.1 ``` Push the commit which requires you to have access to the repo: ```shell $ git push origin v0.1 ``` You can then fetch the published package: ```shell $ kpt pkg get <MYREPOURL>/@v0.1 ``` You may have a Git repo containing multiple packages. kpt provides a tagging convention to enable packages to be independently versioned. For example, let's assume the `wordpress` directory is not at the root of the repo but instead is in the directory `packages/wordpress`. Tag the commit: ```shell $ git tag packages/wordpress/v0.1 ``` Push the commit: ```shell $ git push origin packages/wordpress/v0.1 ``` You can then fetch the published package: ```shell $ kpt pkg get <MYREPOURL>/packages/wordpress@v0.1 ```
Project: KICS (Provisioning / Security & Compliance)
File: 6e856af2-62d7-4ba2-adc1-73b62cef9cc1.md

title: Security Group With Unrestricted Access To SSH hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 6e856af2-62d7-4ba2-adc1-73b62cef9cc1 Query name: Security Group With Unrestricted Access To SSH Platform: CloudFormation Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: 'SSH' (TCP:22) should not be public in AWS Security Group<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="15" Resources: Ec2Instance: Type: 'AWS::EC2::Instance' Properties: SecurityGroups: !Ref InstanceSecurityGroup KeyName: mykey ImageId: '' InstanceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow http to client host VpcId: Ref: myVPC SecurityGroupIngress: IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 SecurityGroupEgress: IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 0.0.0.0/0 ``` ```json title="Positive test num. 2 - json file" hl_lines="27" { "Resources": { "Ec2Instance": { "Type": "AWS::EC2::Instance", "Properties": { "ImageId": "", "SecurityGroups": [ "InstanceSecurityGroup" ], "KeyName": "mykey" } }, "InstanceSecurityGroup": { "Properties": { "SecurityGroupEgress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" } ], "GroupDescription": "Allow http to client host", "VpcId": { "Ref": "myVPC" }, "SecurityGroupIngress": [ { "ToPort": 22, "CidrIp": "0.0.0.0/0", "IpProtocol": "tcp", "FromPort": 22 } ] }, "Type": "AWS::EC2::SecurityGroup" } } } ``` ```yaml title="Negative test num. 1 - yaml file" Resources: Ec2Instance: Type: 'AWS::EC2::Instance' Properties: SecurityGroups: !Ref InstanceSecurityGroup KeyName: mykey ImageId: '' InstanceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow http to client host VpcId: Ref: myVPC SecurityGroupIngress: IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 127.0.0.1/32 SecurityGroupEgress: IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 127.0.0.1/33 ``` ```json title="Negative test num. 2 - json file" { "Resources": { "InstanceSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Allow http to client host", "VpcId": { "Ref": "myVPC" }, "SecurityGroupIngress": [ { "FromPort": 80, "ToPort": 80, "CidrIp": "127.0.0.1/32", "IpProtocol": "tcp" } ], "SecurityGroupEgress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "127.0.0.1/33" } ] } }, "Ec2Instance": { "Type": "AWS::EC2::Instance", "Properties": { "SecurityGroups": [ "InstanceSecurityGroup" ], "KeyName": "mykey", "ImageId": "" } } } } ```
Project: TDengine (App Definition and Development / Database)
File: 03-telegraf.md

title: Telegraf writing sidebar_label: Telegraf description: This document describes how to integrate TDengine with Telegraf. import Telegraf from "../14-reference/_telegraf.mdx" Telegraf is a viral, open-source, metrics collection software. Telegraf can collect the operation information of various components without having to write any scripts to collect regularly, reducing the difficulty of data acquisition. Telegraf's data can be written to TDengine by simply adding the output configuration of Telegraf to the URL corresponding to taosAdapter and modifying several configuration items. The presence of Telegraf data in TDengine can take advantage of TDengine's efficient storage query performance and clustering capabilities for time-series data. To write Telegraf data to TDengine requires the following preparations. The TDengine cluster is deployed and functioning properly taosAdapter is installed and running properly. Please refer to the for details. Telegraf has been installed. Please refer to the for Telegraf installation. Telegraf collects the running status measurements of current system. You can enable to insert data to Telegraf then forward to TDengine. <Telegraf /> Restart Telegraf service: ``` sudo systemctl restart telegraf ``` Use TDengine CLI to verify Telegraf correctly writing data to TDengine and read out: ``` taos> show databases; name | ================================= information_schema | performance_schema | telegraf | Query OK, 3 rows in database (0.010568s) taos> use telegraf; Database changed. taos> show stables; name | ================================= swap | cpu | system | diskio | kernel | mem | processes | disk | Query OK, 8 row(s) in set (0.000521s) taos> select * from telegraf.system limit 10; ts | load1 | load5 | load15 | ncpus | nusers | uptime | uptime_format | host | ============================================================================================================================================================================================================================================= 2022-04-20 08:47:50.000000000 | 0.000000000 | 0.050000000 | 0.070000000 | 4 | 1 | 5533 | 1:32 | shuduo-1804 | 2022-04-20 08:48:00.000000000 | 0.000000000 | 0.050000000 | 0.070000000 | 4 | 1 | 5543 | 1:32 | shuduo-1804 | 2022-04-20 08:48:10.000000000 | 0.000000000 | 0.040000000 | 0.070000000 | 4 | 1 | 5553 | 1:32 | shuduo-1804 | Query OK, 3 row(s) in set (0.013269s) ``` :::note TDengine take influxdb format data and create unique ID for table names by the rule. The user can configure `smlChildTableName` parameter to generate specified table names if he/she needs. And he/she also need to insert data with specified data format. For example, Add `smlChildTableName=tname` in the taos.cfg file. Insert data `st,tname=cpu1,t1=4 c1=3 1626006833639000000` then the table name will be cpu1. If there are multiple lines has same tname but different tagset, the first line's tagset will be used to automatically creating table and ignore other lines. Please refer to :::