cwielenb/CNCF-Dataset huggingface dataset:
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: Easysearch.md

Spark<br/> Flink<br/> SeaTunnel Zeta<br/> A sink plugin which use send data to `INFINI Easysearch`. Depenndency :::tip Engine Supported Supported all versions released by . ::: | Easysearch Data Type | SeaTunnel Data Type | |--|-| | STRING<br/>KEYWORD<br/>TEXT | STRING | | BOOLEAN | BOOLEAN | | BYTE | BYTE | | SHORT | SHORT | | INTEGER | INT | | LONG | LONG | | FLOAT<br/>HALF_FLOAT | FLOAT | | DOUBLE | DOUBLE | | Date | LOCALDATETIME_TYPE | | name | type | required | default value | |-||-|| | hosts | array | yes | - | | index | string | yes | - | | primary_keys | list | no | | | keydelimiter | string | no | `` | | username | string | no | | | password | string | no | | | maxretrycount | int | no | 3 | | maxbatchsize | int | no | 10 | | tlsverifycertificate | boolean | no | true | | tlsverifyhostnames | boolean | no | true | | tlskeystorepath | string | no | - | | tlskeystorepassword | string | no | - | | tlstruststorepath | string | no | - | | tlstruststorepassword | string | no | - | | common-options | | no | - | `INFINI Easysearch` cluster http address, the format is `host:port` , allowing multiple hosts to be specified. Such as `["host1:9200", "host2:9200"]`. `INFINI Easysearch` `index` name.Index support contains variables of field name,such as `seatunnel_${age}`,and the field must appear at seatunnel row. If not, we will treat it as a normal index. Primary key fields used to generate the document `_id`, this is cdc required options. Delimiter for composite keys ("" by default), e.g., "$" would result in document `id` "KEY1$KEY2$KEY3". security username security password one bulk request max try size batch bulk doc max size Enable certificates validation for HTTPS endpoints Enable hostname validation for HTTPS endpoints The path to the PEM or JKS key store. This file must be readable by the operating system user running SeaTunnel. The key password for the key store specified The path to PEM or JKS trust store. This file must be readable by the operating system user running SeaTunnel. The key password for the trust store specified Sink plugin common parameters, please refer to for details Simple ```bash sink { Easysearch { hosts = ["localhost:9200"] index = "seatunnel-${age}" } } ``` CDC(Change data capture) event ```bash sink { Easysearch { hosts = ["localhost:9200"] index = "seatunnel-${age}" primary_keys = ["key1", "key2", ...] } } ``` SSL (Disable certificates validation) ```hocon sink { Easysearch { hosts = ["https://localhost:9200"] username = "admin" password = "admin" tlsverifycertificate = false } } ``` SSL (Disable hostname validation) ```hocon sink { Easysearch { hosts = ["https://localhost:9200"] username = "admin" password = "admin" tlsverifyhostname = false } } ``` SSL (Enable certificates validation) ```hocon sink { Easysearch { hosts = ["https://localhost:9200"] username = "admin" password = "admin" tlskeystorepath = "${your Easysearch home}/config/certs/http.p12" tlskeystorepassword = "${your password}" } } ``` Add Easysearch Sink Connector Support http/https protocol Support CDC write DELETE/UPDATE/INSERT events
Project: YDB (App Definition and Development / Database)
File: linux.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: Backstage (App Definition and Development / Application Definition & Image Build)
File: api-report.md

Do not edit this file. It is a report generated by . ```ts import { BackendFeature } from '@backstage/backend-plugin-api'; import { OAuthAuthenticator } from '@backstage/plugin-auth-node'; import { OAuthAuthenticatorResult } from '@backstage/plugin-auth-node'; import { PassportOAuthAuthenticatorHelper } from '@backstage/plugin-auth-node'; import { PassportProfile } from '@backstage/plugin-auth-node'; import { SignInResolverFactory } from '@backstage/plugin-auth-node'; // @public (undocumented) const authModuleGitlabProvider: () => BackendFeature; export default authModuleGitlabProvider; // @public (undocumented) export const gitlabAuthenticator: OAuthAuthenticator< PassportOAuthAuthenticatorHelper, PassportProfile ; // @public export namespace gitlabSignInResolvers { const usernameMatchingUserEntityName: SignInResolverFactory< OAuthAuthenticatorResult<PassportProfile>, unknown >; } ```
Project: Apicurio Registry (App Definition and Development / Streaming & Messaging)
File: README.md

System tests for Apicurio Registry and Apicurio Registry operators. Environment variables needed for run of system tests. Other environment variables are optional and have default values. See for list of supported environment variables and their default values. |Environment variable|Purpose| ||| |`CATALOG_IMAGE`|Path to an index image for an Operator catalog (if you want to use it)| |`CONVERTERS_SHA512SUM`|SHA-512 sum of Apicurio converters used in KafkaConnect| |`CONVERTERS_URL`|Path to Apicurio converters used in KafkaConnect| You will probably hit issues with Apicurio Registry API model due to fixes that were introduced in the last weeks. You need to build API model locally and add it into project Libraries:
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_grant_role.md

title: GRANT ROLE statement [YCQL] headerTitle: GRANT ROLE linkTitle: GRANT ROLE description: Use the GRANT ROLE statement to grant a role's permissions and SUPERUSER status to another role. menu: preview: parent: api-cassandra weight: 1282 aliases: /preview/api/cassandra/ddlgrantrole /preview/api/ycql/ddlgrantrole type: docs Use the `GRANT ROLE` statement to grant a role's permissions and SUPERUSER status to another role. More than one role can be granted to another role, and the receiving role will possess the union of all the permissions from the roles granted to it (either directly of indirectly through inheritance) plus the SUPERUSER status if any of the roles granted to it has it. For example, if A is granted to B, and B is granted to C, C will be granted all the permissions from A and B, and if either A or B is a SUPERUSER, then C will also be a SUPERUSER. Granted roles form an acyclic graph, in other words, a role cannot be granted to any of the roles granted to it either directly or indirectly. For example, if A is granted to B, and B granted to C, C cannot be granted to neither A, B, nor C. This statement is enabled by setting the YB-TServer flag to `true`. <svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="305" height="35" viewbox="0 0 305 35"><path class="connector" d="M0 22h5m61 0h10m84 0h10m36 0h10m84 0h5"/><rect class="literal" x="5" y="5" width="61" height="25" rx="7"/><text class="text" x="15" y="22">GRANT</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="76" y="5" width="84" height="25"/><text class="text" x="86" y="22">rolename</text></a><rect class="literal" x="170" y="5" width="36" height="25" rx="7"/><text class="text" x="180" y="22">TO</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="216" y="5" width="84" height="25"/><text class="text" x="226" y="22">rolename</text></a></svg> ```ebnf grantrole ::= GRANT ROLE rolename TO role_name ``` Where `role_name` is a text identifier. Both roles must exist or an error will be raised. Permission `AUTHORIZE` on `ALL ROLES` or on the roles being used in the statement is necessary. Otherwise, an unauthorized error will be returned. If a role is granted to any role granted to it (either directly or indirectly), an error will be raised. ```sql ycqlsh:example> GRANT ROLE eng to robert; ```
Project: Dgraph (App Definition and Development / Database)
File: README.md

To update the protocol buffer definitions, run this from one directory above: ``` protoc -I worker worker/payload.proto --gofast_out=plugins=grpc:worker ``` ike: myAttribute @index("hnsw-euclidian","maxNeighbors":"5","maxLevels":"5","exponent":"6") Roughly, this should be read as: I want to specify an HNSW-type vector index using euclidian distance as a metric with maxNeighbors, maxLevels, and exponent being declared as written, and with all other parameters taking on default values. (In the case of specifying an exponent, this should affect the defaults for the other options, but that is something that can be decided by the factory for the hnsw index)! But this leads to some natural questions: How do I know what option types are allowed? And how do I interpret their types? For example, how do I know that I should interpret "5" as an integer rather than a string? The solution will be to allow each factory to specify a set of "allowed option types". Hence, we get the AllowedOptions class, which specifies a set of named options and corresponding parsers for the given name. Now, if we want to populate an Options instance based on the content of myAttribute @index(hnsw(metric:"euclidian",exponent:"6")), we collect the key-value pairs: "metric":"euclidian" "exponent":"6" And we can now invoke: allowedOpts := hnswFactory.AllowedOpts() myAttributeIndexOpts := NewOptions() val, err := allowedOpts.GetParsedOption("exponent", "6") if err != nil { return ErrBadOptionNoBiscuit } myAttributeIndexOpts.SetOpt("exponent", val) The final resolution of the "puzzle" in fact is to invoke allowedOpts.PopulateOptions(pairs, myAttributeIndexOpts) based on pairs being built from the collection of key-value pairs.
Project: Pilosa (App Definition and Development / Database)
File: README.md

This directory contains Terraform to deploy test environments both ad-hoc and as part of CI/CD pipelines. The .modules contains the guts of the operation, the things you probably want are in the other directories, each with a README. With terraform installed (`brew install terraform` if not)... You can do `terraform plan` -> `terraform apply` to spin up a cluster, `terraform destroy` to tear one down. Please read these carefully.
Project: NATS (App Definition and Development / Streaming & Messaging)
File: README.md

Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite. For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis. The script `runTestsOnTravis.sh` will run a given job based on the definition found in "`.travis.yml`". As for the naming convention: All JetStream tests name should start with `TestJetStream` Cluster tests should go into `jetstreamclustertest.go` and start with `TestJetStreamCluster` Super-cluster tests should go into `jetstreamsupercluster_test.go` and start with `TestJetStreamSuperCluster` Not following this convention means that some tests may not be executed on Travis.
Project: YugabyteDB (App Definition and Development / Database)
File: explore-ysql.md

To open the YSQL shell, run `ysqlsh`. ```sh $ ./bin/ysqlsh ``` ```output ysqlsh (11.2-YB-2.1.0.0-b0) Type "help" for help. yugabyte=# ``` -YB-2.1.0.0-b0) Type "help" for help. yugabyte=# ``` put ysqlsh (11.2-YB-2.1.0.0-b0) Type "help" for help. yugabyte=# ```
Project: Neo4j (App Definition and Development / Database)
File: README.md

This folder contains Cypher Shell, the command line interface to Neo4J. JAR and ZIP distribution are build using maven from `cypher-shell` subproject. RPM and Debian packages are build using make from `packaging` directory, see for details. This clears any previously known neo4j hosts, starts a throw-away instance of neo4j using docker, and connects to it. ```sh rm -rf ~/.neo4j/known_hosts docker run --rm -p 7687:7687 -e NEO4J_AUTH=none neo4j:4.1 make run ``` See . A minimal test of the executable can be run with `make tyre-kicking-test`.ation-test --projects org.neo4j:cypher-shell-integration-test --also-make -DenableCypherShellIntegrationTest ```
Project: TiDB (App Definition and Development / Database)
File: CONTRIBUTING.md

See the in the repository.ution accepted. Fork the repository on GitHub. Read the README.md for build instructions. Play with the project, submit bugs, submit patches! Developing BR requires: An internet connection to download the dependencies Navigate to the tidb directory ```sh cd ../tidb ``` run `make build_br` to build the program. ```sh make build_br ``` After all these, you will find `br` in `tidb/bin` directory This project contains unit tests and integration tests with coverage collection. See for how to execute and add tests. BR uses to manage dependencies. To add or update a dependency: use the `go mod edit` command to change the dependency. This is a rough outline of what a contributor's workflow looks like: Create a topic branch from where you want to base your work. This is usually `master`. Make commits of logical units and add test case if the change fixes a bug or adds new functionality. Run tests and make sure all the tests are passed. Make sure your commit messages are in the proper format (see below). Push your changes to a topic branch in your fork of the repository. Submit a pull request. Your PR must receive LGTMs from two maintainers. Thanks for your contributions! The coding style suggested by the Golang community is used in BR. See the for details. Please follow this style to make BR easy to review, maintain and develop. We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why. ``` restore: add comment for variable declaration Improve documentation. ``` The format can be described more formally as follows: ``` <subsystem>: <what changed> <BLANK LINE> <why this change was made> <BLANK LINE> <footer>(optional) ``` The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters. This allows the message to be easier to read on GitHub as well as in various git tools. If the change affects more than one subsystem, you can use comma to separate them like `backup,restore:`. If the change affects many subsystems, you can use `````` instead, like ```:```. For the why part, if no specific reason for the change, you can use one of some generic reasons like "Improve documentation.", "Improve performance.", "Improve robustness.", "Improve test coverage."
Project: Crux (App Definition and Development / Database)
File: README.md

This is very early days as yet. Particularly, it's currently missing tests and user documentation. It's published to NPM as `@xtdb/xtdb` - to add it to a project: `npm install '@xtdb/xtdb'` `yarn add '@xtdb/xtdb'` `import Xtdb, { q, tx, ex } from '@xtdb/xtdb'` `const xtdb = new Xtdb('http://localhost:3000')` Transactions: ```javascript const txKey = await xtdb.submitTx([ tx.putDocs('myTable', {"xt/id": 1, ...}, {"xt/id": 2, ...}), ... ]) ``` Queries: ```javascript const res = await node.query([ q.from('myTable'), q.aggregate({rc: ex.call("rowCount")}) ]) ``` Get yourself an account on https://www.npmjs.com/ Ask @jarohen for an invite to the `@xtdb` org. `yarn publish --no-git-tag-version`. We're currently using version `0.0.0-YYYY.M.D.n` (closest approximation to a Maven snapshot).
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: TDengine.md

TDengine sink connector Used to write data to TDengine. You need to create stable before running seatunnel task | name | type | required | default value | |-|--|-|| | url | string | yes | - | | username | string | yes | - | | password | string | yes | - | | database | string | yes | | | stable | string | yes | - | | timezone | string | no | UTC | the url of the TDengine when you select the TDengine e.g. ``` jdbc:TAOS-RS://localhost:6041/ ``` the username of the TDengine when you select the password of the TDengine when you select the database of the TDengine when you select the stable of the TDengine when you select the timeznoe of the TDengine sever, it's important to the ts field ```hocon sink { TDengine { url : "jdbc:TAOS-RS://localhost:6041/" username : "root" password : "taosdata" database : "power2" stable : "meters2" timezone: UTC } } ```
Project: Vitess (App Definition and Development / Database)
File: README.md

This README is kept here for reference, however the parent contains all the information necesaary to simulate this in a better way This directory has a docker-compose that will bring up a mysql instance. You can then point your vitess cluster to it to understand how to use Vitess for your existing database when you cannot install Vitess on the mysql instance. First you will need to . Create a new docker-machine that will run your mysql container. Creating a new machine allows you to more comprehensively test the remote functionality. ``` vitess/examples/compose/external_db$ docker-machine create remote-db ``` Grab the docker-machine ip ``` vitess/examples/compose/external_db$ docker-machine ip remote-db 192.168.99.101 ``` Set the environment variables for the remote-db machine ``` vitess/examples/compose/external_db$ eval $(docker-machine ip remote-db) ``` Start the mysql instance ``` vitess/examples/compose/external_db$ docker-compose up -d ``` This will do the following; Starts mysql service and exposes it at `<docker-machine-ip>:3306` Creates a `commerce` database with `users` table Adds sample data to the users table Starts a lightweight adminer container to interact with the database accessible at `<docker-machine-ip>:8081` Default credentials ``` MYSQL_DB: commerce MYSQL_USER: dbuser MYSQL_PASSWORD: dbpass MYSQLROOTPASSWORD: pass ``` Run the following ``` vitess/examples/compose/external_db$ docker-compose ps ``` A valid response should look like below ```sh Name Command State Ports externaldbadminer_1 entrypoint.sh docker-php-e ... Up 0.0.0.0:8081->8080/tcp externaldbdb_1 docker-entrypoint.sh mysqld Up (healthy) 0.0.0.0:3306->3306/tcp, 33060/tcp ``` You now have a mysql instance ready to be migrated to Vitess. Head on to If using docker-compose.beginners.yml, run; ``` vitess/examples/compose$ cp docker-compose.beginners.yml docker-compose.yml ``` Update your `.env` file with these; ``` KEYSPACE=commerce DB=commerce EXTERNAL_DB=1 DB_HOST=<docker-machine-ip> DB_PORT=3306 DB_USER=dbuser DB_PASS=dbpass DBCHARSET=CHARACTER SET latin1 COLLATE latin1swedish_ci ``` If using `vtcompose` command, run; ``` vitess/examples/compose$ go run vtcompose/vtcompose.go -keyspaceData="commerce:0:2::" -externalDbData="commerce:<docker-machine-ip>:3306:dbuser:dbpass:CHARACTER SET latin1 COLLATE latin1swedishci" ``` Ensure you start Vitess in a different docker-machine!! If not, run; ``` vitess/examples/compose$ docker-machine create vitess vitess/examples/compose$ $(docker-machine env vitess) ``` Start Vitess ``` vitess/examples/compose$ docker-compose up -d ``` You should now have Vitess running against your external database instance. Migrating to Vitess entirely can be done from; a) The Vitess Control Panel at http://<vitess_ip>:15000 b) The `lvtctl.sh` Helper Script; The steps are same Do an EmergencyReparentShard to make a replica the new primary. Ran InitShardPrimary on the new primary. If Vitess is wrong about who the MySQL primary is, you can update it with TabletExternallyReparented
Project: Crunchy Postgres Operator (App Definition and Development / Database)
File: README.md

This is a variation derived from our major upgrade KUTTL tests designed to test scenarios where required container images are not defined in either the PostgresCluster spec or via the RELATED_IMAGES environment variables. 01--valid-upgrade: create a valid PGUpgrade instance 01-assert: check that the PGUpgrade instance exists and has the expected status 10--cluster: create the cluster with an unavailable image (i.e. Postgres 10) 10-assert: check that the PGUpgrade instance has the expected reason: "PGClusterNotShutdown" 11-shutdown-cluster: set the spec.shutdown value to 'true' as required for upgrade 11-assert: check that the new reason is set, "PGClusterPrimaryNotIdentified" 12--start-and-update-version: update the Postgres version on both CRD instances and set 'shutdown' to false 12-assert: verify that the cluster is running and the PGUpgrade instance now has the new status info with reason: "PGClusterNotShutdown" 13--shutdown-cluster: set spec.shutdown to 'true' 13-assert: check that the PGUpgrade instance has the expected reason: "PGClusterMissingRequiredAnnotation" 14--annotate-cluster: set the required annotation 14-assert: verify that the upgrade succeeded and the new Postgres version shows in the cluster's status 15--start-cluster: set the new Postgres version and spec.shutdown to 'false' 15-assert: verify that the cluster is running 16-check-pgbackrest: check that the pgbackrest setup has successfully completed 17--check-version: check the version reported by PostgreSQL 17-assert: assert the Job from the previous step succeeded
Project: Redis (App Definition and Development / Database)
File: README.md

This Tcl script is what I used in order to generate the graph you can find at http://antirez.com/news/98. It's really quick & dirty, more a trow away program than anything else, but probably could be reused or modified in the future in order to visualize other similar data or an updated version of the same data. The usage is trivial: ./genhtml.tcl > output.html The generated HTML is quite broken but good enough to grab a screenshot from the browser. Feel free to improve it if you got time / interest. Note that the code filtering the tags, and the hardcoded branch name, does not make the script, as it is, able to analyze a different repository. However the changes needed are trivial.
Project: CloudNativePG (App Definition and Development / Database)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2014 Mitchell Hashimoto Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.