cwielenb/CNCF-Dataset huggingface dataset:
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-system-provider.md

layout: default title: mesheryctl-system-provider permalink: reference/mesheryctl/system/provider redirect_from: reference/mesheryctl/system/provider/ type: reference display-title: "false" language: en command: system subcommand: provider Switch between providers Enforce a provider. Choose between available Meshery providers <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider [flags] </div> </pre> To view provider <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider view </div> </pre> To list all available providers <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider list </div> </pre> To set a provider <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider set [provider] </div> </pre> To switch provider and redeploy Meshery <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider switch [provider] </div> </pre> To reset provider to default <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system provider reset </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for provider </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -c, --context string (optional) temporarily change the current context. -v, --verbose verbose output -y, --yes (optional) assume yes for user interactive prompts. </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: ShardingSphere (App Definition and Development / Database)
File: drop-shadow-algorithm.en.md

+++ title = "DROP SHADOW ALGORITHM" weight = 7 +++ The `DROP SHADOW ALGORITHM` syntax is used to drop shadow algorithm for specified database {{< tabs >}} {{% tab name="Grammar" %}} ```sql DropShadowAlgorithm ::= 'DROP' 'SHADOW' 'ALGORITHM' ifExists? algorithmName (',' algorithmName)* ('FROM' databaseName)? ifExists ::= 'IF' 'EXISTS' algorithmName ::= identifier 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; `ifExists` clause is used for avoid `shadow algorithm not exists` error. Drop mutiple shadow algorithm for specified database ```sql DROP SHADOW ALGORITHM shadowruletordersqlhint0, shadowruletorderitemsqlhint0 FROM shadowdb; ``` Drop single shadow algorithm for current database ```sql DROP SHADOW ALGORITHM shadowruletordersqlhint0; ``` Drop shadow algorithm with `ifExists` clause ```sql DROP SHADOW ALGORITHM IF EXISTS shadowruletordersqlhint0; ``` `DROP`, `SHODOW`, `ALGORITHM`, `FROM`
Project: Harbor (Provisioning / Container Registry)
File: 7-02-Proj-replication-rules-edit.md

Test 7-02 - Edit replication rules ======= To verify admin user can edit replication rules. User guide This test requires that at least two Harbor instances are running and available. Need at least one replication rule has been created. Login UI as admin user. In `Administration->Replications` page, choose a rule and edit its configurations. Repeat steps 1-2 under `Projects->Project_Name->Replication` page. In step 2, Rule can be edited. None
Project: YugabyteDB (App Definition and Development / Database)
File: extension-passwordcheck.md

title: passwordcheck extension headerTitle: passwordcheck extension linkTitle: passwordcheck description: Using the passwordcheck extension in YugabyteDB menu: v2.18: identifier: extension-passwordcheck parent: pg-extensions weight: 20 type: docs The PostgreSQL module provides a means to check user passwords whenever they are set with CREATE ROLE or ALTER ROLE. If a password is considered too weak, it will be rejected and the command will terminate with an error. To enable the passwordcheck extension, add `passwordcheck` to `sharedpreloadlibraries` in the PostgreSQL server configuration parameters using the YB-TServer flag: ```sh --ysqlpgconfcsv="sharedpreload_libraries=passwordcheck" ``` Note that modifying `sharedpreloadlibraries` requires restarting the YB-TServer. You can customize the following passwordcheck parameters: | Parameter | Description | Default | | : | : | : | | minimum_length | Minimum password length. | 8 | | maximum_length | Maximum password length. | 15 | | restrict_lower | Passwords must include a lowercase character. | true | | restrict_upper | Passwords must include an uppercase character. | true | | restrict_numbers | Passwords must include a number. | true | | restrict_special | Passwords must include a special character. | true | | specialchars | The set of special characters. | <code>!@#$%^&*()+{}\|\<\>?=</code> | For example, the following flag changes the minimum and maximum passwordcheck lengths: ```sh --ysqlpgconfcsv="sharedpreloadlibraries=passwordcheck,passwordcheck.minimumlength=10,passwordcheck.maximum_length=18" ``` You can change passwordcheck parameters for the current session only using a `SET` statement. For example, to increase the maximum length allowed and not require numbers, execute the following commands: ```sql SET passwordcheck.maximum_length TO 20; SET passwordcheck.restrict_numbers TO false; ``` When enabled, if a password is considered too weak, it's rejected with an error. For example: ```sql yugabyte=# create role test_role password 'tooshrt'; ``` ```output ERROR: password is too short ``` ```sql yugabyte=# create role test_role password 'nonumbers'; ``` ```output ERROR: password must contain both letters and nonletters ``` ```sql yugabyte=# create role testrole password '12testrole12'; ``` ```output ERROR: password must not contain user name ``` The passwordcheck extension only works for passwords that are provided in plain text. For more information, refer to the .
Project: Flink (App Definition and Development / Streaming & Messaging)
File: _index.md

title: Try Flink icon: <i class="fa fa-rocket title appetizer" aria-hidden="true"></i> bold: true bookCollapseSection: true weight: 1 <!-- 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. -->
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: headlamp_annotations.md

You can provide some extra information about your Headlamp plugins by using the `annotations` field in the . headlamp/plugin/archive-url (string, required) Plugin archive tarball URL (e.g. "https://.../my-archive.tar.gz"). headlamp/plugin/archive-checksum (string, required) Plugin archive tarball checksum (e.g. "sha256:MY_CHECKSUM"). headlamp/plugin/version-compat (string, optional) Headlamp versions this plugin is compatible with (e.g. ">=1.2.3"). headlamp/plugin/distro-compat (string, optional) Headlamp flavor this plugin is compatible with (e.g. one or more of app, in-cluster, web, docker-desktop, linux, windows, mac). ```yaml ... annotations: headlamp/plugin/archive-url: "https://.../my-archive.tar.gz" headlamp/plugin/archive-checksum: "sha256:MY_CHECKSUM" headlamp/plugin/version-compat: ">=1.2.3" headlamp/plugin/distro-compat: "in-cluster,web,docker-desktop" ```
Project: Rudder (Provisioning / Security & Compliance)
File: introduction.md

Download OpenAPI specification: Other documentation sources: Rudder relay exposes an internal API, enabling the agents and other services to interact with the relay. A part of the API (everything but the `System` category) is exposed publicly on the relay at `https://relay.example.com/rudder/relay-api/` (which is a reverse proxy of `http://localhost:3030/rudder/relay-api/1/`). The relay API is authenticated on a case-by-case basis: Remote run* is only accessible to requests from the IP of the relay's own policy server Shared files* checks file signature based on known public keys from nodes Shared folder* is only available to nodes in the authorized networks System* is only accessible to local clients and do not permit access to private information nor modification abilities Each time the API is extended with new features (new functions, new parameters, new responses, ...), it will be assigned a new version number. This will allow you to keep your existing scripts (based on previous behavior). Versions will always be integers (no 2.1 or 3.3, just 2, 3, 4, ...). You can change the version of the API used by setting in the URL: each URL is prefixed by its version id, like `/relay-api/version/action`. In the future, we may declare some versions as deprecated, in order to remove them in a later version of Rudder, but we will never remove any versions without warning, or without a safe period of time to allow migration from previous versions. <table> <thead> <tr> <th style="width: 20%">Version</th> <th style="width: 20%">Rudder version it appeared in</th> <th style="width: 70%">Description</th> </tr> </thead> <tbody> <tr> <td class="code">(none)</td> <td class="code">3.2</td> <td>Unversioned API providing remote-run, shared-files and shared-folder</td> </tr> <tr> <td class="code">1</td> <td class="code">6.0</td> <td>First relay API with a version</td> </tr> </tbody> </table> The System API and future endpoints use JSON with the following schema: ```json { "action": The name of the called function, "result": The result of your action: success or error, "data": Only present if this is a success and depends on the function, it's usually a JSON object, "errorDetails": Only present if this is an error, it contains the error message } ```
Project: YugabyteDB (App Definition and Development / Database)
File: drop_matview.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="546" height="120" viewbox="0 0 546 120"><path class="connector" d="M0 22h15m53 0h10m111 0h10m53 0h30m32 0h10m64 0h20m-141 0q5 0 5 5v8q0 5 5 5h116q5 0 5-5v-8q0-5 5-5m5 0h10m113 0h7m2 0h2m2 0h2m-546 50h2m2 0h2m2 0h27m77 0h22m-109 25q0 5 5 5h5m79 0h5q5 0 5-5m-104-25q5 0 5 5v33q0 5 5 5h89q5 0 5-5v-33q0-5 5-5m5 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="53" height="25" rx="7"/><text class="text" x="25" y="22">DROP</text><rect class="literal" x="78" y="5" width="111" height="25" rx="7"/><text class="text" x="88" y="22">MATERIALIZED</text><rect class="literal" x="199" y="5" width="53" height="25" rx="7"/><text class="text" x="209" y="22">VIEW</text><rect class="literal" x="282" y="5" width="32" height="25" rx="7"/><text class="text" x="292" y="22">IF</text><rect class="literal" x="324" y="5" width="64" height="25" rx="7"/><text class="text" x="334" y="22">EXISTS</text><a xlink:href="../../../syntaxresources/grammardiagrams#matview-name"><rect class="rule" x="418" y="5" width="113" height="25"/><text class="text" x="428" y="22">matview_name</text></a><rect class="literal" x="35" y="55" width="77" height="25" rx="7"/><text class="text" x="45" y="72">CASCADE</text><rect class="literal" x="35" y="85" width="79" height="25" rx="7"/><text class="text" x="45" y="102">RESTRICT</text><polygon points="145,79 149,79 149,65 145,65" style="fill:black;stroke-width:0"/></svg>
Project: userver (App Definition and Development / Streaming & Messaging)
File: releases.md

Information on production usage of userver source code and guarantees. Yes. We are successfully using userver for ages for many high-load high-availability services in production. Make an experiment to make sure that the current functionality suits your needs. If there's something missing, please fill a . userver follows the Trunk-Based Development model. In practice it means that all the revisions from the `develop` branch work fine and all of them have been in production at some point. Any big new feature is enabled by default only after it goes through unit tests, functional tests, experiments in different environments and different stages of production adoption. This development strategy provides fast delivery and adoption of new features. The above model may not fit if stability of interfaces is required. Examples of such development cases are: making prebuilt packeges of the framework for package managers or OS distros, release based development model in the company, prototyping. To satisfy the need in stability, the framework also provides releases - snapshots of the `develop` sources with @ref scripts/docs/en/userver/development/stability.md "API stability" guarantee. Releases do not evolve, all the new functionality and bugfixes go to develop branch of git to become a new release some day. Starting from userver 2.0 we do a new minor release monthly. We do our best to implement feature requests and review the pull requests. However, we prioritize our in-house feature requests and, alas, our resources are limited. Please, see @ref CONTRIBUTING.md before making a PR or posting code! To report an issue or provide a pull request use the github interface https://github.com/userver-framework/. There is a queue of simple tickets and a queue of more complex features . If you're planning to contribute soon or starting a work on a big feature, please write a comment about it into the issue. That way we could remove the issue from a queue and avoid contention on features. Bugfixes and new features are not ported to older releases. To get the functionality you have to update to a new release with a fix. @htmlonly <div class="bottom-nav"> @endhtmlonly @ref scripts/docs/en/userver/deployenv.md | @ref scripts/docs/en/userver/roadmapand_changelog.md @htmlonly </div> @endhtmlonly
Project: Meshery (Provisioning / Automation & Configuration)
File: helm.md

layout: default title: Helm permalink: installation/kubernetes/helm type: installation category: kubernetes redirect_from: installation/platforms/helm display-title: "false" language: en list: include abstract: Install Meshery on Kubernetes using Helm. Deploy Meshery in Kubernetes in-cluster. <div class="prereqs"><h4>Prerequisites</h4> <ol> <li><a href="https://helm.sh/docs/intro/install/" class="meshery-light">Helm</a> should be installed on your local machine.</li> <li>You should have access to the cluster/platform where you want to deploy Meshery.</li> <li>Ensure that the kubeconfig file has the correct current context/cluster configuration.</li> </ol> </div> {% capture code_content %}helm repo add meshery https://meshery.io/charts/ helm install meshery meshery/meshery --namespace meshery --create-namespace {% endcapture %} {% include code.html code=code_content %} Optionally, Meshery Server supports customizing the callback URL for your remote provider, like so: {% capture codecontent %}helm install meshery meshery/meshery --namespace meshery --set env.MESHERYSERVERCALLBACKURL=https://custom-host --create-namespace{% endcapture %} {% include code.html code=code_content %} Meshery's Helm chart supports a number of configuration options. Please refer to the and for more information. Optionally, you can verify the health of your Meshery deployment, using <a href='/reference/mesheryctl/system/check'>mesheryctl system check</a>. You're ready to use Meshery! Open your browser and navigate to the Meshery UI. {% include_cached installation/accessing-meshery-ui.md display-title="true" %} {% include related-discussions.html tag="meshery" %}
Project: ArangoDB (App Definition and Development / Database)
File: preamble.md

+++ title = "Define a custom code domain" weight = 10 +++ Firstly let's alias the experimental Outcome namespace into something less tedious to type, declare our custom status code type, and get started on defining the custom status code domain implementation. {{% snippet "experimentalstatuscode.cpp" "preamble" %}} Note that we inherit from `outcomee::posixcode::domain_type`, not from `outcomee::statuscode_domain`. We thus reuse most of the implementation of `outcomee::posixcode::domain_type` rather than implementing required functionality. If you would like to see a fuller treatment of defining a custom status code domain from scratch, see . [You may find looking at the API reference documentation for `statuscodedomain` useful in the next few pages ](https://ned14.github.io/status-code/docstatuscodedomain.html#standardese-systemerror2statuscodedomain).
Project: ClickHouse (App Definition and Development / Database)
File: truncate.md

slug: /en/sql-reference/statements/truncate sidebar_position: 52 sidebar_label: TRUNCATE ``` sql TRUNCATE TABLE [IF EXISTS] [db.]name [ON CLUSTER cluster] ``` Removes all data from a table. When the clause `IF EXISTS` is omitted, the query returns an error if the table does not exist. The `TRUNCATE` query is not supported for , , , and table engines. You can use the setting to set up waiting for actions to be executed on replicas. You can specify how long (in seconds) to wait for inactive replicas to execute `TRUNCATE` queries with the setting. :::note If the `altersync` is set to `2` and some replicas are not active for more than the time, specified by the `replicationwaitforinactivereplicatimeout` setting, then an exception `UNFINISHED` is thrown. ::: ``` sql TRUNCATE ALL TABLES FROM [IF EXISTS] db [ON CLUSTER cluster] ``` Removes all data from all tables in a database. ``` sql TRUNCATE DATABASE [IF EXISTS] db [ON CLUSTER cluster] ``` Removes all tables from a database but keeps the database itself. When the clause `IF EXISTS` is omitted, the query returns an error if the database does not exist.
Project: KICS (Provisioning / Security & Compliance)
File: ef0b316a-211e-42f1-888e-64efe172b755.md

title: CloudWatch Without Retention Period Specified hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ef0b316a-211e-42f1-888e-64efe172b755 Query name: CloudWatch Without Retention Period Specified Platform: Terraform Severity: <span style="color:#5bc0de">Info</span> Category: Observability URL: AWS CloudWatch Log groups should have retention days specified<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 18" resource "awscloudwatchlog_group" "positive1" { name = "Yada" tags = { Environment = "production" Application = "serviceA" } } resource "awscloudwatchlog_group" "positive2" { name = "Yada" tags = { Environment = "production" Application = "serviceA" } retentionindays = 0 } ``` ```tf title="Negative test num. 1 - tf file" resource "awscloudwatchlog_group" "negative1" { name = "Yada" tags = { Environment = "production" Application = "serviceA" } retentionindays = 1 } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: admin-console-operator.md

layout: integration title: Epam Delivery Platform (EDP) Admin Console subtitle: Collaborative and visual infrastructure as code for Epam Delivery Platform (EDP) Admin Console image: /assets/img/integrations/admin-console-operator/icons/color/admin-console-operator-color.svg permalink: extensibility/integrations/admin-console-operator docURL: https://docs.meshery.io/extensibility/integrations/admin-console-operator description: integrations-category: Provisioning integrations-subcategory: Automation & Configuration registrant: Artifact Hub components: name: admin-console colorIcon: assets/img/integrations/admin-console-operator/components/admin-console/icons/color/admin-console-color.svg whiteIcon: assets/img/integrations/admin-console-operator/components/admin-console/icons/white/admin-console-white.svg description: featureList: [ "Deployed and configured CI/CD toolset (Jenkins, Gerrit, Nexus, SonarQube)", "Kubernetes native approach (CRD, CR) to declare CI/CD pipelines", "Gerrit, GitLab or GitHub as a version control system for your code" ] 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: StarRocks (App Definition and Development / Database)
File: task_runs.md

displayed_sidebar: "English" `task_runs` provides information about the execution of asynchronous tasks. The following fields are provided in `task_runs`: | Field | Description | | - | | | QUERY_ID | ID of the query. | | TASK_NAME | Name of the task. | | CREATE_TIME | Time when the task was created. | | FINISH_TIME | Time when the task finished. | | STATE | State of the task. Valid values: `PENDING`, `RUNNING`, `FAILED`, and `SUCCESS`. | | DATABASE | Database where the task belongs. | | DEFINITION | SQL definition of the task. | | EXPIRE_TIME | Time when the task expires. | | ERROR_CODE | Error code of the task. | | ERROR_MESSAGE | Error message of the task. | | PROGRESS | The progress of the task. | | EXTRA_MESSAGE | Extra message for the task, for example, the partition information in an asynchronous materialized view creation task. |