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

yba - Command line tools to manage your YugabyteDB Anywhere (Self-managed Database-as-a-Service) resources. YugabyteDB Anywhere is a control plane for managing YugabyteDB universes across hybrid and multi-cloud environments, and provides automation and orchestration capabilities. YugabyteDB Anywhere CLI provides ease of access via the command line. ``` yba [flags] ``` ``` -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, --help help for yba -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") -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) ``` - Authenticate yba cli - Manage YugabyteDB Anywhere backups - Generate the autocompletion script for the specified shell - Authenticate yba cli using email and password - Manage YugabyteDB Anywhere providers - Register a YugabyteDB Anywhere customer using yba cli - Manage YugabyteDB Anywhere storage configurations - Manage YugabyteDB Anywhere tasks - Manage YugabyteDB Anywhere universes - Manage YugabyteDB version release
Project: Pulsar (App Definition and Development / Streaming & Messaging)
File: pip-276.md

The metrics are all started with `pulsar_`, so that both users and operators can quickly find the metrics of the entire system through this prefix. However, due to some other reasons, it was found that `topicloadtimes` was missing the prefix, so want to get it right. In master branch, keep the old metric `topicloadtimes` and add below new metrics: `pulsartopicload_times` After release-3.1.0, remove ``topicloadtimes`. Add new metrics: `pulsartopicload_times` : The topic load latency calculated in milliseconds After this PIP, users can use `topicloadtimes` and `pulsartopicload_times` to monitor topic load times. <!-- Updated afterwards --> Mailing List discussion thread: https://lists.apache.org/thread/fcg3f5mm2640fxq4cj8pz6n3lso293f8 Mailing List voting thread: https://lists.apache.org/thread/vky6jcn0llx56599fgo73dh6cxfpmxsm
Project: Trivy (Provisioning / Security & Compliance)
File: help-wanted.md

We use two labels and [good first issue](#good-first-issue) to identify issues that have been specially groomed for new contributors. The `good first issue` label is a subset of `help wanted` label, indicating that members have committed to providing extra assistance for new contributors. All `good first issue` items also have the `help wanted` label. Items marked with the `help wanted` label need to ensure that they are: Low Barrier to Entry It should be tractable for new contributors. Documentation on how that type of change should be made should already exist. Clear Task The task is agreed upon and does not require further discussions in the community. Call out if that area of code is untested and requires new fixtures. API / CLI behavior is decided and included in the OP issue, for example: "The new command syntax is `trivy --format yaml IMAGENAME`" with expected validations called out. Goldilocks priority Not too high that a core contributor should do it, but not too low that it isn't useful enough for a core contributor to spend time to review it, answer questions, help get it into a release, etc. Up-To-Date Often these issues become obsolete and have already been done, are no longer desired, no longer make sense, have changed priority or difficulty , etc. Items marked with the `good first issue` label are intended for _first-time contributors_. It indicates that members will keep an eye out for these pull requests and shepherd it through our processes. These items need to ensure that they follow the guidelines for `help wanted` labels (above) in addition to meeting the following criteria: No Barrier to Entry The task is something that a new contributor can tackle without advanced setup, or domain knowledge. Solution Explained The recommended solution is clearly described in the issue. Provides Context If background knowledge is required, this should be explicitly mentioned and a list of suggested readings included. Gives Examples Link to examples of similar implementations so new contributors have a reference guide for their changes. Identifies Relevant Code The relevant code and tests to be changed should be linked in the issue. Ready to Test There should be existing tests that can be modified, or existing test cases fit to be copied. If the area of code doesn't have tests, before labeling the issue, add a test fixture. This prep often makes a great `help wanted` task!
Project: KICS (Provisioning / Security & Compliance)
File: 261a83f8-dd72-4e8c-b5e1-ebf06e8fe606.md

title: Small PostgreSQL DB Server Log Retention Period hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 261a83f8-dd72-4e8c-b5e1-ebf06e8fe606 Query name: Small PostgreSQL DB Server Log Retention Period Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Observability URL: Check if PostgreSQL Database Server retains logs for less than 3 Days<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "azurermpostgresqlconfiguration" "positive1" { name = "logretentiondays" resourcegroupname = azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = 2 } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermpostgresqlconfiguration" "negative1" { name = "logretentiondays" resourcegroupname = azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = 5 } ```
Project: KICS (Provisioning / Security & Compliance)
File: afa36afb-39fe-4d94-b9b6-afb236f7a03d.md

title: Pod Security Policy Admission Control Plugin Not Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: afa36afb-39fe-4d94-b9b6-afb236f7a03d Query name: Pod Security Policy Admission Control Plugin Not Set Platform: Kubernetes Severity: <span style="color:#bb2124">High</span> Category: Build Process URL: When using kube-apiserver command, the '--enable-admission-plugins' flag should have 'PodSecurityPolicy' plugin and the plugin should be correctly configured in AdmissionControl Config file<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--enable-admission-plugins=AlwaysAdmit"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--enable-admission-plugins=PodSecurityPolicy", "--admission-control-config-file=path/to/plugin/config/file.yaml"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver","--enable-admission-plugins=PodSecurityPolicy", "--admission-control-config-file=path/to/plugin/config/file.yaml"] args: [] restartPolicy: OnFailure ```
Project: YugabyteDB (App Definition and Development / Database)
File: vm.md

title: Install and upgrade issues on virtual machines headerTitle: Install and upgrade issues on virtual machines linkTitle: Install and upgrade issues description: Troubleshoot issues encountered when installing or upgrading YugabyteDB Anywhere on virtual machines. menu: v2.18_yugabyte-platform: identifier: install-upgrade-vm-issues parent: troubleshoot-yp weight: 10 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li> <a href="../vm/" class="nav-link active"> <i class="fa-solid fa-building"></i> Virtual machine</a> </li> <li> <a href="../kubernetes/" class="nav-link"> <i class="fa-regular fa-dharmachakra" aria-hidden="true"></i> Kubernetes </a> </li> </ul> Occasionally, you might encounter issues during installation and upgrade of YugabyteDB Anywhere on a virtual machine. Most of these issues are related to connections. If you experience difficulties while troubleshooting, contact . If your YugabyteDB Anywhere host has a firewall managed by firewalld enabled, then Docker Engine might not be able to connect to the host. To resolve the issue, you can open the ports using firewall exceptions by using the following commands: ```sh sudo firewall-cmd --zone=trusted --add-interface=docker0 sudo firewall-cmd --zone=public --add-port=80/tcp sudo firewall-cmd --zone=public --add-port=443/tcp sudo firewall-cmd --zone=public --add-port=8800/tcp sudo firewall-cmd --zone=public --add-port=5432/tcp sudo firewall-cmd --zone=public --add-port=9000/tcp sudo firewall-cmd --zone=public --add-port=9090/tcp sudo firewall-cmd --zone=public --add-port=32769/tcp sudo firewall-cmd --zone=public --add-port=32770/tcp sudo firewall-cmd --zone=public --add-port=9880/tcp sudo firewall-cmd --zone=public --add-port=9874-9879/tcp ``` The node access might not be available due to IP addresses that cannot be resolved. To remedy the situation, you can create mount paths on the nodes with private IP addresses `10.1.13.150`, `10.1.13.151`, and `10.1.13.152` by executing the following command: ```sh for IP in 10.1.12.103 10.1.12.104 10.1.12.105; do ssh $IP mkdir -p /mnt/data0; done ``` If a firewall is enabled for nodes, it might interfere with node connections. To resolve the issue, you can add firewall exceptions on the nodes with private IP addresses `10.1.13.150`, `10.1.13.151`, and `10.1.13.152` by executing the following command: ```sh for IP in 10.1.12.103 10.1.12.104 10.1.12.105; do ssh $IP firewall-cmd --zone=public --add-port=7000/tcp; ssh $IP firewall-cmd --zone=public --add-port=7100/tcp; ssh $IP firewall-cmd --zone=public --add-port=9000/tcp; ssh $IP firewall-cmd --zone=public --add-port=9100/tcp; ssh $IP firewall-cmd --zone=public --add-port=11000/tcp; ssh $IP firewall-cmd --zone=public --add-port=12000/tcp; ssh $IP firewall-cmd --zone=public --add-port=9300/tcp; ssh $IP firewall-cmd --zone=public --add-port=9042/tcp; ssh $IP firewall-cmd --zone=public --add-port=6379/tcp; done ``` <!-- For YugabyteDB Anywhere HTTPS configuration, you should set your own key or certificate. If you do provide this setting, the default public key is used, creating a potential security risk. -->
Project: Beam (App Definition and Development / Streaming & Messaging)
File: ineat.md

title: "Ineat" icon: /images/logos/powered-by/ineat.png hasLink: "https://ineat.fr/" <!-- Licensed 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. -->
Project: KICS (Provisioning / Security & Compliance)
File: dbfc834a-56e5-4750-b5da-73fda8e73f70.md

title: SLB Policy With Insecure TLS Version In Use hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: dbfc834a-56e5-4750-b5da-73fda8e73f70 Query name: SLB Policy With Insecure TLS Version In Use Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: SLB Policy should not support insecure versions of TLS protocol<br> ```tf title="Positive test num. 1 - tf file" hl_lines="3" resource "alicloudslbtlscipherpolicy" "positive" { tlscipherpolicyname = "Test-examplevalue" tls_versions = ["TLSv1.1","TLSv1.2"] ciphers = ["AES256-SHA","AES256-SHA256", "AES128-GCM-SHA256"] } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudslbtlscipherpolicy" "negative" { tlscipherpolicyname = "Test-examplevalue" tls_versions = ["TLSv1.2","TLSv1.3"] ciphers = ["AES256-SHA256", "AES128-GCM-SHA256","TLSAES256GCMSHA384"] } ```
Project: Apache Heron (App Definition and Development / Streaming & Messaging)
File: schedulers-local.md

id: version-0.20.0-incubating-schedulers-local title: Local Cluster sidebar_label: Local Cluster original_id: schedulers-local <!-- 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. --> In addition to out-of-the-box schedulers for , Heron can also be deployed in a local environment, which stands up a mock Heron cluster on a single machine. This can be useful for experimenting with Heron's features, testing a wide variety of possible cluster events, and so on. One of two state managers can be used for coordination when deploying locally: Note: Deploying a Heron cluster locally is not to be confused with Heron's . Simulator mode enables you to run topologies in a cluster-agnostic JVM process for the purpose of development and debugging, while the local scheduler stands up a Heron cluster on a single machine. Using the local scheduler is similar to deploying Heron on other schedulers. The cli is used to deploy and manage topologies as would be done using a distributed scheduler. The main difference is in the configuration. To configure Heron to use local scheduler, specify the following in `scheduler.yaml` config file. `heron.class.scheduler` Indicates the class to be loaded for local scheduler. Set this to `org.apache.heron.scheduler.local.LocalScheduler` `heron.class.launcher` Specifies the class to be loaded for launching topologies. Set this to `org.apache.heron.scheduler.local.LocalLauncher` `heron.scheduler.local.working.directory` Provides the working directory for topology. The working directory is essentially a scratch pad where topology jars, heron core release binaries, topology logs, etc are generated and kept. `heron.package.core.uri` Indicates the location of the heron core binary package. The local scheduler uses this URI to download the core package to the working directory. `heron.directory.sandbox.java.home` Specifies the java home to be used when running topologies in the containers. Set to `${JAVA_HOME}` to use the value set in the bash environment variable $JAVA_HOME. ```yaml heron.class.scheduler: org.apache.heron.scheduler.local.LocalScheduler heron.class.launcher: org.apache.heron.scheduler.local.LocalLauncher heron.scheduler.local.working.directory: ${HOME}/.herondata/topologies/${CLUSTER}/${TOPOLOGY} heron.package.core.uri: file://${HERON_DIST}/heron-core.tar.gz heron.directory.sandbox.java.home: ${JAVA_HOME} ```
Project: Juju (Provisioning / Automation & Configuration)
File: fixing-bugs.md

juju and Bug Fixes ================== When fixing a bug that affects more than a single branch the prefered process for fixing the bug is to perform the work against the oldest branch (back porting) and then apply that patch up to each release branch and finally in to master. For example, if a bug is reported to impact R1, R2, and master. You would perform the work against a branch of R1. When your fix is ready you would use the pull request and review process. Then you would apply your fix to R2, and finally once your fix was merged in to R2, you would apply the fix to current master. How To Backport ================ Once your initial fix has been merged by the bot (the back port) the process of applying your patch can be done with a few git commands. In this example I will show you applying the fix in to master. You will want to locate the SHA for the merge commit that was generated by jujubot. This will be viewable on github or in your git log output. Copy the SHA since we will use it to cherry-pick the fix in to master. git checkout master git checkout -b <fixed-branch-name> git cherry-pick -m 1 <merge-commit-sha> You may have some minor merge conflicts with the cherry-pick that need to be fixed, this is rare when back porting the change first, but occasionally it does happen. git push your-remote <fixed-branch-name> Now your new branch is ready to follow the same pull request and review process as the original fix. Be sure to note that this is a patch from a backport and link to the previous review.
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.10.4.md

This hotfix release contains two bug fixes. A regression introduced in Dapr 1.10.0 caused gRPC proxying to not work when are used. All calls to proxied gRPC endpoints would fail with an "Unimplemented" gRPC error. The issue impacts users on Dapr 1.10.0-1.10.3 that use API allowlists for gRPC APIs, and who use gRPC proxying. A regression was introduced in Dapr 1.10.0 that caused all proxied gRPC requests to be matched against the API allowlist when that is configured for gRPC, with the consequence that all calls were rejected. We have changed how API allowlists work for gRPC, so all proxied calls are always allowed regardless of the rules in the allowlists. We have added tests to prevent future regressions. A regression introduced in Dapr 1.10.0 caused Dapr to invoke the application on the `/dapr/subscribe` endpoint when the is called. This doesn't affect any existing subscriptions and does not result in Dapr re-subscribing to topics. The issue impacts users on Dapr 1.10.0-1.10.3. A regression was introduced in Dapr 1.10.0 when returning the list of subscriptions in a metadata endpoint response. Instead of only returning a local cache snapshot, Dapr called the application to get the list of subscriptions every time the metadata endpoint is invoked. We updated Dapr to return a subscriptions list snapshot and not invoke the app when the metadata endpoint is invoked.
Project: StarRocks (App Definition and Development / Database)
File: thrift-guides.md

displayed_sidebar: "English" As the project involving, any fields may become optional. But if it is defined as required, it can not be removed. So `required` should not be used. To be back compatible, the ordinal of the field SHOULD NOT be changed. The names of messages are all lowercase, with underscores between words. Files should end in `.thrift`. ``` my_struct.thrift // Good MyStruct.thrift // Bad my_struct.proto // Bad ``` Struct names start with a capital letter `T` and have a capital letter for each new word, with no underscores: TMyStruct ``` struct TMyStruct; // Good struct MyStruct; // Bad struct TMy_Struct; // Bad struct TmyStruct; // Bad ``` The names of struct members are all lowercase, with underscores between words. ``` 1: optional i64 my_field; // Good 1: optional i64 myField; // Bad ```
Project: ArangoDB (App Definition and Development / Database)
File: dictionaryRandomAccess.md

`dictionaryRandomAccess.c` is LZ4 API example which implements dictionary compression and random access decompression. Please note that the output file is not compatible with lz4frame and is platform dependent. Dictionary based compression for homogenous files. Random access to compressed blocks. Reads the dictionary from a file, and uses it as the history for each block. This allows each block to be independent, but maintains compression ratio. ``` Dictionary | v ++ | Block#1 | +-+-+ | v {Out#1} Dictionary | v ++ | Block#2 | +-+-+ | v {Out#2} ``` After writing the magic bytes `TEST` and then the compressed blocks, write out the jump table. The last 4 bytes is an integer containing the number of blocks in the stream. If there are `N` blocks, then just before the last 4 bytes is `N + 1` 4 byte integers containing the offsets at the beginning and end of each block. Let `Offset#K` be the total number of bytes written after writing out `Block#K` including the magic bytes for simplicity. ``` +++ +++-+ +-+--+ | TEST | Block#1 | ... | Block#N | 4 | Offset#1 | ... | Offset#N | N+1 | +++ +++-+ +-+--+ ``` Decompression will do reverse order. Seek to the last 4 bytes of the file and read the number of offsets. Read each offset into an array. Seek to the first block containing data we want to read. We know where to look because we know each block contains a fixed amount of uncompressed data, except possibly the last. Decompress it and write what data we need from it to the file. Read the next block. Decompress it and write that page to the file. Continue these procedure until all the required data has been read.
Project: Meshery (Provisioning / Automation & Configuration)
File: ci.md

name: Continuous Integration / DevOps about: Improve or update workflows or other automation title: '[CI]' labels: 'area/ci' assignees: '' <!-- A brief description of what the problem is. (e.g. I need to be able to...) --> <!-- A brief description of what you expected to happen. --> <!-- Specifics on the approach to fulfilling the feature request. --> <!-- Stipulations of functional behavior or non-functional items that must be in-place in order for the issue to be closed. --> Meshery documentation and Wireframes and designs for Meshery UI in Questions: and
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.14.md

layout: release date: 2022-10-07 tag: v0.6.14 language: en [Design Configurator] Add Name, Namespace, Annotations and Labels in the RJSF form in Meshery UI @Abhishek-kumar09 (#6314) [Feat] Add support for visualizing state machines @sudo-NithishKarthik (#6348) [Meshsync] Populate the context name in meshsync correctly. @legendarykamal (#6345) [Chore] Fix ESlint errors causing workflow failure @Chadha93 (#6347) [CI] Fixed Cypress check failing to initiate tests @Chadha93 (#6346) Two Columns Layout prettify @harkiratsm (#6343) [UI] Inject Prompt Component @MUzairS15 (#6338) Upgrade to Go 1.19 @acald-creator (#6342) [Chore] Fix ESlint errors causing workflow failure @Chadha93 (#6347) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Chadha93, @MUzairS15, @acald-creator, @harkiratsm, @l5io, @leecalcote, @legendarykamal, @sudo-NithishKarthik and @theBeginner86
Project: ArangoDB (App Definition and Development / Database)
File: value.md

+++ title = "`static auto &&_value(Impl &&) noexcept`" description = "Returns a reference to the value in the implementation passed in. Constexpr, never throws." categories = ["observers"] weight = 250 +++ Returns a reference to the value in the implementation passed in. No checking is done to ensure there is a value. Constexpr where possible. Requires: Always available. Complexity: Constant time. Guarantees: Never throws an exception.