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

title: CREATE DATABASE statement [YSQL] headerTitle: CREATE DATABASE linkTitle: CREATE DATABASE description: Use the CREATE DATABASE statement to create a database that functions as a grouping mechanism for database objects, such as tables. menu: v2.18: identifier: ddlcreatedatabase parent: statements type: docs Use the `CREATE DATABASE` statement to create a database that functions as a grouping mechanism for database objects, such as . {{%ebnf%}} create_database, createdatabaseoptions {{%/ebnf%}} Specify the name of the database to be created. An error is raised if a YSQL database of the given `name` already exists. Specify the role name of the user who will own the new database. When not specified, the database creator is the owner. Specify the name of the template from which the new database is created. Specify the character set encoding to use in the new database. Specify the collation order (`LC_COLLATE`). Specify the character classification (`LC_CTYPE`). Specify `false` to disallow connections to the database. Default is `true`, which allows connections to the database. Specify how many concurrent connections can be made to this database. Default of `-1` allows unlimited concurrent connections. `true` This database can be cloned by any user with `CREATEDB` privileges. Specify `false` to only superusers or the owner of the database can clone it. Specify `true` if tables for this database should be colocated on a single tablet by default. See for details on when colocated tables are beneficial. Default is `false` and every table in the database will have its own set of tablets. ```plpgsql yugabyte=# CREATE DATABASE company WITH COLOCATION = true; ``` In this example, tables in the database `company` will be colocated on a single tablet by default.
Project: Koperator (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTING.md

Thanks for your interest in contributing to Koperator! Here are a few general guidelines on contributing and reporting bugs that we ask you to review. Following these guidelines helps to communicate that you respect the time of the contributors managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests. In that spirit of mutual respect, we endeavor to review incoming issues and pull requests within 10 days, and will close any lingering issues or pull requests after 60 days of inactivity. Please note that all of your interactions in the project are subject to our . This includes creation of issues or pull requests, commenting on issues or pull requests, and extends to all interactions in any real-time space e.g., Slack, Discord, etc. Before reporting a new issue, please ensure that the issue was not already reported or fixed by searching through our . When creating a new issue, please be sure to include a title and clear description, as much relevant information as possible, and, if possible, a test case. If you discover a security bug, please do not report it through GitHub. Instead, please see security procedures in . Before sending a new pull request, take a look at existing pull requests and issues to see if the proposed change or fix has been discussed in the past, or if the change was already implemented but not yet released. We expect new pull requests to include tests for any affected behavior, and, as we follow semantic versioning, we may reserve breaking changes until the next major version release. We welcome anyone that wants to contribute to Koperator to triage and reply to open issues to help troubleshoot and fix existing bugs. Here is what you can do: Help ensure that existing issues follows the recommendations from the section, providing feedback to the issue's author on what might be missing. Review and update the existing content of our with up-to-date instructions and code samples. Review existing pull requests, and testing patches against real existing applications that use Koperator. Write a test, or add a missing test case to an existing test. Thanks again for your interest on contributing to Koperator! :heart:
Project: Flink (App Definition and Development / Streaming & Messaging)
File: process_function.md

title: "Process Function" weight: 4 type: docs <!-- 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. --> The `ProcessFunction` is a low-level stream processing operation, giving access to the basic building blocks of all (acyclic) streaming applications: events (stream elements) state (fault-tolerant, consistent, only on keyed stream) timers (event time and processing time, only on keyed stream) The `ProcessFunction` can be thought of as a `FlatMapFunction` with access to keyed state and timers. It handles events by being invoked for each event received in the input stream(s). Please refer to for more details about the concept and usage of `ProcessFunction`. Python user-defined functions are executed in a separate Python process from Flink's operators which run in a JVM, the timer registration requests made in `ProcessFunction` will be sent to the Java operator asynchronously. Once received timer registration requests, the Java operator will register it into the underlying timer service. If the registered timer has already passed the current time (the current system time for processing time timer, or the current watermark for event time), it will be triggered immediately. Note that, due to the asynchronous processing characteristics, it may happen that the timer was triggered a little later than the actual time. For example, a registered processing time timer of `10:00:00` may be actually processed at `10:00:05`.
Project: KICS (Provisioning / Security & Compliance)
File: cc997676-481b-4e93-aa81-d19f8c5e9b12.md

title: EBS Volume Encryption Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: cc997676-481b-4e93-aa81-d19f8c5e9b12 Query name: EBS Volume Encryption Disabled Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: EBS volumes should be encrypted<br> ```tf title="Positive test num. 1 - tf file" hl_lines="4" resource "awsebsvolume" "positive1" { availability_zone = "us-west-2a" size = 40 encrypted = false tags = { Name = "HelloWorld" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" resource "awsebsvolume" "positive2" { availability_zone = "us-west-2a" size = 40 tags = { Name = "HelloWorld" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsebsvolume" "negative1" { availability_zone = "us-west-2a" size = 40 encrypted = true tags = { Name = "HelloWorld" } } ```
Project: CyberArk Conjur (Provisioning / Key Management)
File: authenticator_whitelist_api.md

Enabling and disabling authenticators is a common workflow when setting up Conjur or when adding new integrations. Authenticators are defined and configured using Conjur policy at runtime, but to enable and use an authenticator it has to first be whitelisted. The authenticator whitelist was previously managed with the `CONJUR_AUTHENTICATORS` environment variable. This, however, also requires the Conjur process to be restarted, and often requires updates to configuration management for the Conjur container as well. By storing the authenticator whitelist in the Conjur database, and adding an HTTP API endpoint to manage the whitelist, we both allow the authenticator workflow to become more streamlined, as well as enable additional usability (e.g. enabling or disabling authenticators using the `conjur` CLI). These endpoints require authentication and permission to read and update the given authenticator's `!webservice` resource. URL:* `/:authenticator/:service_id/:account` Example: `/authn-k8s/my-authenticator/my-company` Method:* `PATCH` URL Parameters:* `:authenticator`: The authenticator type (e.g. `authn-k8s`, `authn-oidc`). `:serviceid`: The name of the authenticator from the policy (`!webservice <serviceid>`). `:account`: The Conjur account in which to enable this authenticator. Request Content Type:* `application/x-www-form-urlencoded` Body:* The Authenticator patch endpoint takes a single parameter, `enabled`, which may be set to either `true` to enable the authenticator (add it to the whitelist) or `false` to disable the authenticator (remove it from the whitelist). Example: ``` enabled=true ``` Success Response:* `204 No Content` ```sh curl --request PATCH \ --data "enabled=true" \ https://conjur.mycompany.net/authn-k8s/my-authenticator/my-account ``` ```sh curl --request PATCH \ --data "enabled=false" \ https://conjur.mycompany.net/authn-k8s/my-authenticator/my-account ```
Project: Cyclops (App Definition and Development / Application Definition & Image Build)
File: dependencies.md

This part will go over how Cyclops implements Helm chart dependencies. You can find out more about chart dependencies on . Dependencies allow us to reference another Helm chart and use it in the context of our application without having to configure multiple K8s resources separately. For instance, you might want to deploy an application that uses Redis as its cache storage, but you don't want to add all of those resources for a Redis deployment into your template. You can simply add an existing Redis Helm chart as a dependency to your chart and get your Redis up and running without the hassle of copy-pasting resources. Since Helm supports dependencies, it makes sense that Cyclops also supports them. You can reference dependencies in the `Chart.yaml` of your root template if you want to use dependencies. Refer to Helm docs for more info on how to do it, but here is an of how to do it. ```yaml apiVersion: v1 name: application version: 0.0.0 dependencies: name: application version: "0.3.0" repository: "https://petar-cvit.github.io" ``` Cyclops will render a new object in your UI for each dependency you specify. This object will be named after the dependency, and its fields will be rendered based on its JSON schema. It does that recursively for all dependencies. In our templates repository you can find the . This template will give you an idea of how to create dependencies of your own and we will use this template for this demo. First, go to the Templates tab and add this template to your templates store. ```yaml Name: dependencies-demo Repository URL: https://github.com/cyclops-ui/templates Path: dependencies-demo ``` Once you added this template to your collection, go to the Modules tab and click Add Module. Choose your new template `dependencies-demo`. You should get a screen similar to the one in the picture below. All the fields from the template have been rendered as expected and alongside them on an additional object -- `application`. It is called `application` since it is the name of the dependency we pulled. All the nested fields inside it are rendered based on dependency schema, so be aware that your dependencies must also have a schema defined. It is also automatically populated with default fields from the dependent charts `values.yaml`. Here is the link to the GitHub repo where the dependency chart is stored Once you input all the fields and hit the `save` button, all resources from your root template and all its dependencies get deployed and shown on your Module detail page. :::info Version `v0.0.8-alpha` does not support `alias` and `import-values`. At the moment, when you reference a dependency, it is automatically included in your chart. `condition` and `tags` properties are not yet supported. :::
Project: Meshery (Provisioning / Automation & Configuration)
File: configuring-autocompletion-for-mesheryctl.md

layout: default title: Configuring Autocompletion for `mesheryctl` permalink: guides/mesheryctl/configuring-autocompletion-for-mesheryctl language: en type: guides category: mesheryctl list: include abstract: Bash, Zsh, Oh My Zsh, and fish autocompletion for `mesheryctl` commands. If you would like to have `mesheryctl` commands automatically completed for use as you use `mesheryctl`, then use the following instructions to configure automatic completion within your environment. <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">source /dev/stdin <<< "$(mesheryctl completion bash)"</div></div> </pre> <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">source <(mesheryctl completion bash)</div></div> </pre> <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">brew install bash-completion # ensure you have bash-completion 1.3+ mesheryctl completion bash > $(brew --prefix)/etc/bash_completion.d/mesheryctl</div></div> </pre> <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">brew install bash-completion@2 mesheryctl completion bash > $(brew --prefix)/etc/bash_completion.d/mesheryctl</div></div> </pre> <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">source <(mesheryctl completion zsh)</div></div> </pre><br> If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">~/.zshrc > echo "autoload -U compinit; compinit"</div></div> </pre> Note : You might need to restart your shell for this setup to take effect. <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">COMPLETIONDIR=$(echo $fpath | grep -o '[^ ]*completions' | grep -v cache) && mkdir -p $COMPLETIONDIR && mesheryctl completion zsh > "${COMPLETIONDIR}/mesheryctl"</div></div> </pre> <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">mesheryctl completion fish | source</div></div> </pre><br> To load fish shell completions for each session, execute once: <pre class="codeblock-pre"><div class="codeblock"> <div class="clipboardjs">mesheryctl completion fish > ~/.config/fish/completions/mesheryctl.fish</div></div> </pre> For an exhaustive list of `mesheryctl` commands and syntax: See . Guides to using Meshery's various features and components. {% capture tag %} <li><a href="{{ site.baseurl }}/guides/upgrade#upgrading-meshery-cli">Upgrading mesheryctl</a></li> {% endcapture %} {% include related-discussions.html tag="mesheryctl" %}
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_plugin_kubectl.Pod.md

/ / Pod .Pod <`PodStatus`\> `Pod` apiVersion: `"v1"` KubeResource.apiVersion `Optional` content: `void` KubeResource.content packages/core/mdist/models/entity.d.ts:50 `Optional` contentType: `string` KubeResource.contentType packages/core/mdist/models/entity.d.ts:51 isKubeResource: `true` KubeResource.isKubeResource `Optional` isSimulacrum: `boolean` KubeResource.isSimulacrum kind: `"Pod"` KubeResource.kind `Optional` kuiRawData: `string` KubeResource.kuiRawData `Optional` metadata: { `creationTimestamp?`: `string` ; `generation?`: `string` ; `labels?`: `Record`<`string`, `string`\> ; `name`: `string` ; `namespace?`: `string` } & `Partial`<`WithOwnerReferences`\> & `Partial`<`WithResourceVersion`\> & { `annotations?`: `object` ; `creationTimestamp?`: `string` ; `generateName?`: `string` ; `generation?`: `string` ; `labels?`: { [key: string]: `string`; } ; `name`: `string` ; `namespace?`: `string` ; `uid?`: `string` } KubeResource.metadata packages/core/mdist/models/entity.d.ts:23 `Optional` nameHash: `string` KubeResource.nameHash packages/core/mdist/models/entity.d.ts:42 `Optional` onclick: `Object` family of onclick handlers | Name | Type | | :-- | :- | | `kind?` | `string` | | `name?` | `string` | | `nameHash?` | `string` | | `namespace?` | `string` | KubeResource.onclick packages/core/mdist/models/entity.d.ts:44 originatingCommand: `EvaluatorArgs`<\> KubeResource.originatingCommand `Optional` presentation: `Presentation` KubeResource.presentation packages/core/mdist/models/entity.d.ts:53 `Optional` prettyName: `string` name hash, e.g. the hash part of auto-generated names, or an openwhisk activation id KubeResource.prettyName packages/core/mdist/models/entity.d.ts:41 spec: & { `containers`: `ContainerSpec`[] ; `nodeName`: `string` ; `nominatedNodeName?`: `string` ; `readinessGates?`: { `conditionType`: `string` }[] } KubeResource.spec `Optional` status: `PodStatus` KubeResource.status `Optional` toolbarText: `ToolbarText` KubeResource.toolbarText packages/core/mdist/models/entity.d.ts:52 `Optional` version: `string` optional designation of resource version KubeResource.version packages/core/mdist/models/entity.d.ts:39
Project: YugabyteDB (App Definition and Development / Database)
File: extension-file-fdw.md

title: file_fdw extension headerTitle: file_fdw extension linkTitle: file_fdw description: Using the file_fdw extension in YugabyteDB menu: v2.18: identifier: extension-file-fdw parent: pg-extensions weight: 20 type: docs The module provides the foreign-data wrapper `file_fdw`, which can be used to access data files in the server's file system, or to execute programs on the server and read their output. To enable the extension: ```sql CREATE EXTENSION file_fdw; ``` Create a foreign server: ```sql CREATE SERVER myserver FOREIGN DATA WRAPPER filefdw; ``` Now, you can create foreign tables that access data from files. For example: ```sql CREATE FOREIGN TABLE employees (id int, employeename varchar) SERVER myserver OPTIONS (filename 'employees.csv', format 'csv'); ``` You can execute `SELECT` statements on the foreign tables to access the data in the corresponding files.
Project: YDB (App Definition and Development / Database)
File: aggregate.md

All can also be used as window functions. In this case, each row includes an aggregation result obtained on a set of rows from the . Examples: ```yql SELECT SUM(intcolumn) OVER w1 AS runningtotal, SUM(int_column) OVER w2 AS total, FROM my_table WINDOW w1 AS (ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), w2 AS (); ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: docker_plugin.md

+++ title = "docker_plugin resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "docker_plugin" identifier = "inspec/resources/os/dockerplugin.md dockerplugin resource" parent = "inspec/resources/os" +++ Use the `docker_plugin` Chef InSpec audit resource to verify a Docker plugin. A `docker_plugin` resource block declares the plugin: describe docker_plugin('rexray/ebs') do it { should exist } its('id') { should_not eq '0ac30b93ad40' } its('version') { should eq '0.11.1' } it { should be_enabled } end The resource allows you to pass in an plugin id: describe dockerplugin(id: pluginid) do it { should be_enabled } end The `id` property returns the full plugin id: its('id') { should eq '0ac30b93ad40' } The `version` property tests the value of plugin version: its('version') { should eq '0.11.0' } describe docker_plugin('rexray/ebs') do it { should exist } its('id') { should_not eq '0ac30b93ad40' } its('version') { should eq '0.11.1' } it { should be_enabled } end For a full list of available matchers, please visit our . The `exist` matcher tests if the plugin is available on the node: describe docker_plugin('rexray/ebs') do it { should exist } end The `be_enabled` matches tests if the plugin is enabled
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.138.md

layout: release date: 2023-09-09 tag: v0.6.138 Revert "chore: Sort the technology list in alphabetical order" @Yashsharma1911 (#8706) Thank you to our contributors for making this release possible: @Yashsharma1911 and @leecalcote
Project: YugabyteDB (App Definition and Development / Database)
File: zcard.md

title: ZCARD linkTitle: ZCARD description: ZCARD menu: preview: parent: api-yedis weight: 2510 aliases: /preview/api/redis/zcard /preview/api/yedis/zcard type: docs `ZCARD key` This command returns the number of `members` in the sorted set at `key`. If `key` does not exist, 0 is returned. If `key` is associated with non sorted-set data, an error is returned. The cardinality of the sorted set. You can do this as shown below. ```sh $ ZADD z_key 1.0 v1 2.0 v2 ``` ``` (integer) 2 ``` ```sh $ ZADD z_key 3.0 v2 ``` ``` (integer) 0 ``` ```sh $ ZCARD z_key ``` ``` (integer) 2 ``` ```sh $ ZCARD ts_key ``` ``` (integer) 0 ``` , , , ,
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: promote_packages.md

+++ title = "Promote Packages Through Channels" description = "Promote Packages Through Channels" gh_repo = "habitat" [menu] [menu.habitat] title = "Promote Packages Through Channels" identifier = "habitat/diagrams/promote-packages" parent = "habitat/diagrams" weight = 70 +++
Project: ArangoDB (App Definition and Development / Database)
File: co_tryx_failure_likely.md

+++ title = "`BOOSTOUTCOMECOTRYXFAILURE_LIKELY(expr)`" description = "Evaluate from within a coroutine an expression which results in an understood type, emitting the `T` if successful, immediately returning `tryoperationreturn_as(X)` from the calling function if unsuccessful." +++ Evaluate within a coroutine an expression which results in a type matching the following customisation points, emitting the `T` if successful, immediately returning {{% api "tryoperationreturn_as(X)" %}} from the calling function if unsuccessful: `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationhasvalue(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationreturnas(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationextractvalue(X)" %}} Default overloads for these customisation points are provided. See . Hints are given to the compiler that the expression will be unsuccessful. If you expect success, you should use {{% api "BOOSTOUTCOMECO_TRYX(expr)" %}} instead. An internal temporary to hold the value of the expression is created, which generally invokes a copy/move. Availability: GCC and clang only. Use `#ifdef BOOSTOUTCOMECO_TRYX` to determine if available. Overridable: Not overridable. Definition: See {{% api "BOOSTOUTCOMECO_TRYV(expr)" %}} for most of the mechanics. This macro makes use of a proprietary extension in GCC and clang to emit the `T` from a successful expression. You can thus use `BOOSTOUTCOMECOTRYX(expr)` directly in expressions e.g. `auto x = y + BOOSTOUTCOMECOTRYX(foo(z));`. Be aware there are compiler quirks in preserving the rvalue/lvalue/etc-ness of emitted `T`'s, specifically copy or move constructors may be called unexpectedly and/or copy elision not work as expected. If these prove to be problematic, use {{% api "BOOSTOUTCOMECO_TRY(var, expr)" %}} instead. Header: `<boost/outcome/try.hpp>`