cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.0.19.2.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Blocker | Make support for file append API configurable* Appending to HDFS files is supported only if dfs.support.append is set to true. | Major | Task Tracker burns a lot of cpu in calling getLocalCache* make DistributedCache remember the size of each cache directory
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: Spout-implementations.md

title: Spout Implementations layout: documentation documentation: true : Adapter to use Kestrel as a spout : Adapter to use AMQP source as a spout : Adapter to use a JMS source as a spout : A spout that subscribes to a Redis pubsub stream : A spout that subscribes to a beanstalkd queue
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_azure_list.md

List YugabyteDB Anywhere storage-configurations List YugabyteDB Anywhere storage-configurations ``` yba storage-config azure 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 storage configuration for the operation. 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 Azure storage configuration
Project: YugabyteDB (App Definition and Development / Database)
File: active-active-multi-master.md

title: Active-Active Multi-Master design pattern for global applications headerTitle: Active-active multi-master linkTitle: Active-active multi-master description: Multi-Master dual cluster for global applications headcontent: Multi-Master dual cluster using xCluster deployment menu: v2.18: identifier: global-apps-active-active-multi-master parent: build-global-apps weight: 500 type: docs For applications that have to be run in multiple regions, you can adopt the Active-Active Multi-Master pattern, where you set up two clusters in two different regions, and both clusters actively take responsibility for local reads and writes and replicate data asynchronously. In this case, failover is manual and incurs possible loss of data, as the data is asynchronously replicated between the two clusters, but both reads and writes have low latencies. {{<tip>}} Application instances are active in multiple regions and may read stale data. {{</tip>}} {{<cluster-setup-tabs list="local,anywhere">}} Suppose you have cluster with a replication factor of 3, and applications deployed in `us-west`. This ensures that the reads and writes are in the same region, with the expected low latencies. Because the entire cluster is in a single region, in case of a region failure, you would lose all the data. You can eliminate the possibility of data loss by setting up another cluster in a different region, say `us-east`, using . The `us-east` cluster is independent of the primary cluster in `us-west` and the data is populated by asynchronous replication. This means that the read and write latencies of each cluster are not affected by the other, but at the same time, the data in each cluster is not immediately consistent with the other. You can use this pattern to reduce latencies for local users. The Active-Active Multi-Master pattern does not guarantee any transactional consistency during the replication between the clusters. Conflicts are resolved in the bi-directional replication by adopting the "last-writer wins" strategy. When one of the clusters fails, say `us-west`, the other cluster in `us-east` can handle reads and writes for all applications until the failed region recovers. The replication happens at the DocDB layer, bypassing the query layer, and some standard functionality doesn't work: Avoid `UNIQUE` indexes and constraints, as there is no way to check uniqueness. Avoid `TRIGGERS`, as the triggers won't be fired as the query layer is bypassed. Avoid `SERIAL` columns as both the clusters would generate the same sequence (use UUID instead). Schema changes are not automatically transmitted but have to be applied manually (currently). Transaction updates are NOT committed atomically across sources and hence the other cluster could be transactionally inconsistent.
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: install_faq.md

+++ title = "Download and Install FAQ" description = "Download and Install FAQ" draft = false gh_repo = "habitat" [menu] [menu.habitat] title = "Download and Install FAQ" identifier = "habitat/install/install-faq Install Frequently Asked Questions FAQ" parent = "habitat/install" weight = 30 +++ This section tracks some questions that are frequently encountered when downloading and installing the `hab` binary. Q: Can I just download a GitHub release of Chef Habitat? A: While we do cut releases in GitHub as part of our release process those archives are going to be a `.tar` point in time of our source code. As the `hab` cli is written in Rust, if you follow this approach you'll need to compile the source for your platform. Q: Compile for my platform? Does that mean there aren't any OS native packages of `hab`? A: We publish compiled packages for OSX, Linux, and Windows. `hab` has a requirement of either a Linux kernel >= 2.6.32, OSX >= 10.9, or 64-bit Windows 10 Pro, Enterprise, or Education editions (1511 November update, build 10586 or later) with Hyper-V enabled. Q: What if I need an old version of `hab`? A: We've got you covered! The script we provide for doing curl-bash installations will allow you to specify a `-v` flag to pull down a specific version of Chef Habitat, eg: ``` curl https://raw.githubusercontent.com/habitat-sh/habitat/main/components/hab/install.sh \ | sudo bash -s -- -v 0.56.0 ``` Q: Oh! A curl bash I (love||hate) those. A: Indeed they are divisive, we know, that's why we provide a few different ways for you to download. If you'd like to take a look at the script before running it, you can find it in . If you're staunchly in the anti-curl-bash camp, you can get the latest packages from the listed previously. Q: How do I install `hab` across my server fleet? A: For the most part, we leave that up to you. You could just use the aforementioned curl-bash with your provisioner of choice. If your app was dockerized with Chef Habitat then you won't even need to ask this question, because you'll have everything you need inside your container. We are working on first class Mesosphere DC/OS, and Cloud Foundry integrations - which you can keep up to date on in our and .
Project: ArangoDB (App Definition and Development / Database)
File: explicit_make_exception_ptr_copy_converting_constructor.md

+++ title = "`explicit basicresult(const basicresult<R, S, P> &)`" description = "Explicit converting copy constructor from compatible `basicresult`. Available if `predicate::enablemakeexceptionptrcompatibleconversion<R, S, P>` is true. Constexpr, triviality and noexcept propagating." categories = ["constructors", "explicit-constructors", "converting-constructors"] weight = 323 +++ Explicit converting copy constructor from compatible `basicresult`. Calls {{% api "void onresultcopyconstruction(T *, U &&) noexcept" %}} with `this` and the input. Requires: `predicate::enablemakeexceptionptrcompatible_conversion<R, S, P>` is true. Complexity: Same as for the copy constructors of the underlying types. Constexpr, triviality and noexcept of underlying operations is propagated. Guarantees: If an exception is thrown during the operation, the object is left in a partially completed state, as per the normal rules for the same operation on a `struct`.
Project: KICS (Provisioning / Security & Compliance)
File: 8c0695d8-2378-4cd6-8243-7fd5894fa574.md

title: OSS Bucket Allows Delete Action From All Principals hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 8c0695d8-2378-4cd6-8243-7fd5894fa574 Query name: OSS Bucket Allows Delete Action From All Principals Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Access Control URL: OSS Bucket should not allow delete action from all principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/deletion. This means the 'Effect' must not be 'Allow' when the 'Action' is DeleteBucket, for all Principals.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "alicloudossbucket" "bucket-policy1" { bucket = "bucket-1-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObject", "oss:DeleteBucket" ], "Effect": "Allow", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudossbucket" "bucket-policy2" { bucket = "bucket-2-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:ListObjects" ], "Effect": "Allow", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 2 - tf file" resource "alicloudossbucket" "bucket-policy3" { bucket = "bucket-3-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObject", "oss:DeleteBucket" ], "Effect": "Allow", "Principal": [ "20214760404935xxxx" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 3 - tf file" resource "alicloudossbucket" "bucket-policy4" { bucket = "bucket-4-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObject", "oss:DeleteBucket" ], "Effect": "Deny", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ```
Project: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_connect_postgres.md

title: Kubectl-Dba Connect Postgres menu: docs_{{ .version }}: identifier: kubectl-dba-connect-postgres name: Kubectl-Dba Connect Postgres parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Connect to a postgres object Use this cmd to exec into a postgres object's primary pod. ``` kubectl-dba connect postgres [flags] ``` ``` -h, --help help for postgres ``` ``` --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/runner/.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 --default-seccomp-profile-type string Default seccomp profile --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 --password string Password for basic authentication to the API server --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 --username string Username for basic authentication to the API server ``` - Connect to a database.
Project: Pluto (Provisioning / Security & Compliance)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at opensource@fairwinds.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: TiDB (App Definition and Development / Database)
File: 2021-06-23-spilled-unparallel-hashagg.md

Author(s): Discussion PR: https://github.com/pingcap/tidb/pull/25792 Tracking Issue: https://github.com/pingcap/tidb/issues/25882 * * This proposal describes the implementation of Unparalleled HashAgg that can spill intermediate data when memory usage is higher than memory quota. Spilling for paralleled HashAgg will be supported later. Currently, the calculation logic of the aggregate executors in the TiDB is divided into two types, parallel and unparallel. However, when SQL memory usage exceeds the memory quota, neither implementation can use external memory to control memory usage and can only kill the SQL that is executing. In order to enable SQL to execute normally in the case of insufficient memory, we introduce the spilling algorithm for the unparallel aggregate executor. In aggregate processing, memory increases when tuples are inserted into the hash table. So we can use the following algorithm to control the memory increasing: When the memory usage is higher than the mem-quota, switch the HashAgg executor to spill-mode. When HashAgg is in spill-mode, keep the tuple in the hashMap no longer growing. a. If the processing key exists in the Map, aggregate the result. b. If the processing key doesn't exist in the Map, spill the data to disk. After all data have been processed, output the aggregate result in the Map, clear the Map. Then read the spilling data from disk, repeat the Step1-Step3 until all data have been aggregated. Querying using aggregate functions should give correct result. When the unparallel-agg exceeds the memory quota, this feature helps reduce memory usage and run the sql successfully. When the parallel-agg exceeds the memory quota, the SQL will be canceled before. After the agg-concurrency args are set to 1, the SQL can run successfully. When the ndv of the data is low, the SQL contains distinct function will be canceled before. This feature helps the SQL run successfully. When the ndv of the data is high, the SQL contains distinct function will be canceled before. The SQL can be canceled successfully if there is insufficient memory. N/A The feature shouldn't cause any obvious performance regression (< 2%) on non-spilling scenario. Memory will still grow without increasing the number of new tuples in HashMap for distinct aggregate function. Support friendly spilling implementation for the distinct aggregate functions. Support spilling for paralleled HashAgg.
Project: Checkov (Provisioning / Security & Compliance)
File: integrations_issue.md

name: Integrations Issue about: Create an issue regarding the integration of checkov with other tools. title: '' labels: 'integrations' assignees: '' Describe the issue If an existing integration is malfunctioning, please describe the current state and what you expect to be happening. For new integrations, please share an example use case this integration will help checkov support.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: linking-local-packages.md

id: linking-local-packages title: Linking in Local Packages description: How to link in other local packages into your Backstage monorepo It can often be useful to try out changes to the packages in the main Backstage repo within your own app. For example if you want to make modifications to `@backstage/core-plugin-api` and try them out in your app. To link in external packages, add them to your `package.json` and `lerna.json` workspace paths. These can be either relative or absolute paths with or without globs. For example: ```json "packages": [ "packages/*", "plugins/*", "../backstage/packages/core-plugin-api", // New path added to work on @backstage/core-plugin-api ], ``` Then reinstall packages to make yarn set up symlinks: ```bash yarn install ``` With this in place you can now modify the `@backstage/core-plugin-api` package within the main repo, and have those changes be reflected and tested in your app. Simply run your app using `yarn dev` (or `yarn start` for just frontend) as normal. Note that for backend packages you need to make sure that linked packages are not dependencies of any non-linked package. If you for example want to work on `@backstage/backend-common`, you need to also link in other backend plugins and packages that depend on `@backstage/backend-common`, or temporarily disable those plugins in your backend. This is because the transformation of backend module tree stops whenever a non-local package is encountered, and from that point node will `require` packages directly for that entire module subtree. Type checking can also have issues when linking in external packages, since the linked in packages will use the types in the external project and dependency version mismatches between the two projects may cause errors. To fix any of those errors you need to sync versions of the dependencies in the two projects. A simple way to do this can be to copy over `yarn.lock` from the external project and run `yarn install`, although this is quite intrusive and can cause other issues in existing projects, so use this method with care. It can often be best to simply ignore the type errors, as app serving will work just fine anyway. Another issue with type checking is that the incremental type cache doesn't invalidate correctly for the linked in packages, causing type checking to not reflect changes made to types. You can work around this by either setting `compilerOptions.incremental = false` in `tsconfig.json`, or by deleting the types cache folder `dist-types` before running `yarn tsc`.
Project: Veinmind Tools (Provisioning / Security & Compliance)
File: veinmind-runner_generate_doc.md

``` veinmind-runner generate doc [flags] ``` ``` -h, --help help for doc -p, --path string document path (default "docs") -t, --type string document type, markdown/manpage/yaml/rest (default "markdown") ``` ``` -e, --exit-code int exit-code when veinmind-runner find security issues -g, --glob string specifies the pattern of plugin file to find -o, --output string output filepath of report --threads int threads for scan action (default 5) ``` - Generate relevant information
Project: YDB (App Definition and Development / Database)
File: MSBUILD.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 https://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. --> Microsoft Visual Studio 2019. CMake >= 3.12 (should be supplied as part of VS2019 installation). Clone , and follow build instructions in `README.md`. Install Boost from . Add `C:\<path to>\boost168_0\lib64-msvc-14.1` to PATH environment variable. cd lang\c++ cmake -G "Visual Studio 16 2019" -DBOOSTROOT=C:\<path to>\boost1680 -DBOOSTINCLUDEDIR=c:\<path to>\boost1680\boost -DBOOSTLIBRARYDIR=c:\<path to>\boost1680\lib64-msvc-14.1 -DSNAPPYINCLUDEDIR=C:\<path to>\snappy-visual-cpp -DSNAPPY_LIBRARIES=C:\<path to>\snappy-visual-cpp\x64\Release\snappy.lib .. msbuild Avro-cpp.sln /p:Configuration=Release /p:Platform=x64