cwielenb/CNCF-Dataset huggingface dataset:
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: multi-sa.md

title: Multiple Service Accounts linkTitle: Multiple Service Accounts weight: 80 There may be a need to have multiple service accounts to provide only the necessary permissions to various objects that the operator creates on a Kubernetes cluster. This can be accomplished by using the `--extra-service-accounts` flag when generating the bundle with `make bundle`. Update the `bundle` target in the `Makefile` to add the `--extra-service-accounts` flag with the name of the desired service account. This ensures that the permissions and configurations do not get overwritten by `make bundle`. For example, modify the line that contains `operator-sdk generate bundle` similar to below replacing `myOperator-name-additional-service-account` to the desired service account name appended to the operator name. ``` bundle: manifests kustomize operator-sdk ## Generate bundle manifests and metadata, then validate generated files. operator-sdk generate kustomize manifests -q cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG) $(KUSTOMIZE) build config/manifests | operator-sdk generate bundle -q --overwrite --extra-service-accounts myOperator-name-additional-service-account --version $(VERSION) $(BUNDLEMETADATAOPTS) operator-sdk bundle validate ./bundle ``` The `--extra-service-accounts` flag takes a comma-separated list of strings, so you can add more than a single service account name if desired. These steps will need to be followed for every additional service account. Create a new service account file. For example: ``` cat << EOF > config/rbac/additionalserviceaccount.yaml apiVersion: v1 kind: ServiceAccount metadata: name: additional-service-account namespace: system EOF ``` Create a role binding. In this example, it is a `ClusterRoleBinding`: ``` cat << EOF > config/rbac/additionalrolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: additional-service-account-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: additional-service-account-role subjects: kind: ServiceAccount name: additional-service-account namespace: system EOF ``` Create a role with desired permissions. In this example, it is a `ClusterRole` that provides permission to the `privileged` `SecurityContextConstraint` (`SCC`). ``` cat << EOF > config/rbac/additional_role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: additional-service-account-role rules: apiGroups: security.openshift.io resourceNames: privileged resources: securitycontextconstraints verbs: use EOF ``` Make sure to update the RBAC configuration `kustomization.yaml` file with the previously created RBAC `yaml` files. For example: ``` cat << EOF >> config/rbac/kustomization.yaml additionalserviceaccount.yaml additional_role.yaml additionalrolebinding.yaml EOF ```
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: deploy-applications.md

title: Kubernetes &mdash; Deploying Applications layout: 1: left This tutorial shows you how to build and deploy a simple, multi-tier web application using Kubernetes and Kui. You will learn how to explore the structure of this application. Once you are confident in your understanding of the implications of its deployment, this notebook can help you with taking that next step. The guestbook application uses Redis to store its data. It writes its data to a Redis master instance and reads data from multiple Redis slave instances. Although the Redis master is a single pod, you can make it highly available to meet traffic demands by adding replica Redis slaves. The guestbook application has a web frontend serving the HTTP requests written in PHP. It is configured to connect to the redis-master `Service` for write requests and the redis-slave service for Read requests. First, let's create a namespace to keep our work isolated: ```bash validate: k get ns kui-notebook-1 cleanup: k delete ns kui-notebook-1 kubectl create ns kui-notebook-3 ``` This application consists of the following components: A single-instance Redis master to store guestbook entries Multiple replicated Redis instances to serve reads Multiple web frontend instances By executing `kubectl get -f <dir>`, where `<dir>` is the directory that contains the application's resource definitions, you can view a visual summary of this application structure. This summary lets you preview the deployment. ```bash kubectl get -f plugins/plugin-kubectl/tests/data/k8s/application/guestbook/ -n kui-notebook-3 ``` By executing the following `apply -f` command view, you can initiate the deployment of this application to your cluster. ```bash validate: k get deploy frontend -n kui-notebook-1 cleanup: k delete -n kui-notebook-3 -f plugins/plugin-kubectl/tests/data/k8s/application/guestbook/ kubectl apply -n kui-notebook-3 -f plugins/plugin-kubectl/tests/data/k8s/application/guestbook/ ``` By drilling down the resource in the above view, you can inspect the status of the running deployment. For example, the following sidecar is the result of clicking `Deployment` `frontend`. ```bash kubectl get Deployment frontend -o yaml -n kui-notebook-3 ```
Project: Puppet (Provisioning / Automation & Configuration)
File: http_node.md

Node ==== The `node` endpoint is used by the puppet agent to get basic information about a node. The returned information includes the node name and environment, and optionally any classes set by an External Node Classifier and a hash of parameters which may include the node's facts. The returned node may have a different environment from the one given in the request if Puppet is configured with an ENC. Find Retrieve data for a node GET /puppet/v3/node/:certname?environment=:environment&transactionuuid=:transactionuuid&configured_environment=:environment GET `application/json` One parameter should be provided to the GET: `transaction_uuid`: a transaction uuid identifying the entire transaction (shows up in the report as well) An optional parameter can be provided to the GET to notify a node classifier that the client requested a specific environment, which might differ from what the client believes is its current environment: `configured_environment`: the environment configured on the client > GET /puppet/v3/node/mycertname?environment=production&transactionuuid=aff261a2-1a34-4647-8c20-ff662ec11c4c&configuredenvironment=production HTTP/1.1 > Accept: application/json < HTTP/1.1 200 OK < Content-Type: application/json < Content-Length: 4630 { "name":"thinky.corp.puppetlabs.net", "parameters":{ "architecture":"amd64", "kernel":"Linux", "blockdevices":"sda,sr0", "clientversion":"3.3.1", "clientnoop":"false", "environment":"production", ... }, "environment":"production" } Schema A node response body conforms to
Project: Akri (Provisioning / Automation & Configuration)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. Output of `kubectl get pods,akrii,akric -o wide` Kubernetes Version: [e.g. Native Kubernetes 1.19, MicroK8s 1.19, Minikube 1.19, K3s] To Reproduce Steps to reproduce the behavior: Create cluster using '...' Install Akri with the Helm command '...' '...' Expected behavior A clear and concise description of what you expected to happen. Logs (please share snips of applicable logs) To get the logs of any pod, run `kubectl logs <pod name>` To get the logs of a pod that has already terminated, `kubectl get logs <pod name> --previous` If you believe that the problem is with the Kubelet, run `journalctl -u kubelet` or `journalctl -u snap.microk8s.daemon-kubelet` if you are using a MicroK8s cluster. Additional context Add any other context about the problem here.
Project: YugabyteDB (App Definition and Development / Database)
File: add-nodes.md

title: Use YugabyteDB Anywhere to recover a node headerTitle: Recover a node linkTitle: Recover a node description: Use YugabyteDB Anywhere to recover a decommissioned node. menu: v2.18_yugabyte-platform: identifier: add-nodes parent: manage-deployments weight: 30 type: docs In some cases, depending on the node's status, YugabyteDB Anywhere allows you to recover a removed node on a new backing instance, as follows: Navigate to Universes. Select your universe. Open the Nodes tab. Find a node with a Decommissioned status and click its corresponding Actions > Add Node, as per the following illustration:<br> For Infrastructure as a service (IaaS) such as AWS and GCP, YugabyteDB Anywhere will spawn with the existing node instance type in the existing region and zone of that node. When the process completes, the node will have the Master and TServer processes running, along with data that is load-balanced onto this node. The node's name will be reused and the status will be shown as Live. For information on removing and eliminating nodes, see .
Project: ArangoDB (App Definition and Development / Database)
File: inequality_basic_result.md

+++ title = "`bool operator!=(const basic_result<A, B, C> &) const`" description = "Returns true if this result does not compare equal to the other result. Constexpr and noexcept propagating." categories = ["comparisons"] weight = 840 +++ Returns true if this result does not compare equal to the other result. Comparison is done using `operator!=` on either `valuetype` or `errortype` if the currently chosen state is the same for both results, otherwise true is returned. Requires: `operator!=` must be a valid expression between `valuetype` and `A`, and between `errortype` and `B`. If `valuetype` is `void`, then so must be `A`; similarly for `errortype` and `B`. Complexity: Whatever the underlying `operator!=` have. Constexpr and noexcept of underlying operations is propagated. Guarantees: None. Free function alias: There is a free function `bool operator!=(const basicresult<A, B, C> &, const basicoutcome<A, B, C, D> &)` which forwards perfectly to this function, by reversing the operands.
Project: Druid (App Definition and Development / Database)
File: parquet.md

id: parquet title: "Apache Parquet Extension" <!-- ~ 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 Apache Druid module extends to ingest data directly from offline Apache Parquet files. Note: If using the `parquet-avro` parser for Apache Hadoop based indexing, `druid-parquet-extensions` depends on the `druid-avro-extensions` module, so be sure to . The `druid-parquet-extensions` provides the , the , and the with `druid-avro-extensions`. The Parquet input format is available for and the other 2 parsers are for . Please see corresponding docs for details.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.183.md

layout: release date: 2023-11-28 tag: v0.6.183 fix node tab crash ( missing null checks) @aabidsofi19 (#9483) [fix] missing dashboard overview charts @aabidsofi19 (#9482) Thank you to our contributors for making this release possible: @aabidsofi19
Project: KICS (Provisioning / Security & Compliance)
File: 24e16922-4330-4e9d-be8a-caa90299466a.md

title: ElasticSearch Not Encrypted At Rest hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 24e16922-4330-4e9d-be8a-caa90299466a Query name: ElasticSearch Not Encrypted At Rest Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Check if ElasticSearch encryption is disabled at Rest<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 11" resource "awselasticsearchdomain" "positive1" { domain_name = "example" elasticsearch_version = "1.5" } resource "awselasticsearchdomain" "positive2" { domain_name = "example" elasticsearch_version = "1.5" encryptatrest { enabled = false } } ``` ```tf title="Negative test num. 1 - tf file" resource "awselasticsearchdomain" "negative1" { domain_name = "example" elasticsearch_version = "1.5" encryptatrest { enabled = true } } ```
Project: ArangoDB (App Definition and Development / Database)
File: std_checked.md

+++ title = "`stdchecked<T, E = std::errorcode>`" description = "A type alias to a `basicresult` configured with `std::errorcode` and `policy::throwbadresult_access<EC>`." +++ A type alias to a {{% api "basicresult<T, E, NoValuePolicy>" %}} configured with {{% api "std::errorcode" %}} and `policy::`{{% api "throwbadresult_access<EC>" %}}. This type alias always references the `std` edition of things, unlike {{% api "checked<T, E = varies>" %}} which references either this alias or {{% api "boostchecked<T, E = boost::system::errorcode>" %}}. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/std_result.hpp>`
Project: StarRocks (App Definition and Development / Database)
File: deployment_overview.md

displayed_sidebar: "English" This chapter describes how to deploy, upgrade, and downgrade a StarRocks cluster in a production environment. A summary of the deployment procedure is as follows and later topics provide the details. The deployment of StarRocks generally follows the steps outlined here: Confirm the for your StarRocks deployment. Check the prerequisites that your servers must meet before deploying StarRocks, including CPU, memory, storage, network, operating system, and dependencies. . Plan the number of FE nodes and BE nodes in your cluster, and the hardware specifications of the servers. . When your servers are ready, you need to check and modify some environment configurations before deploying StarRocks on them. . If you want to deploy StarRocks on x86-based CentOS 7.9, you can directly download and extract the software package provided on our official website. If you want to deploy StarRocks with ARM architecture CPUs or on Ubuntu 22.04, you need to prepare the deployment files from the StarRocks Docker image. If you want to deploy StarRocks on Kubernetes, you can skip this step. Deploy StarRocks. If you want to deploy a shared-data StarRocks cluster, which features a disaggregated storage and compute architecture, see for instructions. If you want to deploy a shared-nothing StarRocks cluster, which uses local storage, you have the following options: . . . . Perform necessary measures. Further setup measures are needed before your StarRocks cluster is put into production. These measures include securing the initial account and setting some performance-related system variables. If you plan to upgrade an existing StarRocks cluster to a later version rather than install StarRocks for the first time, see for information about upgrade procedures and issues that you should consider before upgrading. For instructions to downgrade your StarRocks cluster, see .
Project: ArangoDB (App Definition and Development / Database)
File: returning.md

+++ title = "Returning Outcome types from Coroutines" weight = 30 tags = [ "coroutines" ] +++ `eager<T>` and `lazy<T>` and their atomic editions are completely standard awaitables with no special behaviours, except if `T` is a `basic_result` or `basic_outcome`. In that situation, the following occurs: If the Coroutine throws a C++ exception which was not handled inside the Coroutine body, Outcome's awaitable types try to convert it into a form which your Result or Outcome type being returned can transport. For example: If your Coroutine were returning a `result<T, std::exception_ptr>`, an errored Result with a pointer to the exception thrown would be returned. If your Coroutine were returning a `result<T, std::error_code>`, the exception ptr is passed to {{% api "errorfromexception(" %}}`)` to see if it can be matched to an equivalent `std::error_code`. If it can, an errored Result with the equivalent error code would be returned. If your Coroutine were returning an `outcome<T, std::errorcode, std::exceptionptr>`, an Errored Outcome is chosen preferentially to an Excepted Outcome. If your Coroutine were returning an `experimental::statusresult<T, systemcode>`, because Experimental SG14 `system_code` can transport error codes or exception ptrs (or indeed `std::error_code`'s), an errored Result is returned.
Project: StarRocks (App Definition and Development / Database)
File: DROP_FILE.md

displayed_sidebar: "English" You can execute the DROP FILE statement to delete a file. When you use this statement to delete a file, the file is deleted both in frontend (FE) memory and in Berkeley DB Java Edition (BDBJE). :::tip This operation requires the SYSTEM-level FILE privilege. You can follow the instructions in to grant this privilege. ::: ```SQL DROP FILE "file_name" [FROM database] [properties] ``` | Parameter | Required | Description | | - | | | | file_name | Yes | The name of the file. | | database | No | The database to which a file belongs. | | properties | Yes | The properties of the file. The following table describes the configuration items of properties. | Configuration items of `properties` | Configuration items | Required | Description | | -- | | - | | catalog | Yes | The category to which a file belongs. | Delete a file named ca.pem. ```SQL DROP FILE "ca.pem" properties("catalog" = "kafka"); ```
Project: ShardingSphere (App Definition and Development / Database)
File: show-broadcast-table-rule.en.md

+++ title = "SHOW BROADCAST TABLE RULE" weight = 1 +++ The `SHOW BROADCAST TABLE RULE` syntax is used to broadcast tables for specified database. {{< tabs >}} {{% tab name="Grammar" %}} ```sql ShowBroadcastTableRule ::= 'SHOW' 'BROADCAST' 'TABLE' 'RULES' ('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 | |--|-| | broadcast_table | Broadcast table name | Query broadcast tables for specified database. ```sql SHOW BROADCAST TABLE RULES FROM sharding_db; ``` ```sql mysql> SHOW BROADCAST TABLE RULES FROM sharding_db; +--+ | broadcast_table | +--+ | t_a | | t_b | | t_c | +--+ 3 rows in set (0.00 sec) ``` Query broadcast table for current database. ```sql SHOW BROADCAST TABLE RULES; ``` ```sql mysql> SHOW BROADCAST TABLE RULES; +--+ | broadcast_table | +--+ | t_a | | t_b | | t_c | +--+ 3 rows in set (0.00 sec) ``` `SHOW`, `BROADCAST`, `TABLE`, `RULES`
Project: secureCodeBox (Provisioning / Security & Compliance)
File: dockerfile.md

title: Dockerfile sidebar_position: 5 The Dockerfile for a hook looks like the following. If you use the provided hook-sdk, you won't need to apply any changes to it. ```Dockerfile ARG baseImageTag FROM node:12-alpine as build RUN mkdir -p /home/app WORKDIR /home/app COPY package.json package-lock.json ./ RUN npm ci --production FROM securecodebox/hook-sdk-nodejs:${baseImageTag:-latest} WORKDIR /home/app/hook-wrapper/hook/ COPY --from=build --chown=app:app /home/app/nodemodules/ ./nodemodules/ COPY --chown=app:app ./hook.js ./hook.js ``` See for instructions on how to build and deploy your hook.
Project: FOSSA (Provisioning / Security & Compliance)
File: cocoapods.md

`podfile`: Find all directories containing a `Podfile` file. `podfilelock`: Find all directories containing a `Podfile.lock` file. We scan the `Podfile` text for `pod` declarations, which indicate a direct dependency of the current project. We also scan for a `source` declaration, which gives us a default source to assign to all `pod` declarations without an explicit source. We scan the `Podfile.lock` for two particular sections: `PODS` and `DEPENDENCIES`. The `PODS` section describes the relationships between the dependencies, and `DEPENDENCIES` tells us which of the dependencies the project depends on directly. In the following example, we have five dependencies, `one`, `two`, `three`, `four` and `five/+zlib`. `one`, `three` and `five/+zlib` are direct dependencies, `one` depends on both `two` and `three`, and `three` depends on `four`. ``` PODS: one (1.0.0): two (= 3.2.1) three (= 3.2.1) two (2.0.0) three (3.0.0) four (= 2.3.3) four (4.0.0): "five/+zlib (7.0.0)" DEPENDENCIES: one (> 4.4) three (from `Submodules/subproject/.podspec`) "five/+zlib (7.0.0)" ``` We also look at the `EXTERNAL SOURCES` section to try and resolve locally vendored Cocoapods. If we see a locally vendored Cocoapod using either `:podspec` or `:path` to a local directory, we'll read the Podspec at that directory and also upload that dependency if it has a supported `source`. We will also replace any dependencies originating via subspec of locally vendored dependency, with it's vendored dependency's `source`. We currently only support the `git` source. Pods sourced from http path are not supported (e.g `pod 'JSONKit', :podspec => 'https://example.com/JSONKit.podspec'`). Pods sourced from subversion, mercurial, and bazaar are not supported. Plugins in Podfiles are ignored.
Project: YugabyteDB (App Definition and Development / Database)
File: jepsen-testing-ycql.md

title: Jepsen testing of YCQL headerTitle: Jepsen testing linkTitle: Jepsen testing description: Learn the results from Jepsen testing on YCQL. menu: v2.18: identifier: jepsen-testing-2-ycql parent: resilience weight: 13 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../jepsen-testing-ysql/" class="nav-link"> <i class="icon-postgres" aria-hidden="true"></i> YSQL </a> </li> <li > <a href="../jepsen-testing-ycql/" class="nav-link active"> <i class="icon-cassandra" aria-hidden="true"></i> YCQL </a> </li> </ul> For details on Jepsen testing of YCQL, see .
Project: ClickHouse (App Definition and Development / Database)
File: v23.10.2.13-stable.md

sidebar_position: 1 sidebar_label: 2023 Fix a crash during table loading on startup (). Fix segfault in signal handler for Keeper (). Fix incomplete query result for UNION in view() function. (). Fix inconsistency of "cast('0' as DateTime64(3))" and "cast('0' as Nullable(DateTime64(3)))" (). Fix crash in case of adding a column with type Object(JSON) (). Fix buffer overflow in T64 ().
Project: KICS (Provisioning / Security & Compliance)
File: a1ef9d2e-4163-40cb-bd92-04f0d602a15d.md

title: S3 Bucket ACL Allows Read to All Users hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a1ef9d2e-4163-40cb-bd92-04f0d602a15d Query name: S3 Bucket ACL Allows Read to All Users Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Access Control URL: S3 Buckets should not be readable to all users<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11 6" name: Create an empty bucket amazon.aws.aws_s3: bucket: mybucket mode: create permission: public-read name: Create an empty bucket2 amazon.aws.aws_s3: bucket: mybucket mode: create permission: public-read-write ``` ```yaml title="Negative test num. 1 - yaml file" name: Create an empty bucket amazon.aws.aws_s3: bucket: mybucket mode: create permission: private name: Create an empty bucket2 amazon.aws.aws_s3: bucket: mybucket mode: create ```