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

+++ title = "`BOOSTOUTCOMECOTRYV(expr)/BOOSTOUTCOMECOTRY(expr)`" description = "Evaluate from within a coroutine an expression which results in an understood type, continuing execution if successful, immediately returning `tryoperationreturn_as(X)` from the calling function if unsuccessful." +++ Evaluate from within a coroutine 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 `BOOSTOUTCOMECOTRYV(expr)` and `BOOSTOUTCOMECOTRY(expr)` editions is that the latter will set a variable if two or more macro arguments are present (see {{% api "BOOSTOUTCOMECO_TRY(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 "BOOSTOUTCOMECOTRYVFAILURE_LIKELY(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: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-volume-export.1.md

% podman-volume-export 1 podman\-volume\-export - Export volume to external tar podman volume export [options] volume podman volume export exports the contents of a podman volume and saves it as a tarball on the local machine. podman volume export writes to STDOUT by default and can be redirected to a file using the `--output` flag. Note: Following command is not supported by podman-remote. podman volume export [OPTIONS] VOLUME Print usage statement Write to a file, default is STDOUT Export named volume content into the specified file. ``` $ podman volume export myvol --output myvol.tar ``` , ,
Project: Chef InSpec (Provisioning / Security & Compliance)
File: zfs_pool.md

+++ title = "zfs_pool resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "zfs_pool" identifier = "inspec/resources/os/zfspool.md zfspool resource" parent = "inspec/resources/os" +++ Use the `zfs_pool` Chef InSpec audit resource to test the ZFS pools on FreeBSD & Linux (Centos, RHEL, Ubuntu, CloudLinux, Debian) systems. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.16.0 of InSpec. A `zfs_pool` resource block declares the ZFS pool properties that should be tested: describe zfs_pool('pool') do it { should MATCHER 'value' } end where: `('pool')` is the name of the ZFS pool (eg: `'tank'`) `MATCHER` is a valid matcher for this resource `'value'` is the value to be tested This Chef InSpec audit resource dynamically exposes all ZFS pool properties available (see: `man zpool` for the list of supported properties). The following examples show how to use this Chef InSpec audit resource. describe zfs_pool('tank') do its('autoexpand') { should eq 'off' } its('failmode') { should eq 'continue' } its('feature@lz4_compress') { should eq 'active' } its('health') { should eq 'ONLINE' } its('listsnapshots') { should eq 'off' } its('readonly') { should eq 'off' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: KICS (Provisioning / Security & Compliance)
File: 4f615f3e-fb9c-4fad-8b70-2e9f781806ce.md

title: DB Security Group Open To Large Scope hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 4f615f3e-fb9c-4fad-8b70-2e9f781806ce Query name: DB Security Group Open To Large Scope Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: The IP address in a DB Security Group must not have more than 256 hosts.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "awsdbsecurity_group" "positive1" { name = "rds_sg" ingress { cidr = "10.0.0.0/24" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsdbsecurity_group" "negative1" { name = "rds_sg" ingress { cidr = "10.0.0.0/25" } } ```
Project: Paralus (Provisioning / Security & Compliance)
File: ADOPTERS.md

Who is using it? Paralus community stands on the shoulders of individuals, companies, and maintainers. The Paralus team thanks everyone involved - from submitting bug reports and feature requests, to contributing patches and documentation. The Paralus community counts close to 20 members and is growing rapidly. The following list represents companies that have accompanied us along the way and that have made outstanding contributions to our ecosystem. If you think that your company deserves a spot here, reach out to support@paralus.io now! <table> <thead> <tr> <th>Type</th> <th>Name</th> <th>Logo</th> <th>Website</th> </tr> </thead> <tbody> </tbody> </table> <a href="https://github.com/paralus/paralus/graphs/contributors" target="_blank">Many thanks to all individual contributors</a> <em>\* Uses one of Paralus's major projects in production.</em> <!--END ADOPTERS-->
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: format.md

Control the format for the built image's manifest and configuration data. Recognized formats include oci (OCI image-spec v1.0, the default) and docker (version 2, using schema format 2 for the manifest). Note: You can also override the default format by setting the BUILDAH\_FORMAT environment variable. `export BUILDAH_FORMAT=docker`
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: extensions.md

Just by including the TechDocs Core Plugin to your MkDocs site included with Backstage, you gain the immediate use of a variety of popular plugins and extensions to MkDocs. For more information and full details of the available features, see the . This page provides a demonstration of some of the available features. Admonitions are call outs that help catch a users attention. To define an admonition simply put the following Markdown into your content: ``` !!! warn Defining admonitions can be addicting. ``` And they end up looking like this: <!-- prettier-ignore --> !!! warn Defining admonitions can be addicting. <!-- prettier-ignore --> !!! note You can learn a lot about TechDocs by just visiting the Backstage web site at https://backstage.io/docs. <!-- prettier-ignore --> !!! info TechDocs is the core feature that supports documentation as code in Backstage. <!-- prettier-ignore --> !!! tip Don't forget to spell check your documentation. You can create dynamic UML diagrams on the fly by just specifying flow via text, using . ```plantuml format="svg" classes="uml myDiagram" alt="Backstage sample PlantUML" title="Backstage sample PlantUML" width="500px" height="250px" User -> SCMProvider: stores TechDocs -> SCMProvider: prepares TechDocs -> TechDocs: generates TechDocs -> CloudStorage: publishes CloudStorage -> Backstage: displays ``` Pymdownx (Python Markdown extensions) are a variety of smaller additions. <!-- prettier-ignore --> ??? note "What is the answer to life, the universe, and everything? (click me for the answer)" The answer is 42. <!-- prettier-ignore --> ??? note "What is 4 plus 4?" The answer is 8. <!-- prettier-ignore --> ???+ note "How do I get support?" You can get support by opening an issue in this repository. This detail is open by default so it's more easily visible without requiring the user to click to open it. Automatic rendering of Markdown task lists. [x] Phase 1 [x] Phase 2 [ ] Phase 3 Very nice job on documentation! :thumbsup: I've read a lot of documentation, but I love :heart: this document. Weather: :sunny: :umbrella: :cloud: :snowflake: Animals: :tiger: :horse: :turtle: :wolf: :frog: {: download } {: style="width: 100px" } `attributes` `customer` `first_name` `test` `family_name` `email` `person` `first_name` `family_name` `birth_date` `subscription_id` `request`
Project: KICS (Provisioning / Security & Compliance)
File: 91bea7b8-0c31-4863-adc9-93f6177266c4.md

title: Stack Without Template hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 91bea7b8-0c31-4863-adc9-93f6177266c4 Query name: Stack Without Template Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Build Process URL: AWS CloudFormation should have a template defined through the attribute templateurl or attribute templatebody<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "awscloudformationstack" "positive1" { name = "networking-stack" parameters = { VPCCidr = "10.0.0.0/16" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awscloudformationstack" "negative1" { name = "networking-stack" parameters = { VPCCidr = "10.0.0.0/16" } template_url = "sometemplateurl" } resource "awscloudformationstack" "negative2" { name = "networking-stack" parameters = { VPCCidr = "10.0.0.0/16" } template_body = "sometemplatebody" } ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: etc_group.md

+++ title = "etc_group resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "etc_group" identifier = "inspec/resources/os/etcgroup.md etcgroup resource" parent = "inspec/resources/os" +++ Use the `etc_group` Chef InSpec audit resource to test groups that are defined on Linux and Unix platforms. The `/etc/group` file stores details about each group: group name, password, group identifier, along with a comma-separated list of users that belong to the group. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `etc_group` resource block declares a collection of properties to be tested: describe etc_group('path') do its('property') { should eq 'some_value' } end or: describe etc_group.where(item: 'value', item: 'value') do its('gids') { shouldnot containduplicates } its('groups') { should include 'user_name' } its('users') { should include 'user_name' } end where `('path')` is the non-default path to the `\etc\group` file `.where()` filters for a specific item and value, to which the parameter are compared `.where` filter may be one or more of: `name: 'name'`, `groupname: 'groupname'`, `password: 'password'`, `gid: 'gid'`, `groupid: 'gid'`, `users: 'username'`, `members: 'member_name'` The `gids` property returns the list of gids from `/etc/group` file. its('gids') { should include 'gid' } The `groups` property returns the list of groups from `/etc/group` file. its('groups') { should include 'my_group' } The `users` property returns the list of users from `/etc/group `file. its('users') { should include 'my_user' } The following examples show how to use this Chef InSpec audit resource. describe etc_group do its('gids') { shouldnot containduplicates } end describe etc_group do its('groups') { should include 'my_group' } end describe etc_group do its('users') { should include 'my_user' } end describe etcgroup.where(name: 'mygroup') do its('users') { should include 'my_user' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: StarRocks (App Definition and Development / Database)
File: CANCEL_EXPORT.md

displayed_sidebar: "English" Cancels a given data unloading job. Unloading jobs with the state `CANCELLED` or `FINISHED` cannot be canceled. Canceling an unloading job is an asynchronous process. You can use the statement to check whether an unloading job is successfully canceled. The unloading job is successfully canceled if the value of `State` is `CANCELLED`. The CANCEL EXPORT statement requires that you have at least one of the following privileges on the database to which the given unloading job belongs: `SELECTPRIV`, `LOADPRIV`, `ALTERPRIV`, `CREATEPRIV`, `DROPPRIV`, and `USAGEPRIV`. For more information about privilege descriptions, see . ```SQL CANCEL EXPORT [FROM db_name] WHERE QUERYID = "query_id" ``` | Parameter | Required | Description | | - | | | | db_name | No | The name of the databases to which the unloading job belongs. If this parameter is not specified, an unloading job in your current database is canceled. | | query_id | Yes | The query ID of the unloading job. You can obtain the ID by using the function. Note that this function only returns the latest query ID. | Example 1: Cancel an unloading job whose query ID is `921d8f80-7c9d-11eb-9342-acde48001121` in the current database. ```SQL CANCEL EXPORT WHERE queryid = "921d8f80-7c9d-11eb-9342-acde48001121"; ``` Example 2: Cancel an unloading job whose query ID is `921d8f80-7c9d-11eb-9342-acde48001121` in the `example_db` database. ```SQL CANCEL EXPORT FROM example_db WHERE queryid = "921d8f80-7c9d-11eb-9342-acde48001122"; ```
Project: Keycloak (Provisioning / Security & Compliance)
File: ADOPTERS.md

ADOPTERS ======== PUBLIC REFERENCES -- List of organization names below is based on information collected using Keycloak Community Survey. It contains company names from participants who agreed to serve as public reference. If organizations would like get added or removed please make a PR. Accenture Actinver Akvo Foundation AlmaLinux Foundation Appier Associazione Rousseau BISPRO Bluestem Brands, Inc Bundesagentur fr Arbeit Bundesversicherungsamt Capgemini CERN (European Organisation for Nuclear Research) Chassi CloudNative Inc. Conciso GmbH Copenhagen Optimization Curecomp GmbH Cybertech Devsu Devoxx / Voxxed DUENE e.V - project DukeCon European Synchrotron Radiation Facility Fluance AG Genchi Genbutsu SRL Hewlett-Packard Enterprise Hitachi INEAT Inventage ISAAC ITROI Solutions Kindly Ops, LLC msg systems ag Netdava International Ohio Supercomputer Center Okta PharmaPartners B.V. Plivo Price Insight Prodesan Quest Software Research Industrial Software Engineering (RISE) Sportsbet.com.au Stack Labs Storebrand Synekus Synetek Solutions Taklane TrackingSport TRT9 - Brasil UnitedHealthcare Wayfair LLC ...More individuals
Project: ThreatMapper (Provisioning / Security & Compliance)
File: support.md

title: Support and Diagnostics You can download recent log files from the management console, and from each sensor agent on each managed host. Access the Management Console Go to Settings > Diagnosis* Download the diagnostic logs from the management console, or from a selected sensor agent instance Please join the . For possible security issues, please refer to the . For bug reports, contributions and roadmap suggestions, please refer to the .
Project: YDB (App Definition and Development / Database)
File: operation-cancel.md

Use the `ydb operation cancel` subcommand to cancel the specified long-running operation. Only an incomplete operation can be canceled. General format of the command: ```bash {{ ydb-cli }} [global options...] operation cancel <id> ``` `global options`: . `options`: . `id`: The ID of the long-running operation. The ID contains characters that can be interpreted by your command shell. If necessary, use shielding, for example, `'<id>'` for bash. View a description of the command to obtain the status of a long-running operation: ```bash {{ ydb-cli }} operation cancel --help ``` {% include %}
Project: TiKV (App Definition and Development / Database)
File: README.md

This directory contains TiKV fuzz test cases as well as a custom CLI utility, `fuzz`, that builds and runs those tests using one of multiple fuzzers. Supported fuzzers: ```sh cargo install honggfuzz --version 0.5.47 ``` Note that the version of the cargo plugin installed must be the same as the library linked by the `fuzzer-honggfuzz` project template, here 0.5.47. Building honggfuzz test cases with `cargo run -p fuzz -- run Honggfuzz <test>` requires additional development libraries that will differ from system to system. On a recent Ubuntu system those libraries could be installed with `sudo apt install binutils-dev libunwind-dev`. See . ```sh cargo install afl ``` For more details, see . Proper seeds can make fuzzing faster, seed files for a specific target should be placed in the `fuzz/common/seeds/{target}/` directory, where `target` is the fuzz target name. If no seed file provided for the given target, `fuzz/common/seeds/default/` will be used as seeds. ```bash cargo run --package fuzz -- list-targets ``` ```bash cargo run --package fuzz -- run [FUZZER] [TARGET] ``` Valid values for `[FUZZER]` are "Libfuzzer", "Honggfuzz", and "Afl". The corpus dir of fuzzing is `fuzz/fuzzer-{FUZZER}/corpus-{TARGET}` for "Libfuzzer" and "Afl".
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.11.2.md

This update contains security fixes: () () Additionally, this patch release contains bug fixes: - A high-severity vulnerability has been found in Dapr that allows bypassing , which is used by the Dapr sidecar to authenticate calls coming from the application, with a well-crafted HTTP request. The vulnerability impacts all users on Dapr <=1.10.9 and <=1.11.2 who are using API token authentication. The Dapr sidecar allowed all requests containing `/healthz` in the URL (including query string) to bypass API token authentication. We have changed the API token authentication middleware to allow bypassing the authentication only for healthcheck endpoints more strictly. An issue in the third-party avro dependency could cause a resource exhaustion and a DoS for Dapr. This issue impacts users of Dapr that use the Pulsar components. The issue was in a third-party dependency. We have upgraded the avro dependency to version 2.13.0 which contains a fix for the reported issue. Due to a bug in the workflow engine, the full workflow history was saved on each checkpoint, rather than only the deltas. This resulted in two problems: The I/O cost of saving workflow state increased over the lifetime of the workflow Using state stores which have limits on transaction batch sizes, for example Azure Cosmos DB, caused workflows with more than a few actions to fail permanently The issue impacts users of Dapr Workflow on Dapr 1.10 and higher. The problem was caused by a coding issue: an object was passed by reference rather than as a pointer. We fixed the issue in the source code and added new tests to prevent regressions. In some Kubernetes clusters, the workflow engine may not have been able to process work items and tasks that were part of a workflow. Calls to the workflow engine would time out and fail. The issue impacts users of Dapr Workflows which run the Dapr gRPC server listening on more than one address. This is the default behavior on Kubernetes, where Dapr normally listens on both `127.0.0.1` (IPv4) an `[::1]` (IPv6). The issue can appear also outside of Kubernetes if users run Dapr with multiple values for `--dapr-listen-addresses`. A new instance of the workflow engine was attached to each Dapr gRPC listener independently. Depending on what protocol the application was using to connect to Dapr (IPv4 or IPv6), the request could hit a workflow engine that was not currently processing tasks, causing a deadlock. We have changed the initialization code to ensure that Dapr uses a single instance of the workflow engine across all listeners. We identified a number of bugs, especially race conditions, in the gRPC implementation for the Configuration Subscribe API, which became stable in Dapr 1.11.0. These bugs could have caused the Subscribe API to behave unexpectedly. The issue can impact users that are invoking the Configuration building block APIs using gRPC. The issues were traced back to a number of race conditions in the way the gRPC stream was handled. We refactored the code to remove the race conditions and fix the bugs.
Project: Flink (App Definition and Development / Streaming & Messaging)
File: debugging_event_time.md

title: "Debugging Windows & Event Time" weight: 2 type: docs aliases: /ops/debugging/debuggingeventtime.html /monitoring/debuggingeventtime.html <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Flink's and watermark support are powerful features for handling out-of-order events. However, it's harder to understand what exactly is going on because the progress of time is tracked within the system. Low watermarks of each task can be accessed through Flink web interface or . Each Task in Flink exposes a metric called `currentInputWatermark` that represents the lowest watermark received by this task. This long value represents the "current event time". The value is calculated by taking the minimum of all watermarks received by upstream operators. This means that the event time tracked with watermarks is always dominated by the furthest-behind source. The low watermark metric is accessible using the web interface, by choosing a task in the metric tab, and selecting the `<taskNr>.currentInputWatermark` metric. In the new box you'll now be able to see the current low watermark of the task. Another way of getting the metric is using one of the metric reporters, as described in the documentation for the . For local setups, we recommend using the JMX metric reporter and a tool like . Approach 1: Watermark stays late (indicated completeness), windows fire early Approach 2: Watermark heuristic with maximum lateness, windows accept late data {{< top >}}
Project: ClickHouse (App Definition and Development / Database)
File: v22.7.4.16-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : fix HashMethodOneNumber get wrong key value when column is const. (). Backported in : Fix bug in collectFilesToSkip() by adding correct file extension(.idx or idx2) for indexes to be recalculated, avoid wrong hard links. Fixed . (). Backported in : A segmentation fault that has CaresPTRResolver::resolve in the stack trace has been reported:. (). Backported in : Fix insufficient argument check for encryption functions (found by query fuzzer). This closes . (). Backported in : Fix possible segfault in CapnProto input format. This bug was found and send through ClickHouse bug-bounty by kiojj*. (). Fix a bug with symlinks detection (). fix heap buffer overflow by limiting http chunk size (). Reduce changelog verbosity in CI ().