cwielenb/CNCF-Dataset huggingface dataset:
Project: Meshery (Provisioning / Automation & Configuration)
File: harbor-operator.md

layout: integration title: Harbor Operator subtitle: Collaborative and visual infrastructure as code for Harbor Operator image: /assets/img/integrations/harbor-operator/icons/color/harbor-operator-color.svg permalink: extensibility/integrations/harbor-operator docURL: https://docs.meshery.io/extensibility/integrations/harbor-operator description: integrations-category: Provisioning integrations-subcategory: Container Registry registrant: Artifact Hub components: name: instance-chart-repository colorIcon: assets/img/integrations/harbor-operator/components/instance-chart-repository/icons/color/instance-chart-repository-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/instance-chart-repository/icons/white/instance-chart-repository-white.svg description: name: instance colorIcon: assets/img/integrations/harbor-operator/components/instance/icons/color/instance-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/instance/icons/white/instance-white.svg description: name: project colorIcon: assets/img/integrations/harbor-operator/components/project/icons/color/project-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/project/icons/white/project-white.svg description: name: registry colorIcon: assets/img/integrations/harbor-operator/components/registry/icons/color/registry-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/registry/icons/white/registry-white.svg description: name: replication colorIcon: assets/img/integrations/harbor-operator/components/replication/icons/color/replication-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/replication/icons/white/replication-white.svg description: name: user colorIcon: assets/img/integrations/harbor-operator/components/user/icons/color/user-color.svg whiteIcon: assets/img/integrations/harbor-operator/components/user/icons/white/user-white.svg description: featureList: [ "Content signing and validation", "Security and vulnerability analysis", "Replication across many registries, including Harbor" ] 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: YugabyteDB (App Definition and Development / Database)
File: disaster-recovery-switchover.md

title: Planned Switchover with disaster recovery headerTitle: Planned switchover linkTitle: Switchover description: Switchover using disaster recovery headContent: Switch application traffic to the DR replica menu: stable_yugabyte-platform: parent: disaster-recovery identifier: disaster-recovery-switchover weight: 40 type: docs Planned switchover is the process of switching write access from the DR primary to the DR replica without losing any data (zero RPO). Planned switchover is typically performed during a maintenance window. Switchover can be used by enterprises when performing regular business continuity or disaster recovery testing. Switchover can also used for failback purposes. That is, after a , you can use switchover to switch traffic back to the original DR primary after it is brought back online. First, confirm there is no excessive lag between the DR primary and replica. You can on the xCluster Disaster Recovery tab. If the DR config has any tables that don't have a replication status of Operational, switchover will be unsuccessful. In that case, you can do one of the following: Perform a full copy from the DR primary to the DR replica. . Verify that the list of tables in the DR primary's database(s) match the list of tables in the DR replica's database(s). Switchover will fail if there is a mismatch in this list. Use the following steps to perform a planned switchover: Ensure there is no significant lag between DR primary and replica, and that there are no critical alerts active on either universe. Stop the application traffic on the DR primary. Navigate to your DR primary universe and select xCluster Disaster Recovery. Click Actions and choose Switchover. Enter the name of the DR replica and click Initiate Switchover. The switchover process waits for all remaining changes on the current DR primary to be replicated to the DR replica. Resume the application traffic on the new DR primary.
Project: Scylla (App Definition and Development / Database)
File: cql-extensions-internal.md

Scylla extends the CQL language to provide a few extra features. This document lists those extensions. The `SCYLLATIMEUUIDLIST_INDEX` function allows using the raw (sstable) collection key for lists, which is a timeuuid, as "index" when performing a modification. The function is used to wrap the index part of a list assignment: UPDATE ... SET listcolumn[SCYLLATIMEUUIDLISTINDEX(:v1)] = :v2 ... It is only used by sstableloader. The `SCYLLACOUNTERSHARD_LIST` function allows setting a counter column value by its internal representation. The function is used to wrap the value part of a counter assignment: UPDATE ... SET countercolumn = SCYLLACOUNTERSHARDLIST(:v1) ... It is only used by sstableloader. The `SCYLLACLUSTERINGBOUND` function marks a query bound as being a CQL clustering boundary, not a value range bound as in normal CQL. This function can be used on the right-hand side of a `WHERE` statement multicolumn comparison, excluding the IN and LIKE operators. Its parameters are values corresponding to the clustering prefix specified on the left-hand side of that comparison. UPDATE ... WHERE (c1, c2) < SCYLLACLUSTERINGBOUND(:v1, :v2) AND (c1, c2) > SCYLLACLUSTERINGBOUND(:v3, :v4) ... It is only used by sstableloader.
Project: YDB (App Definition and Development / Database)
File: upgrade.md

{{ ydb-short-name }} is a distributed system that supports rolling restart without downtime or performance degradation. The basic scenario is updating the executable file and restarting each node one by one: Updating and restarting storage nodes. Updating and restarting dynamic nodes. The shutdown and startup process is described on the page. You must update {{ ydb-short-name }} nodes one by one and monitor the cluster status after each step in : make sure the `Storage` tab has no pools in the `Degraded` status (as shown in the example below). Otherwise, stop the update process. All minor versions within a major version are compatible for updates. Major versions are consecutively compatible. To update to the next major version, you must first update to the latest minor release of the current major version. For example: X.Y. X.Y.*: Update is possible, all minor versions within a single major version are compatible. X.Y.Z (the latest available version in X.Y.) X.Y+1.* : Update is possible, major versions are consistent. X.Y. X.Y+2.*: Update is impossible, major versions are inconsistent. X.Y. X.Y-2.*: Update is impossible, major versions are inconsistent. A list of available versions can be found on the . The YDB release policy is described in more details in the article of the YDB development documentation. {% note warning %} Also, in any case, you cannot roll back more than 2 major versions relative to the version that was deployed at least once. This is because such an old version may not know how to work with data on the disks that the newer version persisted. {% endnote %} v.22.2.5 -> v.22.2.47: Update is possible. v.22.2.47 -> v.22.3.21: Update is possible. v.22.2.40 -> v.22.3.21: Update is impossible, first upgrade to the latest minor version (v.22.2.47). v.22.2.47 -> v.22.4.5: Update is impossible, upgrade to the next major version first (v.22.3.). You can check the updated node versions on the `Nodes` page in Monitoring.
Project: OpenYurt (Provisioning / Automation & Configuration)
File: MAINTAINERS.md

This file lists the maintainers of the OpenYurt project which synced from file: https://github.com/openyurtio/community/blob/main/OWNERS.md#maintainers. The responsibilities of maintainers are listed in the file. | Name | GitHub ID | Affiliation | |--|--|-| | | | Microsoft | | | | Alibaba | | | | VMware | | | | Intel | | | | Independent | | | | Inspur | | | | Sangfor | | | | Tongji University | | | | Alibaba |
Project: YDB (App Definition and Development / Database)
File: failure_model.md

With SelfHeal enabled, this situation is considered normal. SelfHeal will move the VDisk over the time specified in the settings, then data replication will start on a different PDisk. If SelfHeal is disabled, you'll have to manually move the VDisk. Before moving it, make sure that only one VDisk in the storage group has failed. Then follow the . In this kind of failure, no data is lost, the system maintains operability, and read and write queries are executed successfully. Performance might degrade because of the load handover from the failed disks to the operable ones. If multiple VDisks have failed in the group, SelfHeal stops moving VDisks. If the maximum number of failed VDisks for the failure model has been reached, recover at least one VDisk before you start . You may also need to be more careful when . The availability and operability of the system might be lost. Make sure to revive at least one VDisk without losing the data stored on it.
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_cluster_vscale.md

title: kbcli cluster vscale Vertically scale the specified components in the cluster. ``` kbcli cluster vscale NAME [flags] ``` ``` kbcli cluster vscale mycluster --components=mysql --cpu=500m --memory=500Mi kbcli cluster vscale mycluster --components=mysql --class=general-2c4g ``` ``` --auto-approve Skip interactive approval before vertically scaling the cluster --class string Component class --components strings Component names to this operations --cpu string Request and limit size of component cpu --dry-run string[="unchanged"] Must be "client", or "server". If with client strategy, only print the object that would be sent, and no data is actually sent. If with server strategy, submit the server-side request, but no data is persistent. (default "none") -h, --help help for vscale --memory string Request and limit size of component memory --name string OpsRequest name. if not specified, it will be randomly generated -o, --output format Prints the output in the specified format. Allowed values: JSON and YAML (default yaml) --ttlSecondsAfterSucceed int Time to live after the OpsRequest succeed ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "$HOME/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use ``` - Cluster command.
Project: Meshery (Provisioning / Automation & Configuration)
File: opengitops.md

layout: integration title: OpenGitOps subtitle: Collaborative and visual infrastructure as code for OpenEBS image: /assets/img/integrations/opengitops/icons/color/opengitops-color.svg permalink: extensibility/integrations/opengitops docURL: https://docs.meshery.io/extensibility/integrations/opengitops description: integrations-category: App Definition and Development integrations-subcategory: Continuous Integration & Delivery 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: YDB (App Definition and Development / Database)
File: container_literal.md

Some containers support operator notation for their literal values: Tuple: `(value1, value2...)`; Structure: `<|name1: value1, name2: value2...|>`; List: `[value1, value2,...]`; Dictionary: `{key1: value1, key2: value2...}`; Set: `{key1, key2...}`. In every case, you can use an insignificant trailing comma. For a tuple with one element, this comma is required: ```(value1,)```. For field names in the structure literal, you can use an expression that can be calculated at evaluation time, for example, string literals or identifiers (including those enclosed in backticks). For nested lists, use , for nested dictionaries, use , for nested sets, use , for nested tuples, use , for nested structures, use . Examples ```yql $name = "computed " || "member name"; SELECT (1, 2, "3") AS `tuple`, <| `complex member name`: 2.3, b: 2, $name: "3", "inline " || "computed member name": false |> AS `struct`, [1, 2, 3] AS `list`, { "a": 1, "b": 2, "c": 3, } AS `dict`, {1, 2, 3} AS `set` ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_networks.md

+++ title = "googlecomputenetworks resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputenetworks" identifier = "inspec/resources/gcp/googlecomputenetworks.md googlecomputenetworks resource" parent = "inspec/resources/gcp" +++ A `googlecomputenetworks` is used to test a Google Network resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ``` describe googlecomputenetworks(project: 'chef-gcp-inspec') do its('network_names') { should include 'inspec-network' } end ``` describe googlecomputenetworks(project: 'chef-inspec-gcp') do its('count') { should be <= 100} end describe googlecomputenetworks(project: 'chef-inspec-gcp') do its('network_ids') { should include 12345678975432 } end describe googlecomputenetworks(project: 'chef-inspec-gcp') do its('network_names') { should include "network-name" } end Properties that can be accessed from the `googlecomputenetworks` resource: See the resource for more information. `descriptions` : an array of `googlecomputenetwork` description `gateway_ipv4s` : an array of `googlecomputenetwork` gateway_ipv4 `network_ids` : an array of `googlecomputenetwork` id `network_names` : an array of `googlecomputenetwork` name `subnetworks` : an array of `googlecomputenetwork` subnetworks `autocreatesubnetworks` : an array of `googlecomputenetwork` autocreatesubnetworks `creation_timestamps` : an array of `googlecomputenetwork` creation_timestamp `routing_configs` : an array of `googlecomputenetwork` routing_config This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: SPIRE (Provisioning / Key Management)
File: CODE-OF-CONDUCT.md

We follow the . Additionally, we commit to the following guidelines as detailed on the : Our goal is to foster an inclusive and diverse community of technology enthusiasts. Try to be your best self. Treat your fellow community members with kindness and empathy. We welcome disagreements when they are conducted respectfully and without personal attacks. We ask that you keep unstructured critique to a minimum. Disparaging remarks about the project are unnecessary and a drain on community morale. Feedback should be constructive and relevant. Having passionately held opinions on what should improve is encouraged! We hope you will use that enthusiasm to roll up your sleeves and get involved by submitting pull requests. We have additional guidelines on . We don't tolerate insults, spamming, trolling, flaming, baiting, or harassment. We don't tolerate sexual language, imagery, or unwanted advances. Private harassment is also unacceptable. We do our best to avoid : small actions that make others feel uncomfortable. If you witness a subtle-ism, you may respectfully point it out to the person publicly or privately, or you may ask a moderator to say something. Accidentally saying something biased is common, expected, and readily forgiven. It is not in and of itself a bannable offense. If you feel any of SPIFFE's Slack channels require moderation, please e-mail . The TSC will issue a warning to users who don't follow this code of conduct. A second offense results in a temporary ban. A third offense warrants a permanent ban. It is at the moderator's discretion to un-ban offending users, or to immediately ban a toxic user without warning.
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-system-channel-view.md

layout: default title: mesheryctl-system-channel-view permalink: reference/mesheryctl/system/channel/view redirect_from: reference/mesheryctl/system/channel/view/ type: reference display-title: "false" language: en command: system subcommand: channel view release channel and version View release channel and version of context in focus <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system channel view [flags] </div> </pre> View current release channel <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system channel view </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -a, --all Show release channel for all contexts -h, --help help for view </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: KubeMQ (App Definition and Development / Streaming & Messaging)
File: kubemq_commands_attach.md

Command attach to 'commands' channels command Command attach command allows to display 'commands' channel content for debugging proposes ``` kubemq commands attach [flags] ``` ``` kubemq commands attach * kubemq commands attach some-commands kubemq commands attach some-commands1 some-commands2 kubemq commands attach some-commands -i some* kubemq commands attach some-commands -e not-some* ``` ``` -e, --exclude stringArray Set (regex) strings to exclude -h, --help help for attach -i, --include stringArray Set (regex) strings to include ``` - Execute Kubemq 'commands'
Project: KICS (Provisioning / Security & Compliance)
File: 1d972c56-8ec2-48c1-a578-887adb09c57a.md

title: Lambda Permission Principal Is Wildcard hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1d972c56-8ec2-48c1-a578-887adb09c57a Query name: Lambda Permission Principal Is Wildcard Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Lambda Permission Principal should not contain a wildcard.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="8" name: Lambda S3 event notification community.aws.lambda_policy: state: present function_name: functionName alias: Dev statement_id: lambda-s3-myBucket-create-data-log action: lambda:AddPermission principal: "*" source_arn: arn:aws:s3:eu-central-1:123456789012:bucketName source_account: 123456789012 ``` ```yaml title="Negative test num. 1 - yaml file" name: Lambda S3 event notification negative community.aws.lambda_policy: state: present function_name: functionName alias: Dev statement_id: lambda-s3-myBucket-create-data-log action: lambda:AddPermission principal: s3.amazonaws.com source_arn: arn:aws:s3:eu-central-1:123456789012:bucketName source_account: 123456789012 ```
Project: kpt (Provisioning / Automation & Configuration)
File: trivial-repository.md

For easier orientation, an overview of the contents of the `trivial-repository.tar`. The repository in `trivial-repository.tar` contains a single, empty, commit, in its `main` branch. The commit graph is: ``` 0f890879a10df9aaa9b263035eea955335451804 (HEAD -> main) Empty Commit ```
Project: StarRocks (App Definition and Development / Database)
File: ADD_SQLBLACKLIST.md

displayed_sidebar: "English" Adds a regular expression to the SQL blacklist to forbid certain SQL patterns. When the SQL Blacklist feature is enabled, StarRocks compares all SQL statements to be executed against the SQL regular expressions in the blacklist. StarRocks does not execute SQLs that match any regular expression in the blacklist and returns an error. This prevents certain SQLs from triggering cluster crashes or unexpected behavior. For more about SQL Blacklist, see . :::tip This operation requires the SYSTEM-level BLACKLIST privilege. You can follow the instructions in to grant this privilege. ::: ```SQL ADD SQLBLACKLIST "<sqlregexpr>" ``` `sqlregexpr`: the regular expression that is used to specify a certain SQL pattern. To distinguish the special characters in the SQL statement and those in the regular expression, you need to use the escape character `\` as a prefix for the special characters in the SQL statement, such as `(`, `)`, and `+`. Whereas `(` and `)` have been often used in SQL statements, StarRocks can identify `(` and `)` in SQL statements directly. You do not need to use the escape character for `(` and `)`. Example 1: Add `count(\*)` to the SQL blacklist. ```Plain mysql> ADD SQLBLACKLIST "select count(\\*) from .+"; ``` Example 2: Add `count(distinct )` to the SQL blacklist. ```Plain mysql> ADD SQLBLACKLIST "select count(distinct .+) from .+"; ``` Example 3: Add `order by limit x, y, 1 <= x <=7, 5 <=y <=7` to the SQL blacklist. ```Plain mysql> ADD SQLBLACKLIST "select idint from testalltypeselect1 order by id_int limit [1-7], [5-7]"; ``` Example 4: Add a complex SQL regular expression to the SQL blacklist. This example is to demonstrate how to use escape characters for `*` and `-` in SQL statements. ```Plain mysql> ADD SQLBLACKLIST "select idint \\* 4, idtinyint, id_varchar from testalltype_nullable except select idint, idtinyint, id_varchar from test_basic except select (idint \\* 9 \\- 8) \\/ 2, idtinyint, id_varchar from testalltype_nullable2 except select idint, idtinyint, id_varchar from testbasicnullable"; ```