cwielenb/CNCF-Dataset huggingface dataset:
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: shared-resource.md

Sometimes, you may want different applications to share the same resource. For example, you might have various applications that needs the same namespace to exist. In this case, you can use the `shared-resource` policy to declare which resources should be shared. ```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app1 spec: components: name: ns1 type: k8s-objects properties: objects: apiVersion: v1 kind: Namespace metadata: name: example name: cm1 type: k8s-objects properties: objects: apiVersion: v1 kind: ConfigMap metadata: name: cm1 namespace: example data: key: value1 policies: name: shared-resource type: shared-resource properties: rules: selector: resourceTypes: ["Namespace"] ``` ```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app2 spec: components: name: ns2 type: k8s-objects properties: objects: apiVersion: v1 kind: Namespace metadata: name: example name: cm2 type: k8s-objects properties: objects: apiVersion: v1 kind: ConfigMap metadata: name: cm2 namespace: example data: key: value2 policies: name: shared-resource type: shared-resource properties: rules: selector: resourceTypes: ["Namespace"] ``` The above two applications will dispatch the same namespace "example". They will create two different ConfigMap inside namespace "example" respectively. Both application use the `shared-resource` policy and declared the namespace resource as shared. In this way, there will be no conflict for creating the same namespace. If the `shared-resource` policy is not used, the second application will report error after it finds that the namespace "example" is managed by the first application. The namespace will only be recycled when both applications are removed. One of the problem for sharing resource is that what will happen if different application holds different configuration for the shared resource. In the `shared-resource` policy, all sharers will be recorded by time order. The first sharer will be able to write the resource while other sharers can only read it. After the first sharer is deleted, it will give the control of the resource to the next sharer. If no sharer is handling it, the resource will be finally removed.
Project: ShardingSphere (App Definition and Development / Database)
File: unregister-storage-unit.en.md

+++ title = "UNREGISTER STORAGE UNIT" weight = 3 +++ The `UNREGISTER STORAGE UNIT` syntax is used to unregister storage unit from the current database {{< tabs >}} {{% tab name="Grammar" %}} ```sql UnregisterStorageUnit ::= 'UNREGISTER' 'STORAGE' 'UNIT' ifExists? storageUnitName (',' storageUnitName)* (ignoreSingleTables | ignoreBroadcastTables | ignoreSingleAndBroadcastTables)? ignoreSingleTables ::= 'IGNORE' 'SINGLE' 'TABLES' ignoreBroadcastTables ::= 'IGNORE' 'BROADCAST' 'TABLES' ignoreSingleAndBroadcastTables ::= 'IGNORE' ('SINGLE' ',' 'BROADCAST' | 'BROADCAST' ',' 'SINGLE') 'TABLES' ifExists ::= 'IF' 'EXISTS' storageUnitName ::= identifier ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} `UNREGISTER STORAGE UNIT` will only unregister storage unit in Proxy, the real data source corresponding to the storage unit will not be unregistered; Unable to unregister storage unit already used by rules. `Storage unit are still in used.` will be prompted when removing storage units used by rules; The storage unit need to be removed only contains `SINGLE RULE`, `BROADCAST RULE` and when the user confirms that this restriction can be ignored, the `IGNORE SINGLE TABLES`, `IGNORE BROADCAST TABLES`, `IGNORE SINGLE, BROADCAST TABLES` keyword can be added to remove the storage unit; `ifExists` clause is used for avoid `Storage unit not exists` error. Drop a storage unit ```sql UNREGISTER STORAGE UNIT ds_0; ``` Drop multiple storage units ```sql UNREGISTER STORAGE UNIT ds0, ds1; ``` Ignore single rule remove storage unit ```sql UNREGISTER STORAGE UNIT ds_0 IGNORE SINGLE TABLES; ``` ```sql UNREGISTER STORAGE UNIT ds_0 IGNORE BROADCAST TABLES; ``` ```sql UNREGISTER STORAGE UNIT ds_0 IGNORE SINGLE, BROADCAST TABLES; ``` Drop the storage unit with `ifExists` clause ```sql UNREGISTER STORAGE UNIT IF EXISTS ds_0; ``` `DROP`, `STORAGE`, `UNIT`, `IF`, `EXISTS`, `IGNORE`, `SINGLE`, `BROADCAST`, `TABLES`
Project: StarRocks (App Definition and Development / Database)
File: TRUNCATE_TABLE.md

displayed_sidebar: "English" This statement is used to truncate the specified table and partition data. Syntax: ```sql TRUNCATE TABLE [db.]tbl[ PARTITION(p1, p2, ...)] ``` Note: This statement is used to truncate data while retaining tables or partitions. Unlike DELETE, this statement can only empty the specified tables or partitions as a whole, and filtering conditions cannot be added. Unlike DELETE, using this method to clear data will not affect query performance. This statement directly deletes data. The deleted data cannot be recovered. The table on which you perform this operation must be in the NORMAL state. For example, you cannot perform TRUNCATE TABLE on a table with SCHEMA CHANGE going on. Truncate table `tbl` under `example_db`. ```sql TRUNCATE TABLE example_db.tbl; ``` Truncate partitions `p1` and `p2` in table `tbl`. ```sql TRUNCATE TABLE tbl PARTITION(p1, p2); ```
Project: SPIFFE (Provisioning / Key Management)
File: sig-creation-procedure.md

Purpose the new SIG publicly include a brief mission statement, by emailing spiffe-dev@googlegroups.com and spiffe-users@googlegroups.com, then wait a couple of days for feedback Ask a repo maintainer to create a github label, if one doesn't already exist: sig/foo Request a new channel (#sig-foo). New users can join at [slack.spiffe.io] Slack activity is archived at . To start archiving a new channel invite slackarchive bot to the channel via '/invite @slackarchive' Organization video meetings as needed. No need to wait for the [Weekly Community Video Conference](community/README.md) to discuss. Please report summary of SIG activities there. Add the meeting to the community meeting calendar by inviting {TODO}@group.calendar.google.com. Announce new SIG on spiffe-dev@googlegroups.com Submit a PR to add a row for the SIG to the table in the file, to create a spiffe/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new spiffe/community/SIG-foo directory. With a purpose to distribute the channels of notification and discussion of the various topics, every SIG has to use multiple accounts to GitHub mentioning and notifications. Below the procedure is explained step-by-step Create Google Groups at , following the procedure: Each SIG should have one discussion groups Create groups using the name conventions below Groups should be created as e-mail lists with at least three owners To add the owners, visit the Group Settings (drop-down menu on the right side), select Direct Add Members on the left side and add (2 default owners TODO) Set "View topics", "Post" "Join the Groups" permissions to be "Public" For now we will use one group per SIG. Later on the SIGs can be sub divided into more granular groupings. Name convention example: spiffe-sig-cert-format (the discussion group) Create the GitHub users at , using the name convention below. As an e-mail address, please, use the Google Group e-mail address of the respective Google Group, created before. After creating the GitHub users, please add these users to the Spiffe organization. Name convention: spiffe-mirror-foo Example: spiffe-mirror-cert-format NOTE: Github's notification autocompletion finds the users before the corresponding teams. This is the reason we recommend naming the users `spiffe-mirror-foo-` instead of `spiffe-sig-foo-`. Create the GitHub teams using the name conventions below. Please, add the GitHub users (created before) to the GitHub teams respectively. For now we will create one GitHub team per SIG. Later on we will subdivide SIG teams into more granular groupings. sig-foo-misc Example sig-cert-format sig-cert-format
Project: StarRocks (App Definition and Development / Database)
File: to_tera_date.md

displayed_sidebar: "English" Parses a date or time string according to the specified format and converts the string to a DATE value. ```Haskell DATE toteradate(VARCHAR str, VARCHAR format) ``` `str`: the time expression to convert. It must be of the VARCHAR type. `format`: the date format specifier for `str`. It is used to parse and convert the input string. `format` must match `string`. Otherwise, NULL is returned. If `format` is invalid, an error is returned. The following table describes the format elements. | Element | Description | | | - | | [ \r \n \t - / , . ;] | Punctuation characters that are ignored in conversion | | dd | Day of month (1 - 31) | | hh | Hour of day (1 - 12) | | hh24 | Hour of day (0 - 23) | | mi | Minute (0 - 59) | | mm | Month (01 - 12) | | ss | Second (0 - 59) | | yyyy | 4-digit year. | | yy | 2-digit year. | | am | Meridian indicator. | | pm | Meridian indicator. | ```SQL select toteradate("1988/04/08","yyyy/mm/dd"); ++ | toteradate('1988/04/08', 'yyyy/mm/dd') | ++ | 1988-04-08 | ++ select toteradate("04-08-1988","mm-dd-yyyy"); ++ | toteradate('04-08-1988', 'mm-dd-yyyy') | ++ | 1988-04-08 | ++ select toteradate(";198804:08",";yyyymm:dd"); ++ | toteradate(';198804:08', ';yyyymm:dd') | ++ | 1988-04-08 | ++ select toteradate("2020-02-02 00:00:00", "yyyy-mm-dd"); ++ | toteradate('2020-02-02 00:00:00', 'yyyy-mm-dd') | ++ | 2020-02-02 | ++ -- The input is year and does not contain the month or date part. The first day in that year is returned. select toteradate("1988","yyyy"); ++ | toteradate('1988', 'yyyy') | ++ | 1988-01-01 | ++ ``` TOTERADATE
Project: StarRocks (App Definition and Development / Database)
File: previous_day.md

displayed_sidebar: "English" Returns the date of the first specified day of week (DOW) that occurs before the input date (DATE or DATETIME). For example, `previous_day('2023-04-06', 'Monday')` returns the date of the previous Monday that occurred before '2023-04-06'. This function is supported from v3.1. It is the opposite of . ```SQL DATE previousday(DATETIME|DATE dateexpr, VARCHAR dow) ``` `date_expr`: the input date. It must be a valid DATE or DATETIME expression. `dow`: the day of week. Valid values include a number of abbreviations which are case-sensitive: | DOWFULL | DOW2 | DOW_3 | | | -- |:--:| | Sunday | Su | Sun | | Monday | Mo | Mon | | Tuesday | Tu | Tue | | Wednesday | We | Wed | | Thursday | Th | Thu | | Friday | Fr | Fri | | Saturday | Sa | Sat | Returns a DATE value. Any invalid `dow` will cause an error. `dow` is case-sensitive. NULL is returned if an invalid date or a NULL argument is passed in. ```Plain -- Return the date of the previous Monday that occurred before 2023-04-06. 2023-04-06 is Thursday and the date of the previous Monday is 2023-04-03. MySQL > select previous_day('2023-04-06', 'Monday'); +--+ | previous_day('2023-04-06', 'Monday') | +--+ | 2023-04-03 | +--+ MySQL > select previous_day('2023-04-06', 'Tue'); +--+ | previous_day('2023-04-06', 'Tue') | +--+ | 2023-04-04 | +--+ MySQL > select previous_day('2023-04-06 20:13:14', 'Fr'); +-+ | previous_day('2023-04-06 20:13:14', 'Fr') | +-+ | 2023-03-31 | +-+ ``` PREVIOUS_DAY, PREVIOUS, previousday
Project: YDB (App Definition and Development / Database)
File: darwin_arm64.md

| Version | Release date | Download | Changelog | : | : | : | : | v.2.8.0 | 12/01/2024 | | | | v.2.7.0 | 23/10/2023 | | | | v.2.6.0 | 07/09/2023 | | | | v.2.5.0 | 20/06/2023 | | | | v.2.4.0 | 24/05/2023 | | | | v.2.3.0 | 01/05/2023 | | | | v.2.2.0 | 03/03/2023 | | | | v.2.1.1 | 30/12/2022 | | | | v.2.1.0 | 18/11/2022 | | | | v.2.0.0 | 20/09/2022 | | | | v.1.9.2 | 30/06/2022 | | | v.1.9.1 | 25/06/2022 | | | | v.1.9.0 | 22/06/2022 | | | v.1.8.0 | 19/04/2022 | | | v.1.7.0 | 01/03/2022 | | | v.1.6.0 | 24/12/2021 | |
Project: KICS (Provisioning / Security & Compliance)
File: 124b173b-e06d-48a6-8acd-f889443d97a4.md

title: BOM - AWS Cassandra hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 124b173b-e06d-48a6-8acd-f889443d97a4 Query name: BOM - AWS Cassandra Platform: CloudFormation Severity: <span style="color:#CCCCCC">Trace</span> Category: Bill Of Materials URL: A list of Cassandra resources found. Amazon Cassandra is an open-source NoSQL database designed to store data for applications that require fast read and write performance<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="3" AWSTemplateFormatVersion: 2010-09-09 Resources: myNewTable1: Type: 'AWS::Cassandra::Table' Properties: KeyspaceName: my_keyspace TableName: my_table PartitionKeyColumns: ColumnName: Message ColumnType: ASCII ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="3" AWSTemplateFormatVersion: '2010-09-09' Resources: myNewTable2: Type: AWS::Cassandra::Table Properties: KeyspaceName: my_keyspace TableName: my_table EncryptionSpecification: EncryptionType: CUSTOMERMANAGEDKMS_KEY KmsKeyIdentifier: arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111 PointInTimeRecoveryEnabled: true ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: '2010-09-09' Resources: myDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true ```
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-system-channel-set.md

layout: default title: mesheryctl-system-channel-set permalink: reference/mesheryctl/system/channel/set redirect_from: reference/mesheryctl/system/channel/set/ type: reference display-title: "false" language: en command: system subcommand: channel set release channel and version Set release channel and version of context in focus <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system channel set [stable|stable-version|edge|edge-version] [flags] </div> </pre> Subscribe to release channel or version <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system channel set [stable|stable-version|edge|edge-version] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for set </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: kiosk (Provisioning / Automation & Configuration)
File: bash_completions.md

Please refer to for details. For backward compatibility, Cobra still supports its legacy dynamic completion solution (described below). Unlike the `ValidArgsFunction` solution, the legacy solution will only work for Bash shell-completion and not for other shells. This legacy solution can be used along-side `ValidArgsFunction` and `RegisterFlagCompletionFunc()`, as long as both solutions are not used for the same command. This provides a path to gradually migrate from the legacy solution to the new solution. The legacy solution allows you to inject bash functions into the bash completion script. Those bash functions are responsible for providing the completion choices for your own completions. Some code that works in kubernetes: ```bash const ( bashcompletionfunc = `kubectlparseget() { local kubectl_output out if kubectl_output=$(kubectl get --no-headers "$1" 2>/dev/null); then out=($(echo "${kubectl_output}" | awk '{print $1}')) COMPREPLY=( $( compgen -W "${out[*]}" -- "$cur" ) ) fi } kubectlgetresource() { if [[ ${#nouns[@]} -eq 0 ]]; then return 1 fi kubectlparseget ${nouns[${#nouns[@]} -1]} if [[ $? -eq 0 ]]; then return 0 fi } kubectlcustomfunc() { case ${last_command} in kubectlget | kubectldescribe | kubectldelete | kubectlstop) kubectlgetresource return ;; *) ;; esac } `) ``` And then I set that in my command definition: ```go cmds := &cobra.Command{ Use: "kubectl", Short: "kubectl controls the Kubernetes cluster manager", Long: `kubectl controls the Kubernetes cluster manager. Find more information at https://github.com/GoogleCloudPlatform/kubernetes.`, Run: runHelp, BashCompletionFunction: bashcompletionfunc, } ``` The `BashCompletionFunction` option is really only valid/useful on the root command. Doing the above will cause `kubectl_custom_func()` (`<command-use>customfunc()`) to be called when the built in processor was unable to find a solution. In the case of kubernetes a valid command might look something like `kubectl get pod ` the `kubectl_customc_func()` will run because the cobra.Command only understood "kubectl" and "get." `kubectlcustomfunc()` will see that the cobra.Command is "kubectlget" and will thus call another helper `kubectlgetresource()`. `kubectlgetresource` will look at the 'nouns' collected. In our example the only noun will be `pod`. So it will call `kubectlparseget pod`. `kubectlparse_get` will actually call out to kubernetes and get any pods. It will then set `COMPREPLY` to valid pods! Similarly, for flags: ```go annotation := make(mapstring) annotation[cobra.BashCompCustom] = []string{"kubectlgetnamespaces"} flag := &pflag.Flag{ Name: "namespace", Usage: usage, Annotations: annotation, } cmd.Flags().AddFlag(flag) ``` In addition add the `kubectlgetnamespaces` implementation in the `BashCompletionFunction` value, e.g.: ```bash kubectlgetnamespaces() { local template template="{{ range .items }}{{ .metadata.name }} {{ end }}" local kubectl_out if kubectl_out=$(kubectl get -o template --template="${template}" namespace 2>/dev/null); then COMPREPLY=( $( compgen -W "${kubectl_out}[*]" -- "$cur" ) ) fi } ```
Project: Keycloak (Provisioning / Security & Compliance)
File: README.md

You need to create a client in Keycloak. The configuration options when creating the client should be: Client ID: You choose Access Type: confidential Root URL: Root URL for where you're hosting the application (for example http://localhost:8080) Valie Redirect URIs: /app-profile-jee/ Base URL: /app-profile-jee/ Admin URL: /app-profile-jee/ Then, build the WAR with Maven and install as per the Adapter configuration for your server as described in the Keycloak documentation.
Project: ShardingSphere (App Definition and Development / Database)
File: alter-default-shadow-algorithm.en.md

+++ title = "ALTER DEFAULT SHADOW ALGORITHM" weight = 5 +++ The `ALTER DEFAULT SHADOW ALGORITHM` syntax is used to alter a default shadow algorithm. {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterDefaultShadowAlgorithm ::= 'ALTER' 'DEFAULT' 'SHADOW' 'ALGORITHM' shadowAlgorithm shadowAlgorithm ::= 'TYPE' '(' 'NAME' '=' algorithmType ',' propertiesDefiinition ')' algorithmType ::= string propertiesDefinition ::= 'PROPERTIES' '(' key '=' value (',' key '=' value)* ')' key ::= string value ::= literal ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} `algorithmType` currently supports `VALUEMATCH`, `REGEXMATCH` and `SQL_HINT`. Alter default shadow algorithm ```sql ALTER DEFAULT SHADOW ALGORITHM TYPE(NAME="SQL_HINT"); ``` `ALTER`, `DEFAULT`, `SHADOW`, `ALGORITHM`, `TYPE`, `NAME`, `PROPERTIES`
Project: Vault (Provisioning / Key Management)
File: tests.md

Our test are constantly evolving, but here's a general overview of how we set up and organize tests. Acceptance tests should test the overall workflows and navigation within Vault. When possible, they should use the real API instead of mocked so that breaking changes from the backend can be caught. Reasons you may opt to use a mocked backend instead of the real one: Using the real backend would cause instability in concurrently-running tests (eg. seal/unseal flow) There isn't a way to set up a 3rd party dependency that the backend needs to run correctly (Database Secrets Engine, Sync Secrets) Shared helpers such as selectors, common interactions, WebREPL commands, and API response stubs live in this folder. When selectors are only used for a single test, they should be defined on the same file where they are used for the test. Once the selectors are being used for multiple tests, they should be moved to this folder so they can be defined in a single place and shared to wherever they are needed. Often we will need a set of selectors for "workflow" tests, or acceptance tests that navigate through an area of the app. For these, the helpers should be organized as such: `/helpers/<area>/<area>-selectors.ts` - exports selector consts (never default) for each page -- eg. for PKI we would have PKIOVERVIEW, PKIROLE, etc. `/helpers/<area>/<area>-helpers.js` - exports methods and consts which are otherwise helpful in the tests -- eg. example API responses, common interactions (eg. writeVersionedSecret for KV v2) Whenever possible we should try to use the general selectors exported from `/helpers/general-selectors.ts`. Integration tests are most often used to test specific components out of context from the rest of the app. Be sure to mock anything that the component needs to work correctly -- for example, if the component has a certain behavior in enterprise than community edition, in your tests for each scenario it should not assume that the underlying Vault binary is in one state or the other, and mock the enterprise/community state in all the scenarios. The exports in `helpers/stubs.js` might be helpful for these tests, particularly when the component uses a model which fetches capabilities. [DEPRECATED] This file should be removed in favor of selectors within the "helpers" folder. We are moving away from ember-page-object selectors toward simple strings Unit tests are most often used to test utils, adapters, serializers, routes, and services functionality.
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: ShardingSphere (App Definition and Development / Database)
File: Newfeature.en.md

+++ title = "New feature of Apache ShardingSphere 5.x" weight = 7 chapter = true +++ The first version of Apache ShardingSphere 5.x will be released soon. In version 5.x, Apache ShardingSphere has made significant innovations from architecture design to product scope. Apache ShardingSphere 5.x follow pluggable architecture design concept to build a flexible, embeddable and extensible project. Apache ShardingSphere 5. X no longer takes data sharding as kernel, but turns to building distributed database ecosystem. In the new version, core functions such as data sharding, distributed transaction and database governance are completely separated from the kernel and become a part of its pluggable component. Through SPI, the ecosystem is fully opened, and the functions of data migration, elastic scheduling, data encryption, shadow table are fully integrated into the product ecology. This presentation will comprehensively introduce the new features of Apache ShardingSphere 5.x. {{< bilibili BV1Qa4y1s7WK >}}