cwielenb/CNCF-Dataset huggingface dataset:
Project: Beam (App Definition and Development / Streaming & Messaging)
File: BUILD.md

<!-- 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. --> This document describes the code layout and build integration with Gradle. Goals: Go code can be built and tested using Gradle w/o special requirements. Go tools such as `go build`, `go test` and `go generate` work as usual. Go code can be pulled with `go get` from `github.com/apache/beam` for users. Go programs can used in docker container images. In short, the goals are to make both worlds work well. Beam publishes a single Go Module for SDK developement and usage, in the `sdks` directory. This puts all Go code necessary for user pipeline development and for execution under the same module. This includes container bootloader code in the Java and Python SDK directories. Pipeline authors will require a dependency on `github.com/apache/beam/sdks/v2` in their `go.mod` files to use beam. To integrate with Gradle, we use a gradle plugin called GoGradle. However, we disable GoGradle vendoring in favour of using Go Modules for dependency management. GoGradle handles invoking the go toolchain or gradle and jenkins, using the same dependencies as SDK contributors and users. For the rare Go binary, such as the container boot loaders, it should be possible to build the same binary with both Gradle and the usual Go tool. The container build adds a small twist to the build integration, because container images use linux/amd64 but the development setup might not. We therefore additionally cross-compile Go binaries for inclusion into container images where needed, generally placed in `target/linux_amd64`. To develop the SDK, it should be sufficient to clone the repository, make changes and execute tests from within the module directory (`<repo>/sdks/...`). Go users can just `go get` the code directly. For example: ``` go get github.com/apache/beam/sdks/v2/go/pkg/beam ``` Developers must invoke Go for cross-compilation manually, if desired. If you make changes to .proto files, you will need to rebuild the generated code. Consult `pkg/beam/model/PROTOBUF.md`. If you make changes to .tmpl files, then add the specialize tool to your path. You can install specialize using: ``` go get github.com/apache/beam/sdks/v2/go/cmd/specialize ``` Add it to your path: ``` export PATH=$PATH:$GOROOT/bin:$GOPATH/bin ```
Project: StarRocks (App Definition and Development / Database)
File: uuid.md

displayed_sidebar: "English" Returns a random UUID of the VARCHAR type. Two calls to this function can generate two different numbers. The UUID is 36 characters in length. It contains 5 hexadecimal numbers which are connected with four hyphens in the aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format. ```Haskell uuid(); ``` None Returns a value of the VARCHAR type. ```Plain Text mysql> select uuid(); +--+ | uuid() | +--+ | 74a2ed19-9d21-4a99-a67b-aa5545f26454 | +--+ 1 row in set (0.01 sec) ```
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_cluster_list-accounts.md

title: kbcli cluster list-accounts List accounts for a cluster ``` kbcli cluster list-accounts [flags] ``` ``` kbcli cluster list-accounts CLUSTERNAME --component COMPNAME kbcli cluster list-accounts CLUSTERNAME kbcli cluster list-accounts --instance INSTANCE ``` ``` --component string Specify the name of component to be connected. If not specified, pick the first one. -h, --help help for list-accounts -i, --instance string Specify the name of instance to be connected. ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "$HOME/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use ``` - Cluster command.
Project: LinuxKit (Provisioning / Automation & Configuration)
File: platform-aws.md

This is a quick guide to run LinuxKit on AWS. Before you proceed it's recommended that you set up the and perform an `aws configure` If you do not wish to install these tools you should ensure that you set the AWS You will need to create an Amazon S3 Storage Bucket for your LinuxKit images and create a VM Import Service Role. Instructions on how to do this can be found . Finally, you must set the `AWS_REGION` environment variable as this is used by the AWS Go SDK. ``` export AWS_REGION=eu-west-1 ``` AWS requires a `RAW` image. To create one: ``` $ linuxkit build -format aws examples/aws.yml ``` Before you do this you need to create a `vmimport` service role as explained in . Do `linuxkit push aws -bucket bucketname aws.raw` to upload it to the specified bucket, and create a bootable image from the stored image. Alternatively, you can use the `AWS_BUCKET` environment variable to specify the bucket name. Note: If the push times out before it finishes, you can use the `-timeout` flag to extend the timeout. You may also want to consider passing `-ena` to enable enhanced networking in the AMI. ``` linuxkit push aws -bucket bucketname -timeout 1200 aws.raw ``` With the image created, we can now create an instance. You won't be able to see the serial console output until after it has terminated. ``` linuxkit run aws -security-group "<securitygroupid>" aws ``` You can edit the AWS example to allow you to SSH to your instance in order to use it.
Project: YugabyteDB (App Definition and Development / Database)
File: yba_provider_aws_list.md

List AWS YugabyteDB Anywhere providers List AWS YugabyteDB Anywhere providers ``` yba provider aws list [flags] ``` ``` -h, --help help for list ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the provider for the action. Required for create, delete, describe, update. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage a YugabyteDB Anywhere AWS provider
Project: ArangoDB (App Definition and Development / Database)
File: README.md

See the `gdbinit` files (e.g. `./utils/gdb-pretty-printers/immer/gdbinit`) for an example to write in your `~/.gdbinit` to load the pretty printers. Copy its content to (the end of your) `~/.gdbinit` file, and adapt the path passed to `sys.path.insert`. Run `./utils/buildandrun_tests.sh` to test the pretty printers. The tests currently don't run automatically in the CI. I've tested them only on Linux. It's to be expected that the tests might break if not built with `CMAKEBUILDTYPE=Debug` (we're testing `gdb`, after all). The tests also rely on a pretty-printer for `std::string` of the installed stdlib to be installed, and to pretty-print a `std::string{"hello, world"}` as `"hello, world"` (the ones I have for `libstdc++` and `libc++` both do). The `flexvectortest` is executed by `ctest`, and consists of two files. `flexvectortest.cpp`, which sets up both `testee` and `expected` data structures. And `flexvectortest.gdbscript`, which runs the `flex_vector` pretty printer on each `testee` and compares it to `expected`. Currently there's only one pretty printer, for `immer::flex_vector` (to be precise, there's also one for `immer::details::rbts::rrbtree`, which is the implementation of `immer::flex_vector`). We might want to include the existing VelocyPack one, and possibly add more later.
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: docker_automated_flow.md

+++ title = "Automate Docker Container Publishing Flow" description = "Automate Docker Container Publishing Flow" gh_repo = "habitat" [menu] [menu.habitat] title = "Automated Docker Container Publishing Flow" identifier = "habitat/diagrams/docker-automated-flow" parent = "habitat/diagrams" weight = 60 +++
Project: YugabyteDB (App Definition and Development / Database)
File: disaster-recovery-failover.md

title: Unplanned failover with disaster recovery headerTitle: Unplanned failover linkTitle: Failover description: Unplanned failover using disaster recovery headContent: Failover of application traffic to the DR replica menu: stable_yugabyte-platform: parent: disaster-recovery identifier: disaster-recovery-failover weight: 30 type: docs Unplanned failover is the process of switching application traffic to the DR replica universe in case the DR primary universe becomes unavailable. One of the common reasons for such a scenario is an outage of the primary region. Use the following procedure to perform an unplanned failover to the DR replica and resume applications. If the DR primary is terminated for some reason, do the following: Stop the application traffic to ensure no more updates are attempted. Navigate to your DR primary universe and select xCluster Disaster Recovery. Note the Potential data loss on failover to understand the extent of possible data loss as a result of the outage, and determine if the extent of data loss is acceptable for your situation. The potential data loss is computed as the safe time lag that existed at the current safe time on the DR replica. Use the Tables tab to understand which specific tables have the highest safe time lag and replication lag. For more information on replication metrics, refer to . To proceed, click Actions and choose Failover. Enter the name of the DR replica and click Initiate Failover. YugabyteDB Anywhere switches the DR replica universe to be the DR primary. Resume the application traffic on the new DR primary. At this point, the DR configuration is halted and needs to be repaired. There are two options to repair a DR that has failed over: If the original DR primary has recovered and is fully functional with no active alerts, you can configure DR to use this universe as a DR replica. If the original DR primary cannot be recovered, create a new universe to be configured to act as the DR replica (see ). In both cases, repairing DR involves making a full copy of the databases through the backup-restore process. To repair DR, do the following: Navigate to your (new) DR primary universe and select xCluster Disaster Recovery. Click Repair DR. If the original DR primary has recovered and is fully functional with no active alerts, choose Reuse the current DR replica. To use a new universe as the DR replica, choose Select a new universe as DR replica and select the universe. Click Initiate Repair. If your eventual desired configuration is for the other universe (that is, the one you have added to DR to act as DR replica) to be the DR primary, follow the steps for .
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.0-beta-2.md

layout: release date: 2023-12-04 tag: v0.7.0-beta-2 [policies] Improve support for policies evaluation. @MUzairS15 (#9517) Add missing Watch-List configuration on Meshery Helm Chart CRD @KiptoonKipkurui (#9562) Thank you to our contributors for making this release possible: @KiptoonKipkurui, @MUzairS15, @leecalcote and @sudhanshutech
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.9.10.md

RabbitMQ `3.9.10` is a maintenance release in the `3.9.x` release series. Please refer to the Upgrading to 3.9 section from if upgrading from a version prior to 3.9.0. This release requires at least Erlang 23.2, and supports Erlang 24. has more details on Erlang version requirements for RabbitMQ. Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and a more consistent release schedule. Make stream coordinator more defensive to rapid declaration and deletion cycles GitHub issue: Several inter-node communication listener settings are now exposed to `rabbitmq.conf`: ``` ini distribution.listener.port_range.min = 25675 distribution.listener.port_range.max = 25675 distribution.listener.interface = 192.168.0.1 ``` GitHub issue: Signing keys specified in `rabbitmq.conf` were not translated correctly, resulting in exceptions during permission checks. GitHub issue: Ra was To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.9.10.tar.xz` instead of the source tarball produced by GitHub.
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: legitify.md

title: Legitify subtitle: Security policy for SCM labels: layer: tooling category: application inventors: legitsecurity tutorials: https://legitify.dev https://github.com/Legit-Labs/legitify#github-action-usage code: https://github.com/Legit-Labs/legitify Strengthen the security posture of your source-code management. Detect and remediate misconfigurations, security and compliance issues across all your GitHub & GitLab assets with ease.
Project: ArangoDB (App Definition and Development / Database)
File: thread_local.md

+++ title = "`BOOSTOUTCOMETHREAD_LOCAL`" description = "How to mark variables as having thread local storage duration." +++ Compiler-specific markup used to mark variables as having thread local storage duration. {{% notice note %}} This isn't used inside Outcome, but is used by its unit test suite. {{% /notice %}} Overridable: Define before inclusion. Default: To `threadlocal` if the compiler implements C++ 11 `threadlocal`, else `thread` for the one supported compiler (older Mac OS XCode) which does not. Header: `<boost/outcome/config.hpp>`
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: leader-for-life.md

Implementation Owner: Status: implemented See . - Operators need leader election to ensure that if the same operator is running in two separate pods within the same namespace, only one of them will be active. The primary goal of leader election is to avoid contention between multiple active operators of the same type. High availability is not a goal of leader election for operators. Controller-runtime is adding leader election based on functionality present [in client-go](https://github.com/kubernetes/client-go/blob/master/tools/leaderelection/leaderelection.go). However that implementation allows for the possibility of brief periods during which multiple leaders are active. Requirements have been [discussed on GitHub](https://github.com/operator-framework/operator-sdk/issues/136). This proposal is to add leader election to the SDK that follows a "leader for life" model, which does not allow for multiple concurrent leaders. Provide leader election that is easy to use Provide leader election that prohibits multiple leaders Make operators highly available The "leader for life" approach uses Kubernetes features to detect when a leader has disappeared and then automatically remove its lock. The approach and a PoC is detailed in [a separate repository](https://github.com/mhrivnak/leaderelection). This proposal is to move that implementation into `operator-sdk` and finish/modify it as appropriate. ```golang func main() { // create a lock named "myapp-lock", retrying every 5 seconds until it succeeds err := leader.Become("myapp-lock", 5) if err != nil { log.Error(err, "") os.Exit(1) } ... // do whatever else your app does } ``` Once accepted into operator-sdk, this would be valuable to contribute back to either controller-runtime directly or client-go.
Project: ShardingSphere (App Definition and Development / Database)
File: count-mask-rule.en.md

+++ title = "COUNT MASK RULE" weight = 2 +++ The `COUNT MASK RULE` syntax is used to query the number of mask rules for specified database. {{< tabs >}} {{% tab name="Grammar" %}} ```sql CountMaskRule::= 'COUNT' 'MASK' 'RULE' ('FROM' databaseName)? databaseName ::= identifier ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} When `databaseName` is not specified, the default is the currently used `DATABASE`. If `DATABASE` is not used, `No database selected` will be prompted. | Column | Description | |--|-| | rule_name | rule type | | database | the database to which the rule belongs | | count | the number of the rule | Query the number of mask rules for specified database. ```sql COUNT MASK RULE FROM mask_db; ``` ```sql mysql> COUNT MASK RULE FROM mask_db; +--+-+-+ | rule_name | database | count | +--+-+-+ | mask | mask_db | 3 | +--+-+-+ 1 row in set (0.50 sec) ``` Query the number of mask rules for current database. ```sql COUNT MASK RULE; ``` ```sql mysql> COUNT MASK RULE; +--+-+-+ | rule_name | database | count | +--+-+-+ | mask | mask_db | 3 | +--+-+-+ 1 row in set (0.50 sec) ``` `COUNT`, `MASK`, `RULE`, `FROM`
Project: StarRocks (App Definition and Development / Database)
File: PAUSE_ROUTINE_LOAD.md

displayed_sidebar: "English" import RoutineLoadPrivNote from '../../../assets/commonMarkdown/RoutineLoadPrivNote.md' Pauses a Routine Load job but does not terminate this job. You can execute to resume it. After the load job is paused, you can execute and to view and modify information about the paused load job. <RoutineLoadPrivNote /> ```SQL PAUSE ROUTINE LOAD FOR [dbname.]<jobname>; ``` | Parameter | Required | Description | | | -- | | | db_name | | The name of the database to which the Routine Load job belongs. | | job_name | | The name of the Routine Load job. A table may have multiple Routine Load jobs, it is recommended to set a meaningful Routine Load job name by using identifiable information, for example, Kafka topic name or time when you create the load job, to distinguish multiple routine load jobs. The name of the Routine Load job must be unique within the same database | Pause the Routine Load job `exampletbl1ordertest1` in the database `example_db`. ```sql PAUSE ROUTINE LOAD FOR exampledb.exampletbl1_ordertest1; ```
Project: GraphScope (App Definition and Development / Database)
File: admin_tool.md

`gs_interactive` is a command-line tool designed to manage various aspects of GraphScope Interactive. This document provides a comprehensive guide on how to utilize its functionalities. `gs_interactive` is organized into the following sections: root: Without any specific option, this is used to initialize and destroy the docker image for GraphScope Interactive. database: Handles all data-related operations, such as creating/removing graphs and importing data. service: Manages the GraphScope Interactive service. procedure: Manages the stored procedures of GraphScope Interactive. `gs_interactive -h (--help)`: Showing help message. `gs_interactive init -c (--config) interactive.yaml`: Initializes the docker image for GraphScope Interactive. If the image isn't present, it will be downloaded. This command also configures volume and port mappings. `gs_interactive destroy`: Destroys the docker image of GraphScope Interactive. This action will erase all data and is irreversible. `gs_interactive service -h (--help)`: Showing help message. `gsinteractive service start [-g (--graph) <graphname>] [-c (--config) config.yaml]`: Starts the service with a specified graph and optional configurations. If no graph is provided, the default "modern" graph will be used. `gs_interactive service restart [-c (--config) config.yaml]`: Restarts the service with optional configurations. `gs_interactive service stop`: Stops the service. `gs_interactive service status`: Checks the status (the entry) of the service. `gs_interactive database -h (--help)` `gsinteractive database create -g (--graph) <graphname> -c (--config) schema.yaml`: Creates a graph with the given name and schema. The graph name must be unique within GraphScope Interactive. `gsinteractive database remove -g (--graph) <graphname>`: Removes the specified graph. The currently running graph must be stopped before it can be removed. `gsinteractive database import -g (--graph) <graphname> -c (--config) loading.yaml`: Imports raw data for the given graph. The currently running graph must be stopped before data can be imported, as this will overwrite the existing data. `gs_interactive procedure -h (--help)` `gsinteractive procedure compile -g (--graph) <graphname> [-n (--name) <procname>] [-d (--desc) <description>] -i (--input) <inputfile/folder> [--compile_only]`: Compiles (and enables by default) a given input file (or files in the input folder). If -n isn't provided, the file name will be used as the stored procedure's name. Without the -d option, an empty description will be used. `gsinteractive procedure enable -g (--graph) <graphname> -c (--config) stored_procedures.yaml`: Enables the specified stored procedures. `gsinteractive procedure disable -g (--graph) <graphname> [-a (--all)] -c (--config) stored_procedures.yaml`: Disables the provided (or all) stored procedures. `gsinteractive procedure show -g (--graph) <graphname>`: Displays all enabled stored procedures along with their metadata, including names and descriptions.
Project: StarRocks (App Definition and Development / Database)
File: acos.md

displayed_sidebar: "English" Computes the arc cosine of an argument. ```Haskell DOUBLE acos(DOUBLE arg) ``` `arg`: You can specify only a numeric value. This function converts the numeric value into a DOUBLE value before it computes the arc cosine of the value. Returns a value of the DOUBLE data type. If you specify a non-numeric value, this function returns `NULL`. ```Plain mysql> select acos(-1); +-+ | acos(-1) | +-+ | 3.141592653589793 | +-+ mysql> select acos(0); +--+ | acos(0) | +--+ | 1.5707963267948966 | +--+ mysql> select acos(1); ++ | acos(1) | ++ | 0 | ++ mysql> select acos(""); +-+ | acos('') | +-+ | NULL | +-+ ``` ACOS