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

slug: /en/sql-reference/statements/drop sidebar_position: 44 sidebar_label: DROP Deletes existing entity. If the `IF EXISTS` clause is specified, these queries do not return an error if the entity does not exist. If the `SYNC` modifier is specified, the entity is dropped without delay. Deletes all tables inside the `db` database, then deletes the `db` database itself. Syntax: ``` sql DROP DATABASE [IF EXISTS] db [ON CLUSTER cluster] [SYNC] ``` Deletes one or more tables. :::tip To undo the deletion of a table, please see ::: Syntax: ``` sql DROP [TEMPORARY] TABLE [IF EXISTS] [IF EMPTY] [db1.]name1[, [db2.]name2, ...] [ON CLUSTER cluster] [SYNC] ``` Limitations: If the clause `IF EMPTY` is specified, the server checks the emptiness of the table only on the replica which received the query. Deleting multiple tables at once is not an atomic operation, i.e. if the deletion of a table fails, subsequent tables will not be deleted. Deletes the dictionary. Syntax: ``` sql DROP DICTIONARY [IF EXISTS] [db.]name [SYNC] ``` Deletes a user. Syntax: ``` sql DROP USER [IF EXISTS] name [,...] [ON CLUSTER clustername] [FROM accessstorage_type] ``` Deletes a role. The deleted role is revoked from all the entities where it was assigned. Syntax: ``` sql DROP ROLE [IF EXISTS] name [,...] [ON CLUSTER clustername] [FROM accessstorage_type] ``` Deletes a row policy. Deleted row policy is revoked from all the entities where it was assigned. Syntax: ``` sql DROP [ROW] POLICY [IF EXISTS] name [,...] ON [database.]table [,...] [ON CLUSTER clustername] [FROM accessstorage_type] ``` Deletes a quota. The deleted quota is revoked from all the entities where it was assigned. Syntax: ``` sql DROP QUOTA [IF EXISTS] name [,...] [ON CLUSTER clustername] [FROM accessstorage_type] ``` Deletes a settings profile. The deleted settings profile is revoked from all the entities where it was assigned. Syntax: ``` sql DROP [SETTINGS] PROFILE [IF EXISTS] name [,...] [ON CLUSTER clustername] [FROM accessstorage_type] ``` Deletes a view. Views can be deleted by a `DROP TABLE` command as well but `DROP VIEW` checks that `[db.]name` is a view. Syntax: ``` sql DROP VIEW [IF EXISTS] [db.]name [ON CLUSTER cluster] [SYNC] ``` Deletes a user defined function created by . System functions can not be dropped. Syntax ``` sql DROP FUNCTION [IF EXISTS] function_name [on CLUSTER cluster] ``` Example ``` sql CREATE FUNCTION linear_equation AS (x, k, b) -> k*x + b; DROP FUNCTION linear_equation; ``` Deletes a named collection. Syntax ``` sql DROP NAMED COLLECTION [IF EXISTS] name [on CLUSTER cluster] ``` Example ``` sql CREATE NAMED COLLECTION foobar AS a = '1', b = '2'; DROP NAMED COLLECTION foobar; ```
Project: ShardingSphere (App Definition and Development / Database)
File: unload-single-table.en.md

+++ title = "UNLOAD SINGLE TABLE" weight = 2 +++ The `UNLOAD SINGLE TABLE` syntax is used to unload single table. {{< tabs >}} {{% tab name="Grammar" %}} ```sql unloadSingleTable ::= 'UNLOAD' 'SINGLE' 'TABLE' tableNames tableNames ::= tableName (',' tableName)* tableName ::= identifier ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} Unlike loading, only the table name needs to be specified when unloading a single table Unload specified single table ```sql UNLOAD SINGLE TABLE t_single; ``` Load all single tables ```sql UNLOAD SINGLE TABLE *; -- or UNLOAD ALL SINGLE TABLES; ``` `UNLOAD`, `SINGLE`, `TABLE`, `ALL`, `TABLES`
Project: CloudEvents (App Definition and Development / Streaming & Messaging)
File: couchdb.md

This document describes how to convert: and into CloudEvents. Each section below describes how to determine the CloudEvents attributes based on the event type. | CloudEvents Attribute | Value | | :-- | : | | `id` | The event sequence identifier (`seq`) | | `source` | The server URL / `db` | | `specversion` | `1.0` | | `type` | `org.apache.couchdb.document.updated` | | `datacontenttype` | `application/json` | | `subject` | The document identifier (`id`) | | `time` | Current time | | `data` | `changes` value (array of `revs`) | | CloudEvents Attribute | Value | | :-- | : | | `id` | The event sequence identifier (`seq`) | | `source` | The server URL / `db` | | `specversion` | `1.0` | | `type` | `org.apache.couchdb.document.deleted` | | `datacontenttype` | `application/json` | | `subject` | The document identifier (`id`) | | `time` | Current time | | `data` | `changes` value (array of `revs`) | | CloudEvents Attribute | Value | | :-- | : | | `id` | The event sequence identifier (`seq`) | | `source` | The server URL | | `specversion` | `1.0` | | `type` | `org.apache.couchdb.database.created` | | `subject` | The database name (`db_name`) | | `time` | Current time | | CloudEvents Attribute | Value | | :-- | : | | `id` | The event sequence identifier (`seq`) | | `source` | The server URL | | `specversion` | `1.0` | | `type` | `org.apache.couchdb.database.updated` | | `subject` | The database name (`db_name`) | | `time` | Current time | | CloudEvents Attribute | Value | | :-- | : | | `id` | The event sequence identifier (`seq`) | | `source` | The server URL | | `specversion` | `1.0` | | `type` | `org.apache.couchdb.database.deleted` | | `subject` | The database name (`db_name`) | | `time` | Current time |
Project: YugabyteDB (App Definition and Development / Database)
File: retry-failed-task.md

title: Use YugabyteDB Anywhere to retry failed tasks headerTitle: Retry a universe task linkTitle: Retry a universe task description: Use YugabyteDB Anywhere to retry failed tasks. menu: stable_yugabyte-platform: identifier: retry-task parent: manage-deployments weight: 75 type: docs In case of most task failures in YugabyteDB Anywhere (YBA) universes (VMs or Kubernetes), you can retry the tasks from the YBA UI or via an . To retry a failed task, do one of the following: Navigate to Universes in the YBA UI, select your universe, and click Retry task as per the following illustration: Navigate to Tasks in the YBA UI, click See Details corresponding to the failed universe task, and click Retry Task. A retry of the original task reruns the individual steps of the task in an idempotent fashion. This should resolve a failure if it was caused by a temporary issue. For example, a quota limit may prevent a universe scale up task, causing it to fail. When the quota limit is adjusted to the right value and the task is retried, it should succeed. If the underlying issue is more permanent, contact {{% support-platform %}}. Critical task failures, such as scaling a universe, placement changes, software upgrades, and flag changes block other critical tasks from being run on the universe. It is recommended to retry the failed task to completion before attempting other operations on the universe, or contact {{% support-platform %}} if the task continues to fail. Note that some operations, such as taking or creating , can always be attempted even after such failures.
Project: OAuth2 Proxy (Provisioning / Key Management)
File: tls.md

id: tls title: TLS Configuration There are two recommended configurations: Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`. The command line to run `oauth2-proxy` in this configuration would look like this: ```bash ./oauth2-proxy \ --email-domain="yourcompany.com" \ --upstream=http://127.0.0.1:8080/ \ --tls-cert-file=/path/to/cert.pem \ --tls-key-file=/path/to/cert.key \ --cookie-secret=... \ --cookie-secure=true \ --provider=... \ --client-id=... \ --client-secret=... ``` With this configuration approach the customization of the TLS settings is limited. The minimal acceptable TLS version can be set with `--tls-min-version=TLS1.3`. The defaults set `TLS1.2` as the minimal version. Regardless of the minimum version configured, `TLS1.3` is currently always used as the maximal version. TLS server side cipher suites can be specified with `--tls-cipher-suite=TLSRSAWITHRC4128_SHA`. If not specified, the defaults from of the currently used `go` version for building `oauth2-proxy` will be used. A complete list of valid TLS cipher suite names can be found in . Configure SSL Termination with (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ... Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or `--http-address="http://:4180"`. Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`. `oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example would be `https://internal.yourcompany.com/`. An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL via : ``` server { listen 443 default ssl; server_name internal.yourcompany.com; ssl_certificate /path/to/cert.pem; sslcertificatekey /path/to/cert.key; add_header Strict-Transport-Security max-age=2592000; location / { proxy_pass http://127.0.0.1:4180; proxysetheader Host $host; proxysetheader X-Real-IP $remote_addr; proxyconnecttimeout 1; proxysendtimeout 30; proxyreadtimeout 30; } } ``` The command line to run `oauth2-proxy` in this configuration would look like this: ```bash ./oauth2-proxy \ --email-domain="yourcompany.com" \ --upstream=http://127.0.0.1:8080/ \ --cookie-secret=... \ --cookie-secure=true \ --provider=... \ --reverse-proxy=true \ --client-id=... \ --client-secret=... ```
Project: Veinmind Tools (Provisioning / Security & Compliance)
File: veinmind-runner_completion_fish.md

Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: veinmind-runner completion fish | source To load completions for every new session, execute once: veinmind-runner completion fish > ~/.config/fish/completions/veinmind-runner.fish You will need to start a new shell for this setup to take effect. ``` veinmind-runner completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ``` -e, --exit-code int exit-code when veinmind-runner find security issues -g, --glob string specifies the pattern of plugin file to find -o, --output string output filepath of report --threads int threads for scan action (default 5) ``` - Generate the autocompletion script for the specified shell
Project: KICS (Provisioning / Security & Compliance)
File: e93bbe63-a631-4c0f-b6ef-700d48441ff2.md

title: ElastiCache Redis Cluster Without Backup hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e93bbe63-a631-4c0f-b6ef-700d48441ff2 Query name: ElastiCache Redis Cluster Without Backup Platform: Pulumi Severity: <span style="color:#ff7213">Medium</span> Category: Backup URL: ElastiCache Redis cluster should have 'snapshotRetentionLimit' higher than 0<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="9 17" name: aws-eks runtime: yaml description: An EKS cluster resources: example: type: aws:elasticache:Cluster properties: engine: redis snapshotRetentionLimit: 0 name: aws-eks runtime: yaml description: An EKS cluster resources: example: type: aws:elasticache:Cluster properties: engine: redis ``` ```yaml title="Negative test num. 1 - yaml file" name: aws-eks runtime: yaml description: An EKS cluster resources: example: type: aws:elasticache:Cluster properties: engine: redis snapshotRetentionLimit: 5 name: aws-eks runtime: yaml description: An EKS cluster resources: example: type: aws:elasticache:Cluster properties: engine: memcached ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: behalf.md

title: "Behalf" icon: /images/logos/powered-by/behalf.png hasLink: "https://www.behalf.com/" <!-- 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: Meshery (Provisioning / Automation & Configuration)
File: strimzi-registry-operator.md

layout: integration title: Strimzi Registry Operator subtitle: Collaborative and visual infrastructure as code for Strimzi Registry Operator image: /assets/img/integrations/strimzi-registry-operator/icons/color/strimzi-registry-operator-color.svg permalink: extensibility/integrations/strimzi-registry-operator docURL: https://docs.meshery.io/extensibility/integrations/strimzi-registry-operator description: integrations-category: App Definition and Development integrations-subcategory: Streaming & Messaging registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Kapitan (Provisioning / Automation & Configuration)
File: reclass-rs.md

is a reimplementation of Kapitan's Reclass fork in Rust. Please note that the Rust implementation doesn't support all the features of Kapitan's Reclass fork yet. However, reclass-rs improves rendering time for the inventory significantly, especially if you're making heavy use of parameter references in class includes. If some of the Reclass features or options that you're using are missing in reclass-rs, don't hesitate to open an issue in the . The `reclass-rs` Python package is an optional dependency of Kapitan. You can install it as follows: ```shell pip install kapitan[reclass-rs] ``` To use the reclass-rs inventory backend, you need to pass `--inventory-backend=reclass-rs` on the command line. If you want to permanently switch to the reclass-rs inventory backend, you can select the inventory backend in the : ```yaml global: inventory-backend: reclass-rs ``` For the performance comparison, a real Kapitan inventory which makes heavy use of parameter interpolation in class includes was rendered with both Reclass and reclass-rs. The example inventory that was used for the performance comparison contains 325 classes and 56 targets. The example inventory renders to a total of 25MB of YAML. ``` $ time kapitan inventory -v --inventory-backend=reclass > inv.yml [ ... some output omitted ... ] kapitan.resources DEBUG Using reclass as inventory backend kapitan.inventory.inv_reclass DEBUG Inventory reclass: No config file found. Using reclass inventory config defaults kapitan.inventory.inv_reclass DEBUG Inventory rendering with reclass took 0:01:06.037057 real 1m23.840s user 1m23.520s sys 0m0.287s ``` Reclass takes 1 minute and 6 seconds to render the example inventory. The rest of the runtime (roughly 18 seconds) is spent in writing the resulting 25MB of YAML to the output file. ``` $ time kapitan inventory -v --inventory-backend=reclass-rs > inv-rs.yml [ ... some output omitted ... ] kapitan.resources DEBUG Using reclass-rs as inventory backend kapitan.inventory.inv_reclass DEBUG Inventory reclass: No config file found. Using reclass inventory config defaults reclass-config.yml entry 'storagetype=yamlfs' not implemented yet, ignoring... reclass-config.yml entry 'inventorybaseuri=./inventory' not implemented yet, ignoring... reclass-config.yml entry 'allownoneoverride=true' not implemented yet, ignoring... kapitan.inventory.invreclassrs DEBUG Inventory rendering with reclass-rs took 0:00:01.717107 real 0m19.921s user 0m35.586s sys 0m1.066s ``` reclass-rs takes 1.7 seconds to render the example inventory. The rest of the runtime (roughly 18 seconds) is spent in writing the resulting 25MB of YAML to the output file.
Project: ClickHouse (App Definition and Development / Database)
File: v21.1.9.41-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Make FQDN and other DNS related functions work correctly in alpine images. (). Backported in : If PODArray was instantiated with element size that is neither a fraction or a multiple of 16, buffer overflow was possible. No bugs in current releases exist. (). Backported in : Fix very rare bug when quorum insert with `quorum_parallel=1` is not really "quorum" because of deduplication. (). Backported in : In case if query has constant `WHERE` condition, and setting `optimizeskipunused_shards` enabled, all shards may be skipped and query could return incorrect empty result. (). Backported in : Fix possible error ` Cannot find column` when `optimizeskipunused_shards` is enabled and zero shards are used. (). Backported in : Fix usage of function `map` in distributed queries. (). Backported in : Fix approx total rows accounting for reverse reading from MergeTree. (). Backported in : Fixed a crash when using `mannWhitneyUTest` and `rankCorr` with window functions. This fixes . (). Backported in : Allow to start up with modified binary under gdb. In previous version if you set up breakpoint in gdb before start, server will refuse to start up due to failed integrity check. (). Check for EINTR in epoll_wait (). FileDictionarySource fix absolute file path ().
Project: Crunchy Postgres Operator (App Definition and Development / Database)
File: wal.md

<!-- Copyright 2021 - 2024 Crunchy Data Solutions, Inc. 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. --> PostgreSQL commits transactions by storing changes in its . The contents of the log are applied to data files (containing tables and indexes) later as part of a checkpoint. The way WAL files are accessed and utilized often differs from that of data files. In high-performance situations, it can desirable to put WAL files on storage with different performance or durability characteristics. PostgresCluster has a field that specifies how to store PostgreSQL data files and an optional field for how to store PostgreSQL WAL files. When a WAL volume is specified the PostgresCluster controller reconciles one "pgwal" PVC per instance in the instance set. When a PostgresCluster is created with a WAL volume specified, the `--waldir` argument to `initdb` ensures that WAL files are written to WAL volume. When creating a replica (e.g. scaling up) the `--waldir` argument to `pg_basebackup` does the same. The way pgBackRest handles this depends on the contents of the backup, but when creating a replica the `--link-map=pg_wal` argument does the same. It is possible to specify a WAL volume on PostgresCluster after it has already bootstrapped, has data, etc. In this case, the WAL PVC is reconciled and mounted as usual and an init container moves any existing WAL files while PostgreSQL is stopped. These are changes to the instance PodTemplate and go through the normal rollout procedure. It is possible to remove the specification of a WAL volume on PostgresCluster after it has already bootstrapped, has data, etc. In this case, a series of rollouts moves WAL files off the volume then unmounts and deletes the PVC. First, the command of the init container is adjusted to match the PostgresCluster spec -- WAL files belong off the WAL volume. The WAL PVC continues to exist and remains mounted in the PodSpec. This change to the PodTemplate is rolled out, allowing the init container to move WAL files off the WAL volume while PostgreSQL is stopped. When the PostgreSQL container of an instance Pod starts running, the PostgresCluster controller examines the WAL directory inside its volume. When the WAL files are safely off the WAL volume, it deletes the WAL PVC and removes it from the PodSpec. This change to the PodTemplate goes through the normal rollout procedure.
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: ENG-003-test-infrastructure.md

Proposal E2E tests ensure the functional correctness in an e2e environment in order to make sure Dapr works with the user code deployments. The tests will be run before / after PR is merged or by a scheduler. Dapr E2E tests require the test infrastructure in order to not only test Dapr functionalities, but also show these test results in a consistent way. This document will decide how to bring up the test cluster, run the test, and report the test results. Although Dapr is designed for multi cloud environments, e2e tests will be run under Kubernetes environments for now. We will support two different options to run e2e tests with local machine and CI on the pre-built Kubernetes cluster. Local machine*. contributors or developers will use to validate their changes and run new tests before creating Pull Request. Continuous Integration*. E2E tests will be run in the pre-built before/after PR is merged or by a scheduler. Even if we will use in our test infrastructure, contributors should run e2e tests in any RBAC-enabled Kubernetes clusters. We will provide the manual instruction or simple script to bring up test infrastructure unlike the other Kubernetes projects using . Dapr E2E tests will clean up and revert all configurations in the cluster once the test is done. Without kubetest, we can create e2e tests simpler without the dependency of the 3rd party test frameworks, such as ginkgo, gomega. Many Kubernetes-related projects use , and for Test CI, PR, and test result management. However, we will not use them to run Dapr E2E tests and share the test result since we need to self-host them on Google cloud platform. Instead, Dapr will use to run e2e tests and its without self-hosted CI and test report services. Even contributors can get their own azure pipelines accounts for free without self-hosting them. Dapr E2E tests will run in with local machine and with CI, but the tests will run in any RBAC-enabled Kubernetes clusters We will provide the manual instruction and scripts to build test Kubernetes cluster will run e2e tests before/after PR is merged or by a scheduler and report test results