cwielenb/CNCF-Dataset huggingface dataset:
Project: Vald (App Definition and Development / Database)
File: lb-gateway.md

Vald LB Gateway is the component to handle requests in the Vald cluster. This component is essential to operate the Vald cluster because all requests should pass it, and other components depend on it. This page introduces the overview and features of Vald Gateway. Vald LB Gateway is responsible for: Pass and load balancing requests to other Vald components Control processing with a timeout setting Aggregate search results from each Vald Agent Sort and combine into one search result The next chapter shows the main features. Vald LB Gateway is a mandatory component for the Vald cluster. Each following section introduces each feature. Vald LB Gateway is the only component that connects to Kubernetes Ingress in the Vald clusters components in basic. User requests have passed Kubernetes Ingress reaches to Vald LB Gateway. Then, Vald LB Gateway will suspend processing according to timeout and return a response when the internal processing takes a long time. <div class="note"> If Vald Filter Gateway runs and the request has the filter gateway option, Kubernetes Ingress will pass the request to Vald Filter Gateway. Then, Vald Filter Gateway sends the processed request to the Vald LB Gateway. </div> As its name shows, Vald LB Gateway has the load balancing feature. Vald LB Gateway controls insert vector requests based on `index replica` and each Vald Agent Pod resource usage, which provides, to avoid uneven resource usage. Vald LB Gateway broadcasts searching requests, e.g., `Search`, `GetObject`, `Exist`, to all Vald Agent Pods and gets their result. In the `Search` phase, Vald LB Gateway receives search results from all Vald Agent Pods within the user-defined timeout time and sorts combining results by shortest distance. Then, Vald LB Gateway returns the Top-N of the sorted search results (N is the user-defined number). <div class="note"> When Vald Agent Pod could not give search result by the timeout limit, Vald LB Gateway will cancel the searching requests to the Vald Agent Pod. </div> Vald LB Gateway is the only component to connect to the ingress (or egress) filter component via Vald Filter Gateway. When the ingress component runs, Vald LB Gateway will pass the object of request to the Ingress, then get the vector converted from it. Vald LB Gateway will send the search result to the Egress when the egress component runs and get the filtered result. <div class="note"> For more information about Vald Filter Gateway, please refer to . </div> <!-- TODO: add the link of configuration page -->
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: custom-rpms.md

This setup illustrates how to build and integrate custom libvirt rpms in KubeVirt. This can be particularly useful if you need to test a fix in libvirt for KubeVirt. If you already have the rpms available you can skip this section. Create a volume for the rpms that will be shared with the http server container ```bash $ docker volume create rpms ``` Start build environment for libvirt source code. This setup uses the used by the libvirt CI. This setup is just an example for reference, and this can be achieved in many ways. Start container inside the libvirt directory with your changes and enter in the build container ```bash $ docker run -td -w /libvirt-src --security-opt label=disable --name libvirt-build -v $(pwd):/libvirt-src -v rpms:/root/rpmbuild/RPMS registry.gitlab.com/libvirt/libvirt/ci-centos-stream-8 $ docker exec -ti libvirt-build bash ``` Steps inside the build environment to obtain the rpms. More details at https://libvirt.org/compiling.html ```bash $ dnf update -y $ meson build $ ninja -C build dist ``` The build environment might require additional dependencies and this may vary based on the libvirt version: ```bash $ dnf install -y createrepo hostname $ rpmbuild -ta /libvirt-src/build/meson-dist/libvirt-*.tar.xz $ createrepo -v /root/rpmbuild/RPMS/x86_64 ``` If you want to use other publicly available rpms or a private repository that is reachable from the KubeVirt build container, you can skip this section and substitute the custom repository. The http server container allows to expose locally the rpms to the KubeVirt build server. It is reachable by the IP address from the KubeVirt build container. Start the http server with the `rpms` volume where we created the rpms in the previous step (otherwise pass the directory that contains the rpms) ```bash $ docker run -dit --name rpms-http-server -p 80 -v rpms:/usr/local/apache2/htdocs/ httpd:latest ``` Get the IP of the container `rpms-http-server` ```bash $ docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' rpms-http-server 172.17.0.4 ``` Create `custom-repo.yaml` pointing to the local http server: ```yaml repositories: arch: x86_64 baseurl: http://172.17.0.4:80/x86_64/ # The IP corresponding to the rpms-http-server container name: custom-build gpgcheck: 0 repo_gpgcheck: 0 ``` Update the rpms in KubeVirt repository. If you only want to update a single architecture, set `SINGLEARCH="x8664"`. It is sometimes necessary to change `basesystem` when using custom rpms packages. This can be achieved by setting `BASESYSTEM=xyz` env variable. If you want to change version of some packages you can set env variables. See script for all variables that can be changed. ```bash $ make CUSTOMREPO=custom-repo.yaml LIBVIRTVERSION=0:7.2.0-1.el8 rpm-deps ``` Afterwards, the `WORKSPACE` and `rpm/BUILD.bazel` are automatically updated and KubeVirt can be built with the custom rpms.
Project: Percona Server for MySQL (App Definition and Development / Database)
File: README.md

Here we provide short but complete and working samples of some of the most important parts of the Jones API. illustrates using [session.find()] (../../database-jones/API-documentation/Session) to retreive a single record from a table. illustrates using session.persist() to store a record. illustrates using session.createQuery() to build and execute a that returns multiple records. illustrates using a to define a relationship between tables, and then running session.find() against the projection. The equivalent query in SQL would be a join. The scan and join samples use the tables in the tweet demo, described below. This directory contains a Twitter-like demo application using Database Jones. The SQL script createtweettables.sql contains DDL statements for MySQL to create the five tables used by the demo application. It can be executed using the standard mysql command: mysql -u root < createtweettables.sql The Node.js application is a rather complete large example which can run as either as a command-line tool or as a REST web server. tweet.js supplements the simple API examples with sample code for explicit transaction handling and batching (e.g. in InsertTweetOperation at line 320). tweet.js responds to a number of verb-object commands; to see a list of them, simply type: node tweet Some demonstration scripts are provided to illustrate tweet.js: populates the database with some sample data. demonstrates querying the sample data from the command shell. demonstrates querying the sample data (and posting a new tweet) over the HTTP interface. uses the HTTP interface to delete the sample data. Note that in order to run the HTTP demo scripts, you should first start the server on port 7800, using the command: node tweet start server 7800 tweet.js pays attention to the environment variables `JONES_ADAPTER` (which defaults to "ndb") and `JONES_DEPLOYMENT` (which defaults to "test"). Jones applications connect to a particular database using a named deployment defined in the file . The sample code uses the "test" deployment. You can customize jones_deployments.js for your environment, and you can supply a different deployment as a command-line option in tweet.js or by editing the call to in the API samples.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.80.md

layout: release date: 2023-04-13 tag: v0.6.80 Migrate to OpenAPIV3 @Revolyssup (#7535) Revert "changes the application icon w/signoff" @Chadha93 (#7541) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Chadha93, @MUzairS15 and @Revolyssup
Project: KICS (Provisioning / Security & Compliance)
File: f29904c8-6041-4bca-b043-dfa0546b8079.md

title: Callback JSON Reference Does Not Exists hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: f29904c8-6041-4bca-b043-dfa0546b8079 Query name: Callback JSON Reference Does Not Exists Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Structure and Semantics URL: Callback reference should exists on components field<br> ```json title="Positive test num. 1 - json file" hl_lines="19" { "openapi": "3.0.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/components/schemas/Success" } }, "callbacks": { "myEvent": { "$ref": "#/components/callbacks/inProgress" } } } } }, "components": { "callbacks": { "onProgress": { "{$request.body#/onProgressUrl}": { "delete": { "responses": { "204": { "description": "Deleted" } } } } } } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="15" openapi: 3.0.0 info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: '200': "$ref": "#/components/schemas/Success" callbacks: myEvent: "$ref": "#/components/callbacks/inProgress" components: callbacks: onProgress: "{$request.body#/onProgressUrl}": delete: responses: '204': description: Deleted ``` ```json title="Negative test num. 1 - json file" { "openapi": "3.0.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/components/schemas/Success" } }, "callbacks": { "myEvent": { "$ref": "#/components/callbacks/inProgress" } } } } }, "components": { "callbacks": { "inProgress": { "{$request.body#/inProgressUrl}": { "delete": { "responses": { "204": { "description": "Deleted" } } } } } } } } ``` ```yaml title="Negative test num. 2 - yaml file" openapi: 3.0.0 info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: '200': "$ref": "#/components/schemas/Success" callbacks: myEvent: "$ref": "#/components/callbacks/inProgress" components: callbacks: inProgress: "{$request.body#/inProgressUrl}": delete: responses: '204': description: Deleted ```
Project: KICS (Provisioning / Security & Compliance)
File: 6db52fa6-d4da-4608-908a-89f0c59e743e.md

title: MSK Cluster Encryption Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 6db52fa6-d4da-4608-908a-89f0c59e743e Query name: MSK Cluster Encryption Disabled Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Ensure MSK Cluster encryption in rest and transit is enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 26 37 14" resource "awsmskcluster" "positive1" { cluster_name = "example" kafka_version = "2.4.1" numberofbroker_nodes = 3 } resource "awsmskcluster" "positive2" { cluster_name = "example" kafka_version = "2.4.1" numberofbroker_nodes = 3 encryption_info { encryptionintransit { client_broker = "PLAINTEXT" } } } resource "awsmskcluster" "positive3" { cluster_name = "example" kafka_version = "2.4.1" numberofbroker_nodes = 3 encryption_info { encryptionintransit { in_cluster = false } } } resource "awsmskcluster" "positive4" { cluster_name = "example" kafka_version = "2.4.1" numberofbroker_nodes = 3 encryption_info { encryptionintransit { client_broker = "PLAINTEXT" in_cluster = false } } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsmskcluster" "negative1" { encryption_info { encryptionatrestkmskeyarn = awskms_key.kms.arn } } resource "awsmskcluster" "negative2" { encryption_info { encryptionatrestkmskeyarn = awskms_key.kms.arn encryptionintransit { client_broker = "TLS" in_cluster = true } } } resource "awsmskcluster" "negative3" { encryption_info { encryptionatrestkmskeyarn = awskms_key.kms.arn encryptionintransit { client_broker = "TLS" } } } resource "awsmskcluster" "negative4" { encryption_info { encryptionatrestkmskeyarn = awskms_key.kms.arn encryptionintransit { in_cluster = true } } } ```
Project: KICS (Provisioning / Security & Compliance)
File: 53bce6a8-5492-4b1b-81cf-664385f0c4bf.md

title: S3 Bucket Allows Get 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: 53bce6a8-5492-4b1b-81cf-664385f0c4bf Query name: S3 Bucket Allows Get Action From All Principals Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Access Control URL: S3 Buckets must not allow Get 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 Get, for all Principals.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" name: Bucket amazon.aws.s3_bucket: name: mys3bucket state: present policy: Version: "2020-10-07" Statement: Effect: Allow Action: GetObject Principal: "*" ``` ```yaml title="Negative test num. 1 - yaml file" name: Bucket amazon.aws.s3_bucket: name: mys3bucket state: present policy: Version: '2020-10-07' Statement: Effect: Allow Action: GetObject Principal: NotAll ```
Project: secureCodeBox (Provisioning / Security & Compliance)
File: conventions.md

title: "Coding Conventions" sidebar_position: 5 Following... Following... We're using snake_case (lower case) for json attributes. If an enum type is used as attribute it's converted to lower case. If it's a value it's always used UPPERCASE. This is to hold the attribute api consistent, but make sure Enums are recognized as enums. ```json { "id": "e18cdc5e-6b49-4346-b623-28a4e878e154", "name": "Open mysql Port", "description": "Port 3306 is open using tcp protocol.", "category": "Open Port", "osi_layer": "NETWORK", "severity": "INFORMATIONAL", "attributes": { "protocol": "tcp", "port": 3306, "service": "mysql", "mac_address": null, "start": "1520606104", "end": "1520606118", "ip_address": "127.0.0.1", "state": "open" }, "location": "tcp://127.0.0.1:3306" } ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_project_iam_custom_role.md

+++ title = "googleprojectiamcustomrole resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleprojectiamcustomrole" identifier = "inspec/resources/gcp/googleprojectiamcustomrole.md googleprojectiamcustomrole resource" parent = "inspec/resources/gcp" +++ A `googleprojectiamcustomrole` is used to test a Google CustomRole resource ```ruby describe googleprojectiamcustomrole(project: 'chef-gcp-inspec', name: 'admin-role') do it { should exist } its('stage') { should eq 'GA' } its('included_permissions') { should eq ["iam.roles.list"] } end describe googleprojectiamcustomrole(project: 'chef-gcp-inspec', name: 'nonexistent') do it { should_not exist } end ``` describe googleprojectiamcustomrole(project: 'chef-inspec-gcp', name: 'chef-inspec-gcp-role-abcd') do its('stage') { should eq "GA" } end describe googleprojectiamcustomrole(project: 'chef-inspec-gcp', name: 'chef-inspec-gcp-role-abcd') do its('included_permissions') { should eq ["iam.roles.list"] } end Properties that can be accessed from the `googleprojectiamcustomrole` resource: `name` : The name of the role. `title` : A human-readable title for the role. Typically this is limited to 100 UTF-8 bytes. `description` : Human-readable description for the role `included_permissions` : Names of permissions this role grants when bound in an IAM policy. `stage` : The current launch stage of the role. Possible values: ALPHA BETA GA DEPRECATED DISABLED EAP `deleted` : The current deleted state of the role Ensure the is enabled for the current project.
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: request.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: request-http namespace: default spec: components: [] workflow: steps: name: request type: request properties: url: https://api.github.com/repos/kubevela/workflow outputs: name: stars valueFrom: | import "strconv" "Current star count: " + strconv.FormatInt(response["stargazers_count"], 10) name: notification type: notification inputs: from: stars parameterKey: slack.message.text properties: slack: url: value: <your slack url> name: failed-notification type: notification if: status.request.failed properties: slack: url: value: <your slack url> message: text: "Failed to request github" ```
Project: YugabyteDB (App Definition and Development / Database)
File: vitess.md

title: Compare Vitess with YugabyteDB headerTitle: Vitess linkTitle: Vitess description: Compare Vitess with the YugabyteDB database. aliases: /comparisons/vitess/ menu: preview_faq: parent: comparisons identifier: comparisons-vitess weight: 1077 type: docs Vitess is an automated sharding solution for MySQL. Each MySQL instance acts as a shard of the overall database. It uses etcd, a separate strongly consistent key-value store, to store shard location metadata such as which shard is located in which instance. Vitess uses a pool of stateless servers to route queries to the appropriate shard based on the mapping stored in etcd. Each instance uses standard MySQL source-replica replication to account for high availability. While Vitess presents a single logical SQL database to clients, it does not support distributed ACID transactions across shards. Application developers have to be aware of their sharding mechanism and account for it while designing their schema, as well as while executing queries as scalability may be impacted by queries which scatter across shards. Vitess does not make any enhancements to the asynchronous master-slave replication architecture of MySQL. For every shard in the Vitess cluster, another slave instance has to be created and replication has to be maintained. The end result is that Vitess cannot guarantee continuous availability during failures. Spanner-inspired distributed SQL databases like YugabyteDB solve this replication problem at the core using Raft distributed consensus at a per-shard level for both data replication and leader election.
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_create.md

title: "Command - devspace create" sidebar_label: devspace create Create spaces in the cloud ``` ``` ``` -h, --help help for create ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile string The devspace profile to use (if there is any) --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) ```
Project: ArangoDB (App Definition and Development / Database)
File: throw_exception.md

+++ title = "`BOOSTOUTCOMETHROW_EXCEPTION(expr)`" description = "How to throw a C++ exception, or equivalent thereof." +++ Throws a C++ exception, or equivalent thereof. Overridable: Define before inclusion. Default:<dl> <dt>Standalone Outcome (C++ exceptions enabled): <dd>To `throw expr` <dt>Standalone Outcome (C++ exceptions disabled): <dd>To `BOOSTOUTCOMEV2NAMESPACE::detail::dofatal_exit(#expr)` which is a function which prints a useful error message including a stack backtrace (where available) to `stderr` before calling `abort()`. <dt>Boost.Outcome: <dd>To `BOOSTTHROWEXCEPTION(expr)`. </dl> Header: `<boost/outcome/config.hpp>`
Project: Juju (Provisioning / Automation & Configuration)
File: ENV.md

The following is a list of environment variables that are used to control behaviour in the Bash tests. This list may not be complete, and as always, the definitive source is the code. | Variable name | Description | ||| | `BOOTSTRAPADDITIONALARGS` | Additional arguments passed to `juju bootstrap`. | | `BOOTSTRAP_ARCH` | Architecture to bootstrap on - passed to `--bootstrap-constraints`. | | `BOOTSTRAP_CLOUD` | The cloud to use when bootstrapping (i.e. the first argument to `juju bootstrap`). | | `BOOTSTRAP_PROVIDER` | The provider to use when bootstrapping (see the `provider` package). | | `BOOTSTRAP_REUSE` | Reuse an existing controller when asked to bootstrap (true/false). | | `BOOTSTRAPREUSELOCAL` | The name of a local controller to reuse for testing. Set using the `-l` flag. | | `BOOTSTRAP_SERIES` | Series to use for the controller. Set using the `-S` flag. | | `CONTROLLERCHARMCHANNEL` | The channel to pull the controller charm from (CaaS only). | | `CONTROLLERCHARMPATH_CAAS` | The Charmhub charm name to pull the controller charm from (CaaS only). | | `CONTROLLERCHARMPATH_IAAS` | Path to a locally built controller charm to use (IaaS only). | | `KILL_CONTROLLER` | If `'true'`, controllers will be forcibly killed during teardown. | | `MODEL_ARCH` | Will be set as a model constraint on newly added models. | | `OPERATORIMAGEACCOUNT` | Passed as the value of `--config caas-image-repo` when bootstrapping. | | `TEST_INSPECT` | If set, pause before teardown to allow inspection of the controller. |