cwielenb/CNCF-Dataset huggingface dataset:
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: meshery_designs_repositories.md

Meshery designs repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path/to/packages provided can contain metadata for one or more packages. Each package version must be on a separate folder, and it's up to you to decide if you want to publish one or multiple versions of your package. The structure of a repository with multiple designs packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml design.yml 2.0.0 README.md artifacthub-pkg.yml design.yml package2 1.0.0 README.md artifacthub-pkg.yml design.yml ``` This structure is flexible, and in some cases where you only have a package and a version it can be greatly simplified. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml design.yml ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file for more details. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. In addition to the Artifact Hub metadata file, each version must include a `design.yml` file that will describe all the resources and properties of the design. Once you have added your repository, you are all set up. As you add new versions of your designs packages or new packages to your git repository, they'll be automatically indexed and listed in Artifact Hub.
Project: kube-hunter (Provisioning / Security & Compliance)
File: KHV032.md

vid: KHV032 title: Etcd Remote Read Access Event categories: [Access Risk] severity: critical Etcd (Kubernetes' Database) is accessible without authentication. This exposes the entire state of your Kubernetes cluster to the reader. Ensure your etcd is accepting connections only from the Kubernetes API, using the `--trusted-ca-file` etcd flag. This is usually done by the installer, or cloud platform.
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.8.17.md

RabbitMQ `3.8.17` is a maintenance release that includes a security patch. This release addresses an undisclosed vulnerability with CVSS 3.1 (low): . Our team would like to thank Christian Rellmann from for the vulnerability and helping us verify a fix. RabbitMQ releases are distributed via , , and . This release and . explains what package repositories and tools can be used to provision modern Erlang versions. See the for general documentation on upgrades and for release notes of other releases. If upgrading from a`3.7.x` release, see upgrade and compatibility notes first. If upgrading from a `3.6.x` or older , first upgrade to and then to this version. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . Queue index efficiency improvements, mostly around peak memory consumption with large backlogs of small messages. Note that some of the improvements come from more optimal defaults: those will only be applicable to newly created virtual hosts (or new clusters). GitHub issues: , default has been bumped to 30 minutes (previously 15 minutes). The value can be overridden. GitHub issue: A classic queue with option enabled could run into an exception after a restart or initial enablement of the management plugin. GitHub issue: A combination of HTTPS (TLS) settings and advanced HTTP server settings resulted in an exception. GitHub issue: External stats collector is now restarted again if it fails for any reason. Contributed by @luos. GitHub issue: When nodes are restarted, schema database tables used by this plugin are now reconciled with cluster peers the . GitHub issue: When nodes are restarted, schema database tables used by this plugin are now reconciled with cluster peers the . GitHub issue: When nodes are restarted, schema database tables used by this plugin are now reconciled with cluster peers the . Contributed by @mwfriedm. GitHub issue: When nodes are restarted, schema database tables used by this plugin are now reconciled with cluster peers the . GitHub issue: MQTT-over-WebSockets client connections were not accounted for by the file handle tracking mechanism (metric and resource alarm). GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.8.17.tar.xz` instead of the source tarball produced by GitHub.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: plugin_kitchen_inspec.md

+++ title = "About kitchen-inspec" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "kitchen-inspec" identifier = "inspec/chef/kitchen-inspec" parent = "inspec/chef" weight = 10 +++ Use Chef InSpec as a verifier with `kitchen-inspec`. For hands-on examples, learn how to use Test Kitchen to run Chef InSpec profiles on the Learn Chef course . Add the Chef InSpec verifier to the `.kitchen.yml` file: ```yaml verifier: name: inspec ``` Use a compliance profile from the Chef Compliance server: ```yaml suites: name: compliance run_list: recipe[ssh-hardening::default] verifier: inspec_tests: compliance://base/ssh ``` and then run the following command: ```bash inspec automate login https://compliance.test --user admin --insecure --token '' ``` where: `--insecure` is required when using self-signed certificates. `inspec compliance` is a backwards compatible alias for `inspec automate` and works the same way: ```bash inspec compliance login https://compliance.test --user admin --insecure --token '' ``` Use a compliance profile from the Chef Supermarket: ```yaml suites: name: supermarket run_list: recipe[ssh-hardening::default] verifier: inspec_tests: supermarket://dev-sec/ssh-baseline ``` Use Chef InSpec tests from the local file system: ```yaml suites: name: local run_list: recipe[my_cookbook::default] verifier: inspec_tests: test/integration/default ```
Project: KICS (Provisioning / Security & Compliance)
File: 132a8c31-9837-4203-9fd1-15ca210c7b73.md

title: SSO Policy with full privileges hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 132a8c31-9837-4203-9fd1-15ca210c7b73 Query name: SSO Policy with full privileges Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: SSO policies should be configured to grant limited administrative privileges, rather than full access to all resources. This approach allows for better security and control over the resources being accessed.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="4" resource "awsssoadminpermissionsetinline_policy" "pos1" { instancearn = awsssoadminpermissionset.example.instance_arn permissionsetarn = awsssoadminpermission_set.example.arn inline_policy = <<POLICY { "Statement": [ { "Action": [ "*" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "" }, { "Action": "s3:PutObject*", "Effect": "Allow", "Resource": "arn:aws:s3:::b1/*", "Sid": "" } ], "Version": "2012-10-17" } POLICY } ``` ```tf title="Negative test num. 1 - tf file" resource "awsssoadminpermissionsetinline_policy" "neg1" { instancearn = awsssoadminpermissionset.example.instance_arn permissionsetarn = awsssoadminpermission_set.example.arn inline_policy = <<POLICY { "Statement": [ { "Action": [ "s3:ListBucket*", "s3:HeadBucket", "s3:Get*" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::b1", "arn:aws:s3:::b1/*", "arn:aws:s3:::b2", "arn:aws:s3:::b2/*" ], "Sid": "" }, { "Action": "s3:PutObject*", "Effect": "Allow", "Resource": "arn:aws:s3:::b1/*", "Sid": "" } ], "Version": "2012-10-17" } POLICY } ```
Project: SPIFFE (Provisioning / Key Management)
File: DAN_FELDMAN.md

Daniel has been involved in SPIFFE almost since it's inception (2018), and has become a tireless advocate for the community since then. He is active daily in a number of Slack channels around the project, as well as a frequent contributor and speaker. He has played an active role in driving a number of SPIFFE migrations for organisations and teams of significant size. Behind the scenes, he's been an advocate for improving the usability and accessibility of SPIRE, something the project can certainly benefit from. I can think of few more qualified people to be a community steward and SSC member. GitHub Handle: @d_feldman Email Address: dfeldman.mn@gmail.com LinkedIn Profile: https://www.linkedin.com/in/dfeldman Current Affiliation: Hewlett Packard Enterprise
Project: ShardingSphere (App Definition and Development / Database)
File: alter-default-sharding-strategy.en.md

+++ title = "ALTER DEFAULT SHARDING STRATEGY" weight = 5 +++ The `ALTER DEFAULT SHARDING STRATEGY` syntax is used to alter a default sharding strategy {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterDefaultShardingStrategy ::= 'ALTER' 'DEFAULT' 'SHARDING' ('DATABASE' | 'TABLE') 'STRATEGY' '(' shardingStrategy ')' shardingStrategy ::= 'TYPE' '=' strategyType ',' ('SHARDINGCOLUMN' '=' columnName | 'SHARDINGCOLUMNS' '=' columnNames) ',' 'SHARDING_ALGORITHM' '=' algorithmDefinition strategyType ::= string algorithmDefinition ::= 'TYPE' '(' 'NAME' '=' algorithmType ',' propertiesDefinition ')' columnNames ::= columnName (',' columnName)+ columnName ::= identifier algorithmType ::= string propertiesDefinition ::= 'PROPERTIES' '(' key '=' value (',' key '=' value)* ')' key ::= string value ::= literal ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} When using the complex sharding algorithm, multiple sharding columns need to be specified using `SHARDING_COLUMNS`; `algorithmType` is the sharding algorithm type. For detailed sharding algorithm type information, please refer to . Alter a default sharding table strategy ```sql ALTER DEFAULT SHARDING TABLE STRATEGY ( TYPE="standard", SHARDINGCOLUMN=userid, SHARDINGALGORITHM(TYPE(NAME="inline", PROPERTIES("algorithm-expression"="torder${userid % 2}"))) ); ``` `ALTER`, `DEFAULT`, `SHARDING`, `DATABASE`, `TABLE`, `STRATEGY`, `TYPE`, `SHARDINGCOLUMN`, `SHARDINGCOLUMNS`, `SHARDING_ALGORITHM`, `NAME`, `PROPERTIES`
Project: TDengine (App Definition and Development / Database)
File: Small_Materialized_Aggrates.md

SMA (Small Materialized Aggrates) is used to speed up the query process on materialized data cube in TDengine. TDengine 3.0 gives more flexibility on the SMA configurations. There are two kinds of SMA in TDengine: Block-wise SMA Time-range-wise SMA <!-- ```plantuml @startmindmap mindmaptest SMA Block-wise SMA Time-range-wise SMA @endmindmap ``` --> Block-wise SMA is created by default when the data are committed. Since time-series data are saved as block data in files, a corresponding SMA is create when the data block is written. The default block-wise SMA includes: sum(*) max(*) min(*) By default, the system will create SMA for each column except those columns with type binary and nchar. However, users can change the behavior by the keyword NOSMA to disable the SMA for a certain column like below: ```SQL create table st (ts timestamp, a int, b int NOSMA, c double) tags (tg1 binary(10), tg2 int); ``` In addition to the default block-wise SMA, users can create their own SMAs ondemand. Below is an example to create a SMA. ```SQL create smaindx sma10min on st (sum(), max(), min(), twa()) interval(10m); ``` Users can also drop a time-range-wise SMA like below: ```SQL drop smaindex sma5min on st; ``` NOTE: Creating an SMA index is a heavy operation which may take a long time and block the write operation. So create the time-range-wise SMA when creating the table or when there are not too much data.
Project: ClickHouse (App Definition and Development / Database)
File: sum.md

slug: /en/sql-reference/aggregate-functions/reference/sum sidebar_position: 4 Calculates the sum. Only works for numbers. Syntax ```sql sum(num) ``` Parameters `num`: Column of numeric values. , , . Returned value The sum of the values. , , . Example First we create a table `employees` and insert some fictional employee data into it. Query: ```sql CREATE TABLE employees ( `id` UInt32, `name` String, `salary` UInt32 ) ENGINE = Log ``` ```sql INSERT INTO employees VALUES (87432, 'John Smith', 45680), (59018, 'Jane Smith', 72350), (20376, 'Ivan Ivanovich', 58900), (71245, 'Anastasia Ivanovna', 89210); ``` We query for the total amount of the employee salaries using the `sum` function. Query: ```sql SELECT sum(salary) FROM employees; ``` Result: ```response sum(salary) 266140 ```
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: setup-opentelemetry.md

id: setup-opentelemetry title: Setup OpenTelemetry description: Tutorial to setup OpenTelemetry metrics and traces exporters in Backstage Backstage uses to instrument its components by reporting traces and metrics. This tutorial shows how to setup exporters in your Backstage backend package. For demonstration purposes we will use a Prometheus exporter, but you can adjust your solution to use another one that suits your needs; see for example the article on . We will use the OpenTelemetry Node SDK and the `auto-instrumentations-node` packages. Backstage packages, such as the catalog, use the OpenTelemetry API to send custom traces and metrics. The `auto-instrumentations-node` will automatically create spans for code called in libraries like Express. ```bash yarn --cwd packages/backend add \ @opentelemetry/sdk-node \ @opentelemetry/auto-instrumentations-node \ @opentelemetry/exporter-prometheus ``` In your `packages/backend/src` folder, create an `instrumentation.js` file. ```typescript title="in packages/backend/src/instrumentation.js" const { NodeSDK } = require('@opentelemetry/sdk-node'); const { getNodeAutoInstrumentations, } = require('@opentelemetry/auto-instrumentations-node'); const { PrometheusExporter } = require('@opentelemetry/exporter-prometheus'); const prometheus = new PrometheusExporter(); const sdk = new NodeSDK({ // You can add a traceExporter field here too metricReader: prometheus, instrumentations: [getNodeAutoInstrumentations()], }); sdk.start(); ``` You probably won't need all of the instrumentation inside `getNodeAutoInstrumentations()` so make sure to check the and tweak it properly. It's important to setup the NodeSDK and the automatic instrumentation before importing any library. This is why we will use the nodejs flag when we start up the application. For local development, you can add the required flag in your `packages/backend/package.json`. ```json title="packages/backend/package.json" "scripts": { "start": "backstage-cli package start --require ./src/instrumentation.js", ... ``` You can now start your Backstage instance as usual, using `yarn dev`. In your `Dockerfile`, copy `instrumentation.js` file into the root of the working directory. ```Dockerfile COPY --chown=${NOTROOTUSER}:${NOTROOTUSER} packages/backend/src/instrumentation.js ./ ``` And then add the `--require` flag that points to the file to the CMD array. ```Dockerfile // highlight-remove-next-line CMD ["node", "packages/backend", "--config", "app-config.yaml"] // highlight-add-next-line CMD ["node", "--require", "./instrumentation.js", "packages/backend", "--config", "app-config.yaml"] ``` If you need to disable/configure some OpenTelemetry feature there are lots of which you can tweak.
Project: ClickHouse (App Definition and Development / Database)
File: v23.4.3.48-stable.md

sidebar_position: 1 sidebar_label: 2023 Backported in : Revert "`groupArray` returns cannot be nullable" (due to binary compatibility breakage for `groupArray`/`groupArrayLast`/`groupArraySample` over `Nullable` types, which likely will lead to `TOOLARGEARRAYSIZE` or `CANNOTREADALLDATA`). (). Fix key not found error for queries with multiple StorageJoin (). Fix fuzz bug when subquery set is not built when reading from remote() (). Fix postgres database setting (). Fix AsynchronousReadIndirectBufferFromRemoteFS breaking on short seeks (). Fix bug in DISTINCT (). Fix assert in SpanHolder::finish() with fibers (). Fix msan issue in randomStringUTF8(<uneven number>) (). fix `is_prefix` in OptimizeRegularExpression (). Fix IPv6 encoding in protobuf (). Avoid deadlock when starting table in attach thread of `ReplicatedMergeTree` (). Fix assert in SpanHolder::finish() with fibers attempt 2 (). JIT compilation not equals NaN fix (). Fix crashing in case of Replicated database without arguments (). Fix crash with `multiIf` and constant condition and nullable arguments (). Fix iceberg metadata parsing (). Fix bugs in Poco sockets in non-blocking mode, use true non-blocking sockets (). Fixed type conversion from Date/Date32 to DateTime64 when querying with DateTime64 index (). Fix Keeper deadlock on exception when preprocessing requests. (). Fix Log family table return wrong rows count after truncate (). Fix bug in `uniqExact` parallel merging (). Do not read all the columns from right GLOBAL JOIN table. (). Improve CI: status commit, auth for getghapi (). Update github.com/distribution/distribution (). Catch issues with dockerd during the build ().
Project: Seata (App Definition and Development / Database)
File: FEATURE_REQUEST.md

name: Feature Request about: Suggest an idea for Seata <!-- Please do not use this issue template to report security vulnerabilities but refer to our . --> Is your feature request related to a problem? Please describe in details A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it. Add any other context or screenshots about the feature request here.
Project: ArangoDB (App Definition and Development / Database)
File: co_await.md

+++ title = "`operator co_await` as TRY operator" weight = 40 tags = [ "coroutines", "co_await" ] +++ Many people have requested that `operator co_await` be overloaded to behave as a TRY operator when supplied with an Outcome type. Outcome does not implement that extension, nor will we accept PRs contributing support for this. We think you should use `BOOSTOUTCOMECO_TRY()` as this will lead to more maintainable and future proof code. However, we deliberately do not get in the way of you implementing that overload yourself in your own Outcome-based code. Just be sure that you document what you are doing loudly and clearly, and be aware that future C++ standards may have a proper `operator try` overload mechanism.
Project: Beam (App Definition and Development / Streaming & Messaging)
File: 07_io_json.md

Prompt: Write a sample Java code snippet that writes data to a JSON file using Apache Beam. Response: Your Apache Beam pipeline can write data to JSON files using the Apache Beam JsonIO connector. Here is an example of how to use the JsonIO connector to accomplish this: ```java package gcs; import org.apache.beam.sdk.Pipeline; import org.apache.beam.sdk.io.json.JsonIO; import org.apache.beam.sdk.options.Description; import org.apache.beam.sdk.options.PipelineOptions; import org.apache.beam.sdk.options.PipelineOptionsFactory; import org.apache.beam.sdk.options.Validation; import org.apache.beam.sdk.schemas.JavaFieldSchema; import org.apache.beam.sdk.schemas.annotations.DefaultSchema; import org.apache.beam.sdk.transforms.Create; import java.io.Serializable; import java.util.Arrays; import java.util.List; // Pipeline for writing data to JSON files using the `JsonIO.write()` transform. public class WriteJsonIO { // Represents an Example JSON record. @DefaultSchema(JavaFieldSchema.class) public static class SampleRecord implements Serializable { public int id; public String month; public String amount public SampleRecord() { } public SampleRecord(int id, String month, String amount) { this.id = id; this.month = month; this.amount = amount; } } // Pipeline options for writing to JSON files. public interface WriteJsonOptions extends PipelineOptions { @Description("A file path to write JSON files to") @Validation.Required String getFilePath(); // Set the file path. void setFilePath(String filePath); } // Main entry point. public static void main(String[] args) { // Get the pipeline options. WriteJsonOptions options = PipelineOptionsFactory.fromArgs(args) .withValidation().as(WriteJsonOptions.class); // Create the pipeline. Pipeline p = Pipeline.create(options); // Create a list of SampleRecord objects. List<SampleRecord> rows = Arrays.asList( new SampleRecord(1, "January", "$1000"), new SampleRecord(2, "February", "$2000"), new SampleRecord(3, "March", "$3000")); // Write the records to JSON files p.apply("Create Records", Create.of(rows)) .apply( "Write Records to JSON File", JsonIO.<SampleRecord>write(options.getFilePath()) .withNumShards(1)); // Run the pipeline. p.run(); } } ``` This code snippet utilizes the pipeline options pattern to parse command-line arguments.
Project: StarRocks (App Definition and Development / Database)
File: IMAGES_README.md

To use the media gallery, you must upload a minimum of one image. The gallery can hold a maximum of 8 pieces of media total, and one of these pieces of media can be a video (guidelines and submission steps below). Images should be added to your /images directory and referenced in the manifest.json file. ``` File type : .jpg or .png File size : ~500 KB per image, with a max of 1 MB per image File dimensions : The aspect ratio must be 16:9 minimum, with these constraints: Width: 1440px Min height: 810px Max height: 2560px File name : Use only letters, numbers, underscores, and hyphens Color mode : RGB Color profile : sRGB Description : 300 characters maximum ``` To display a video in your media gallery, please send our team the zipped file or a link to download the video at `marketplace@datadog.com`. In addition, please upload a thumbnail image for your video as a part of the pull request. Once approved, we will upload the file to Vimeo and provide you with the vimeo_id to add to your manifest.json file. Please note that the gallery can only hold one video. ``` File type : MP4 H.264 File size : Max 1 video; 1 GB maximum size File dimensions : The aspect ratio must be exactly 16:9, and the resolution must be 1920x1080 or higher File name : partnerName-appName.mp4 Run time : Recommendation of 60 seconds or less Description : 300 characters maximum ```