cwielenb/CNCF-Dataset huggingface dataset:
Project: Terraform (Provisioning / Automation & Configuration)
File: pull_request_template.md

<!-- Describe in detail the changes you are proposing, and the rationale. See the contributing guide: https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md --> <!-- Link all GitHub issues fixed by this PR, and add references to prior related PRs. --> Fixes # <!-- In normal circumstances we only target changes at the upcoming minor release, or as a patch to the current minor version. If you need to port a security fix to an older release, highlight this here by listing all targeted releases. If targeting the next patch release, also add the relevant x.y-backport label to enable the backport bot. --> 1.8.x <!-- Choose a category, delete the others: --> <!-- Write a short description of the user-facing change. Examples: `terraform show -json`: Fixed crash with sensitive set values. When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. The local token configuration in the cloud and remote backend now has higher priority than a token specified in a credentials block in the CLI configuration. -->
Project: Meshery (Provisioning / Automation & Configuration)
File: installation-scoop.md

You need to have `scoop` installed on your Windows system to perform these actions. To install `mesheryctl` using Scoop, execute the following commands. <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">scoop bucket add mesheryctl https://github.com/layer5io/scoop-bucket.git scoop install mesheryctl</div></div> </pre> You're ready to run Meshery. To do so, execute the following command. <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">mesheryctl system start</div></div> </pre> To upgrade `mesheryctl`, execute the following command. <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">scoop update mesheryctl</div></div> </pre>
Project: YugabyteDB (App Definition and Development / Database)
File: extension-tablefunc.md

title: tablefunc extension headerTitle: tablefunc extension linkTitle: tablefunc description: Using the tablefunc extension in YugabyteDB menu: stable: identifier: extension-tablefunc parent: pg-extensions weight: 20 type: docs The module includes various functions that return tables (that is, multiple rows). ```sql CREATE EXTENSION tablefunc; CREATE TABLE t(k int primary key, v double precision); PREPARE insertkv_pairs(int) AS INSERT INTO t(k, v) SELECT generate_series(1, $1), normal_rand($1, 1000.0, 10.0); ``` Test it as follows: ```sql DELETE FROM t; EXECUTE insertkv_pairs(10); SELECT k, to_char(v, '9999.99') AS v FROM t ORDER BY k; ``` You'll see results similar to the following: ```output k | v -+- 1 | 988.53 2 | 1005.18 3 | 1014.30 4 | 1000.92 5 | 999.51 6 | 1000.94 7 | 1007.45 8 | 991.22 9 | 987.95 10 | 996.57 (10 rows) ``` Every time you repeat the test, you'll see different generated values for `v`. For another example that uses `normal_rand()`, refer to . It populates a table with a large number (say 100,000) of rows and displays the outcome as a histogram that clearly shows the familiar bell-curve shape. `tablefunc` also provides the `connectby()`, `crosstab()`, and `crosstabN()` functions. The `connectby()` function displays a hierarchy of the kind that you see in an "employees" table with a reflexive foreign key constraint where "managerid" refers to "employeeid". Each next deeper level in the tree is indented from its parent following the well-known pattern. The `crosstab()`and `crosstabN()` functions produce "pivot" displays. The "N" in crosstabN() indicates the fact that a few, `crosstab1()`, `crosstab2()`, `crosstab3()`, are provided natively by the extension and that you can follow documented steps to create more.
Project: Vald (App Definition and Development / Database)
File: SECURITY.md

We currently offer security updates for the following Vald versions: | Version | Supported | | - | | | v1.7.x | :whitecheckmark: | | v1.6.x | :whitecheckmark: | | < v1.6 | :x: | At Vald, we prioritize software security. If you discover a security vulnerability, please report it to vald@vdaas.org. When reporting a vulnerability, please provide: A clear and concise description of the vulnerability. Steps to reproduce the issue. Any relevant versions or configurations to aid in diagnosing the problem. Any potential solutions or mitigations you may know of. We will assess your report promptly and respond as soon as possible. Once we reply, we will keep you informed about the fix progress and a comprehensive announcement. We value your responsible disclosure and will recognize your contributions. Our goal is to address all reported security issues promptly. Upon confirming a security concern, we will promptly release patch updates for the two most recent Vald minor versions. We advise all users to apply security updates as soon as they become available. Thank you for contributing to the safety of Vald and its users.
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: automatic-updates.md

Lagoon deploys applications in a way that is not compatible with some methods of updating Drupal core and contrib. Lagoon expects to build immutable images and run immutable containers. When the code of the application is changed at runtime, it can cause any of the following problems: Containers are managed automatically by Kubernetes and may be moved, restarted, or scaled at any time. When this happens, the original built container image will be ran and any changes that happened at runtime are lost. Tasks and cronjobs may run with the orignal built container image and won't have access to any updated code. Updating requires write permissions to the filesystem, but it is possible to configure an environment that forces a read-only filesystem. Best practices is to deploy small containers that each do one thing. For a typical Drupal project this means there is a `cli`, `php`, and `nginx` container which each contain a copy of the code. Updating only one of these containers will cause issues with code mismatches. The following update methods been disabled by Lagoon. The contrib module is disabled by and it will also be disabled when it moves into Drupal core. Using `drush pm-install` or `drush pm-update` is disabled by default as part of the package.
Project: ko (App Definition and Development / Application Definition & Image Build)
File: lambda.md

`ko` can build images that can be deployed as AWS Lambda functions, using . For best results, use the provided by the . For example: ```go package main import ( "context" "fmt" "github.com/aws/aws-lambda-go/lambda" ) type Event struct { Name string `json:"name"` // TODO: add other request fields here. } func main() { lambda.Start(func(ctx context.Context, event Event) (string, error) { return fmt.Sprintf("Hello %s!", event.Name), nil }) } ``` See AWS's for more information on writing Lambda functions in Go. To deploy to Lambda, you must push to AWS Elastic Container Registry (ECR): ```sh KODOCKERREPO=[account-id].dkr.ecr.[region].amazonaws.com/my-repo image=$(ko build ./cmd/app) ``` Then, create a Lambda function using the image in ECR: ```sh aws lambda create-function \ --function-name hello-world \ --package-type Image \ --code ImageUri=${image} \ --role arn:aws:iam::[account-id]:role/lambda-ex ``` See AWS's for more information on deploying Lambda functions using Go container images, including how to configure push access to ECR, and how to configure the IAM role for the function. The base image that `ko` uses by default supports both x86 and Graviton2 architectures. You can also use the to build and deploy Lambda functions as part of your IaC workflow, using the . See the to get started.
Project: Salt Project (Provisioning / Automation & Configuration)
File: README.md

Plugin which provides a notification mechanism to Salt, if Yum is used outside of it. Configuration files are going to: `/etc/yum/pluginconf.d/[name].conf` Plugin itself goes to: `/usr/share/yum-plugins/[name].conf` User: root Group: root Mode: 644 must be installed in /usr/bin/dpkgnotify
Project: Kubewarden (Provisioning / Security & Compliance)
File: RELEASE_NOTES_v0.3.0.md

The `v0.3.0` release of kubewarden-controller has dropped support for `v1alpha1` `ClusterAdmissionPolicy` custom resource as described on the `v0.2.0` release notes. Before upgrading to this version, please, refer to the `v0.2.0` release notes to find out how to migrate your `v1alpha1` resources if you still need to do so.
Project: YDB (App Definition and Development / Database)
File: temporary_table.md

In complex multiphase queries, it can be useful to explicitly create a physical temporary table in order to manually affect the query process. To do this, you can use the table name starting with `@`. Such tables are called anonymous to distinguish them from temporary tables created by a YT operation. Each such name within the query is replaced, at execution time, by a globally unique path to a table in a temporary directory. Such temporary tables are automatically deleted upon completion of the query, following the same rules as implicitly created tables. This feature lets you ignore conflicts in paths to temporary tables between parallel operations, and also avoid deleting them explicitly when the query completes. Examples: ```yql INSERT INTO @mytemptable SELECT * FROM myinputtable ORDER BY value; COMMIT; SELECT * FROM @mytemptable WHERE value = "123" UNION ALL SELECT * FROM @mytemptable WHERE value = "456"; ``` Temporary table names can use : ```yql $tmpname = "mytemp_table"; INSERT INTO @$tmp_name SELECT 1 AS one, 2 AS two, 3 AS three; COMMIT; SELECT * FROM @$tmp_name; ```
Project: MongoDB (App Definition and Development / Database)
File: bazel.md

(Note: This is a work-in-progress for the Build team; contact #ask-devprod-build for questions) To perform a Bazel build via SCons: You must be on a arm64 virtual workstation You must generate engflow credentials and store them in the correct location (see below) Build the Bazel-compatible target: `python3 ./buildscripts/scons.py --build-profile=fast --ninja=disabled --link-model=static -j 200 --modules= build/fast/mongo/db/commands/libfsync_locked.a` To generate and install the engflow credentials: Navigate to and log in with your mongodb gmail account: https://sodalite.cluster.engflow.com/gettingstarted Generate and download the credentials; you will need to move them to the workstation machine (scp, copy paste plain text, etc...) Store them (the same filename they downloaded as) on your machine at the default location our build expects: `/engflow/creds/` You should run `chmod 600` on them to make sure they are readable only by your user If you don't want to use the cluster you can pass `BAZEL_FLAGS=--config=local` on the SCons command line or `--config=local` on the bazel command line To perform a Bazel build and bypass SCons: Install Bazelisk: `curl -L https://mdb-build-public.s3.amazonaws.com/bazelisk-binaries/v1.19.0/bazelisk-linux-arm64 --output /tmp/bazelisk && chmod +x /tmp/bazelisk` Build the Bazel-compatible target: `/tmp/bazelisk build --verbosefailures src/mongo/db/commands:fsynclocked` To perform a Bazel build using a local Buildfarm (to test remote execution capability): For more details on Buildfarm, see https://bazelbuild.github.io/bazel-buildfarm (One time only) Build and start the Buildfarm: Change into the `buildfarm` directory: `cd buildfarm` Build the image: `docker-compose build` Start the container: `docker-compose up --detach` Poll until the containers report status `running`: `docker ps --filter status=running --filter name=buildfarm` (Whenever you build): \\ Build the Bazel-compatible target with remote execution enabled: `/tmp/bazelisk build --verbosefailures --remoteexecutor=grpc://localhost:8980 src/mongo/db/commands:fsync_locked`
Project: KICS (Provisioning / Security & Compliance)
File: 3ac3e75c-6374-4a32-8ba0-6ed69bda404e.md

title: Storage Table 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: 3ac3e75c-6374-4a32-8ba0-6ed69bda404e Query name: Storage Table Allows All ACL Permissions Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Azure Storage Table 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="8" resource "azurermstoragetable" "table_resource" { name = "mytablename" storageaccountname = "mystoragexxx" acl { id = "someid-1XXXXXXXXX" access_policy { expiry = "2022-10-03T05:05:00.0000000Z" permissions = "rwdl" start = "2021-05-28T04:05:00.0000000Z" } } } ``` ```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: YDB (App Definition and Development / Database)
File: to_from_bytes.md

Conversion of to a string with their binary representation and back. Numbers are represented in the format. Examples ```yql SELECT ToBytes(123), -- "\u0001\u0000\u0000\u0000" FromBytes( "\xd2\x02\x96\x49\x00\x00\x00\x00", Uint64 ); -- 1234567890ul ```
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.56.md

layout: release date: 2023-02-25 tag: v0.6.56 language: en [MeshModel] Add Schema for Component and Relationship @sudo-NithishKarthik (#6830) Bump golang.org/x/text from 0.3.6 to 0.3.8 in /install/docker-extension @dependabot (#7163) Doc for running Meshery on GitHub Codespace @AnnuCode (#6952) Fix the invalid link @pratik2315 (#7169) Thank you to our contributors for making this release possible: @AnnuCode, @dependabot, @leecalcote, @pratik2315 and @sudo-NithishKarthik
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_revoke_role.md

title: REVOKE ROLE statement [YCQL] headerTitle: REVOKE ROLE linkTitle: REVOKE ROLE description: Use the `REVOKE ROLE` statement to revoke a role (which represents a group of permissions and the SUPERUSER status) from another role. menu: v2.18: parent: api-cassandra weight: 1284 type: docs Use the `REVOKE ROLE` statement to revoke a role (which represents a group of permissions and the SUPERUSER status) from another role. This statement is enabled by setting the YB-TServer flag to `true`. <svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="331" height="35" viewbox="0 0 331 35"><path class="connector" d="M0 22h5m69 0h10m84 0h10m54 0h10m84 0h5"/><rect class="literal" x="5" y="5" width="69" height="25" rx="7"/><text class="text" x="15" y="22">REVOKE</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="84" y="5" width="84" height="25"/><text class="text" x="94" y="22">rolename</text></a><rect class="literal" x="178" y="5" width="54" height="25" rx="7"/><text class="text" x="188" y="22">FROM</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="242" y="5" width="84" height="25"/><text class="text" x="252" y="22">rolename</text></a></svg> ```ebnf revokerole ::= REVOKE ROLE rolename FROM role_name ``` Where `role_name` is a text identifier. Both roles must exist or an error will be raised. Permission `AUTHORIZE` on `ALL ROLES` or on the roles being used in the statement is necessary. Otherwise, an unauthorized error will be returned. You cannot revoke a role that hasn't been granted or an error will be raised. ```sql ycqlsh:example> REVOKE ROLE project_y from diana; ```
Project: KCL (Provisioning / Automation & Configuration)
File: README.md

Serde YAML ========== Rust library for using the [Serde] serialization framework with data in [YAML] file format. (This project is no longer maintained.) ```toml [dependencies] serde = "1.0" serde_yaml = "0.9" ``` Release notes are available under [GitHub releases]. but the general idea is: ```rust use std::collections::BTreeMap; fn main() -> Result<(), serde_yaml::Error> { // You have some type. let mut map = BTreeMap::new(); map.insert("x".to_string(), 1.0); map.insert("y".to_string(), 2.0); // Serialize it to a YAML string. // y is quoted to avoid ambiguity in parsers that might read it as `true`. let yaml = serdeyaml::tostring(&map)?; assert_eq!(yaml, "x: 1.0\n'y': 2.0\n"); // Deserialize it back to a Rust type. let deserializedmap: BTreeMap<String, f64> = serdeyaml::from_str(&yaml)?; asserteq!(map, deserializedmap); Ok(()) } ``` It can also be used with Serde's derive macros to handle structs and enums defined in your program. ```toml [dependencies] serde = { version = "1.0", features = ["derive"] } serde_yaml = "0.9" ``` Structs serialize in the obvious way: ```rust use serde::{Serialize, Deserialize}; struct Point { x: f64, y: f64, } fn main() -> Result<(), serde_yaml::Error> { let point = Point { x: 1.0, y: 2.0 }; let yaml = serdeyaml::tostring(&point)?; assert_eq!(yaml, "x: 1.0\n'y': 2.0\n"); let deserializedpoint: Point = serdeyaml::from_str(&yaml)?; asserteq!(point, deserializedpoint); Ok(()) } ``` Enums serialize using YAML's `!tag` syntax to identify the variant name. ```rust use serde::{Serialize, Deserialize}; enum Enum { Unit, Newtype(usize), Tuple(usize, usize, usize), Struct { x: f64, y: f64 }, } fn main() -> Result<(), serde_yaml::Error> { let yaml = " !Newtype 1 !Tuple [0, 0, 0] !Struct {x: 1.0, y: 2.0} "; let values: Vec<Enum> = serdeyaml::fromstr(yaml).unwrap(); assert_eq!(values[0], Enum::Newtype(1)); assert_eq!(values[1], Enum::Tuple(0, 0, 0)); assert_eq!(values[2], Enum::Struct { x: 1.0, y: 2.0 }); // The last two in YAML's block style instead: let yaml = " !Tuple 0 0 0 !Struct x: 1.0 y: 2.0 "; let values: Vec<Enum> = serdeyaml::fromstr(yaml).unwrap(); assert_eq!(values[0], Enum::Tuple(0, 0, 0)); assert_eq!(values[1], Enum::Struct { x: 1.0, y: 2.0 }); // Variants with no data can be written using !Tag or just the string name. let yaml = " Unit # serialization produces this one !Unit "; let values: Vec<Enum> = serdeyaml::fromstr(yaml).unwrap(); assert_eq!(values[0], Enum::Unit); assert_eq!(values[1], Enum::Unit); Ok(()) } ``` <br> <sup> Licensed under either of <a href="LICENSE-APACHE">Apache License, Version 2.0</a> or <a href="LICENSE-MIT">MIT license</a> at your option. </sup> <br> <sub> Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions. </sub>
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: pipeline-tuning.md

For a data processing pipeline, each vertex keeps running the cycle of reading data from an Inter-Step Buffer (or data source), processing the data, and writing to next Inter-Step Buffers (or sinks). It is possible to make some tuning for this data processing cycle. `readBatchSize` - How many messages to read for each cycle, defaults to `500`. `bufferMaxLength` - How many unprocessed messages can be existing in the Inter-Step Buffer, defaults to `30000`. `bufferUsageLimit` - The percentage of the buffer usage limit, a valid number should be less than 100. Default value is `80`, which means `80%`. These parameters can be customized under `spec.limits` as below, once defined, they apply to all the vertices and Inter-Step Buffers of the pipeline. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: limits: readBatchSize: 100 bufferMaxLength: 30000 bufferUsageLimit: 85 ``` They also can be defined in a vertex level, which will override the pipeline level settings. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: limits: # Default limits for all the vertices and edges (buffers) of this pipeline readBatchSize: 100 bufferMaxLength: 30000 bufferUsageLimit: 85 vertices: name: in source: generator: rpu: 5 duration: 1s name: cat udf: builtin: name: cat limits: readBatchSize: 200 # It overrides the default limit "100" bufferMaxLength: 20000 # It overrides the default limit "30000" for the buffers owned by this vertex bufferUsageLimit: 70 # It overrides the default limit "85" for the buffers owned by this vertex name: out sink: log: {} edges: from: in to: cat from: cat to: out ```
Project: ThreatMapper (Provisioning / Security & Compliance)
File: sensors.md

title: Sensor Agent ThreatMapper Sensors are deployed on your production platforms, directly on each production host. They are deployed in the form of a privileged container (the 'Sensor Agent'). They communicate securely with your ThreatMapper Management Console, taking instructions to retrieve SBOMs and run scans, and forwarding telemetry data. The sensors support the following production platforms: Kubernetes:* The sensors are deployed as a daemonset, similar to other kubernetes services. Docker:* The sensor is deployed as a docker container on each docker host. Bare metal and VM-based platforms:* Sensors are deployed as a Docker container on each Linux operating system instance, using a Docker runtime. Linux instances are supported; Windows Server is not supported, although an experimental implementation is available. AWS Fargate* The sensor is deployed as a daemon service alongside each serverless instance. :::info Refer to the Installation Documentation to :::
Project: Pulsar (App Definition and Development / Streaming & Messaging)
File: pip-325.md

In the current implementation of Pulsar Transaction, Topics ensure that consumers do not read messages belonging to uncommitted transactions through the Transaction Buffer. Within the Transaction Buffer, a Position (`maxReadPosition`) is maintained, as well as a set of aborted transactions (`aborts`). The `maxReadPosition` controls the maximum message position that the broker can read, and it is adjusted to the position just before the first message of the first ongoing transaction when a transaction is committed or aborted. Before distributing messages to consumers, the broker filters out messages that belong to already aborted transactions using the `aborts` set. If we have a stuck transaction, then the transactions after this one cannot be consumed by the consumer even if they have been committed. The consumer will be stuck until the stuck transaction is aborted due to timeout, and then it will continue to consume messages. Therefore, we need to add a command to allow cluster administrators to proactively abort transaction. Introduce a new API for aborting transactions, allowing administrators to proactively abort transaction. None. Introduce a new API for aborting transactions, allowing administrators to proactively abort transaction. Introduce a new API for aborting transactions, allowing administrators to proactively abort transaction. Add a new API to abort transaction: ``` / Abort a transaction. * @param txnID the txnId */ void abortTransaction(TxnID txnID) throws PulsarAdminException; / Asynchronously Abort a transaction. * @param txnID the txnId */ CompletableFuture<Void> abortTransactionAsync(TxnID txnID); ``` ``` admin.transactions().abortTransaction(txnID); ``` Add a command to abort transaction: ``` pulsar-admin transactions abort-transaction --most-sig-bits 1 --least-sig-bits 2 ``` None. None. The transaction owner and super user can access the admin API to abort the transaction. <!-- Updated afterwards --> Mailing List discussion thread: https://lists.apache.org/thread/ssgngyrlgx36zvygvsd5b2dm5q6krn0f Mailing List voting thread: https://lists.apache.org/thread/kp9w4d8drngomx1mdof0203ybgfmvtty