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

+++ title = "`bool operator!=(const basic_outcome<A, B, C, D> &) const`" description = "Returns true if this outcome does not compare equal to the other outcome. Constexpr and noexcept propagating." categories = ["comparisons"] weight = 846 +++ Returns true if this outcome does not compare equal to the other outcome. Comparison is done using `operator!=` on `valuetype`, `errortype` and/or `exception_type` if the currently chosen state is the same for both outcomes, otherwise true is returned. Requires: `operator!=` must be a valid expression between `valuetype` and `A`, and between `errortype` and `B`, and between `exceptiontype` and `C`. If `valuetype` is `void`, then so must be `A`; similarly for `errortype` and `B`; similarly for `exceptiontype` and `C`. Complexity: Whatever the underlying `operator!=` have. Constexpr and noexcept of underlying operations is propagated. Guarantees: None.
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: binop.md

The `BinOp` rule is a convenience that allows defining a template for a common sub rule sequence. The `BinOp` macro rule definition in tremor DSLs allows binary operations to be defined tersely |Argument|Description| ||| |Current|The current rule permissible for the LHS of the expression| |Operation|The operation to be performeed| |Next|The current rule permissible for the RHS of the expression| The macro imposes rule precedence where the left hand side expression takes higher precedence relative to the right hand side expression when interpreted by tremor. Tremor performs compile time optimizations such as constant folding. So literal expressions of the form `1 + 2` may compile to a constant ( `3` in this case ) and have no runtime cost.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: operator-sdk_init.md

title: "operator-sdk init" Initialize a new project Initialize a new project including the following files: a "go.mod" with project dependencies a "PROJECT" file that stores project configuration a "Makefile" with several useful make targets for the project several YAML files for project deployment under the "config" directory a "cmd/main.go" file that creates the manager that will run the project controllers ``` operator-sdk init [flags] ``` ``` operator-sdk init --plugins go/v4 --domain example.org --owner "Your name" operator-sdk init --plugins go/v4 --project-version 3 ``` ``` --domain string domain for groups (default "my.domain") --fetch-deps ensure dependencies are downloaded (default true) -h, --help help for init --license string license to use to boilerplate, may be one of 'apache2', 'none' (default "apache2") --owner string owner to add to the copyright --project-name string name of this project --project-version string project version (default "3") --repo string name to use for go module (e.g., github.com/user/repo), defaults to the go package of the current working directory. --skip-go-version-check if specified, skip checking the Go version ``` ``` --plugins strings plugin keys to be used for this subcommand execution --verbose Enable verbose logging ``` -
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: sup.md

+++ title = "Chef Habitat Supervisor" aliases = ["/habitat/best-practices/"] date = 2020-10-26T18:47:18-07:00 draft = false gh_repo = "habitat" [menu] [menu.habitat] title = "About Supervisors" identifier = "habitat/supervisors/sup Supervisors" parent = "habitat/supervisors" weight = 10 +++ The Supervisor is a process manager that has two primary responsibilities. First, it starts and monitors child services defined in the plan it is running. Second, it receives and acts upon information from the other Supervisors to which it is connected. A service will be reconfigured through application lifecycle hooks if its configuration has changed. Supervisors typically run in a network, which we refer to as a ring (although it is more like a peer-to-peer network rather than a circular ring). The ring can be very large; it could contain hundreds or thousands of supervisors. The membership list of this ring is maintained independently by each Supervisor and is known as the census. The census is the core of the service discovery mechanism in Chef Habitat. It keeps track of every Supervisor in the ring, and handles reading, writing, and serializing it with the discovery backend. Each Supervisor in the system is a census entry that together form a census. Operations to discover or mutate the state of the census happen through algorithms that arrive at the same conclusion given the same inputs. An example is leader election: it's handled here by having a consistent (and simple) algorithm for selecting a leader deterministically for the group. We rely on the eventual consistency of every Supervisor's census entry to elect a new leader in a reasonable amount of time. The Chef Habitat Supervisor provides a HTTP API to expose cluster metadata, statistics, and general diagnostic information useful for monitoring and support in the form of a JSON document. It also provides detailed information about the Chef Habitat package that it is supervising, including metadata such as the build and runtime dependencies and their versions. The Supervisor control gateway is used to issue commands to a remote Supervisor. When a new Supervisor is created, a key for the `HABCTLSECRET` environment variable is generated for it by default, if one is not already present; this key is used to authenticate requests that are made via the control gateway. See the documentation for more details.
Project: Salt Project (Provisioning / Automation & Configuration)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: "[FEATURE REQUEST]" labels: Feature, needs-triage 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. Please Note If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.93.md

layout: release date: 2023-06-13 tag: v0.6.93 [Docker Extension] Contributor instructions @leecalcote (#7837) [Server] Enhance Kubernetes missing context error message @leecalcote (#7852) Bump relay-runtime from 14.1.0 to 15.0.0 in /ui @dependabot (#7773) [Performance] revert the subscription delete change @Abhishek-kumar09 (#7853) fix settings page title is not updating @Meyazhagan (#7793) Bump relay-runtime from 14.1.0 to 15.0.0 in /ui @dependabot (#7773) Update cncf-playground-deploy-meshery.yaml @leecalcote (#7854) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Meyazhagan, @dependabot and @leecalcote
Project: StarRocks (App Definition and Development / Database)
File: str_to_jodatime.md

displayed_sidebar: "English" Converts a Joda-formatted string into a DATETIME value in the specified Joda DateTime format like `yyyy-MM-dd HH:mm:ss`. ```Haskell DATETIME strtojodatime(VARCHAR str, VARCHAR format) ``` `str`: the time expression you want to convert. It must be of the VARCHAR type. `format`: the Joda DateTime format of the DATETIME value to be returned. For information about the formats available, see . If parsing the input string succeeds, a DATETIME value is returned. If parsing the input string fails, `NULL` is returned. Example 1: Convert the string `2014-12-21 12:34:56` into a DATETIME value in `yyyy-MM-dd HH:mm:ss` format. ```SQL MySQL > select strtojodatime('2014-12-21 12:34:56', 'yyyy-MM-dd HH:mm:ss'); +--+ | strtojodatime('2014-12-21 12:34:56', 'yyyy-MM-dd HH:mm:ss') | +--+ | 2014-12-21 12:34:56 | +--+ ``` Example 2: Convert the string `21/December/23 12:34:56` with a text-style month into a DATETIME value in `dd/MMMM/yy HH:mm:ss` format. ```SQL MySQL > select strtojodatime('21/December/23 12:34:56', 'dd/MMMM/yy HH:mm:ss'); ++ | strtojodatime('21/December/23 12:34:56', 'dd/MMMM/yy HH:mm:ss') | ++ | 2023-12-21 12:34:56 | ++ ``` Example 3: Convert the string `21/December/23 12:34:56.123` accurate to milliseconds into a DATETIME value in `dd/MMMM/yy HH:mm:ss.SSS` format. ```SQL MySQL > select strtojodatime('21/December/23 12:34:56.123', 'dd/MMMM/yy HH:mm:ss.SSS'); +--+ | strtojodatime('21/December/23 12:34:56.123', 'dd/MMMM/yy HH:mm:ss.SSS') | +--+ | 2023-12-21 12:34:56.123000 | +--+ ``` STRTOJODATIME, DATETIME
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: Setting-up-development-environment.md

title: Setting Up a Development Environment layout: documentation documentation: true This page outlines what you need to do to get a Storm development environment set up. In summary, the steps are: Download a , unpack it, and put the unpacked `bin/` directory on your PATH To be able to start and stop topologies on a remote cluster, put the cluster information in `~/.storm/storm.yaml` More detail on each of these steps is below. Storm has two modes of operation: local mode and remote mode. In local mode, you can develop and test topologies completely in process on your local machine. In remote mode, you submit topologies for execution on a cluster of machines. A Storm development environment has everything installed so that you can develop and test Storm topologies in local mode, package topologies for execution on a remote cluster, and submit/kill topologies on a remote cluster. Let's quickly go over the relationship between your machine and a remote cluster. A Storm cluster is managed by a master node called "Nimbus". Your machine communicates with Nimbus to submit code (packaged as a jar) and topologies for execution on the cluster, and Nimbus will take care of distributing that code around the cluster and assigning workers to run your topology. Your machine uses a command line client called `storm` to communicate with Nimbus. The `storm` client is only used for remote mode; it is not used for developing and testing topologies in local mode. If you want to be able to submit topologies to a remote cluster from your machine, you should install a Storm release locally. Installing a Storm release will give you the `storm` client that you can use to interact with remote clusters. To install Storm locally, download a release and unzip it somewhere on your computer. Then add the unpacked `bin/` directory onto your `PATH` and make sure the `bin/storm` script is executable. Installing a Storm release locally is only for interacting with remote clusters. For developing and testing topologies in local mode, it is recommended that you use Maven to include Storm as a dev dependency for your project. You can read more about using Maven for this purpose on . The previous step installed the `storm` client on your machine which is used to communicate with remote Storm clusters. Now all you have to do is tell the client which Storm cluster to talk to. To do this, all you have to do is put the host address of the master in the `~/.storm/storm.yaml` file. It should look something like this: ``` nimbus.seeds: ["123.45.678.890"] ```
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_cluster_connect.md

title: kbcli cluster connect Connect to a cluster or instance. ``` kbcli cluster connect (NAME | -i INSTANCE-NAME) [flags] ``` ``` kbcli cluster connect mycluster kbcli cluster connect mycluster --as-user myuser kbcli cluster connect -i mycluster-instance-0 kbcli cluster connect mycluster --component mycomponent kbcli cluster connect mycluster --show-example --client=cli kbcli cluster connect mycluster --show-example --client=java kbcli cluster connect mycluster --show-example kbcli cluster connect mycluster --show-example --client=cli --show-password ``` ``` --as-user string Connect to cluster as user --client string Which client connection example should be output, only valid if --show-example is true. --component string The component to connect. If not specified, pick up the first one. -h, --help help for connect -i, --instance string The instance name to connect. --show-example Show how to connect to cluster/instance from different clients. --show-password Show password in example. ``` ``` --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: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_data_insert_mysql.md

title: Kubectl-Dba Data Insert Mysql menu: docs_{{ .version }}: identifier: kubectl-dba-data-insert-mysql name: Kubectl-Dba Data Insert Mysql parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Insert data to mysql Use this cmd to insert data into a mysql database. ``` kubectl-dba data insert mysql [flags] ``` ``` kubectl dba data insert mysql -n demo sample-mysql --rows 1000 ``` ``` -h, --help help for mysql -r, --rows int number of rows to insert (default 100) ``` ``` --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/runner/.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 --default-seccomp-profile-type string Default seccomp profile --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 --password string Password for basic authentication to the API server --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 --username string Username for basic authentication to the API server ``` - Insert random data in a database
Project: MongoDB (App Definition and Development / Database)
File: libfuzzer.md

title: LibFuzzer LibFuzzer is a tool for performing coverage guided fuzzing of C/C++ code. LibFuzzer will try to trigger AUBSAN failures in a function you provide, by repeatedly calling it with a carefully crafted byte array as input. Each input will be assigned a "score". Byte arrays which exercise new or more regions of code will score better. LibFuzzer will merge and mutate high scoring inputs in order to gradually cover more and more possible behavior. LibFuzzer is great for testing functions which accept a opaque blob of untrusted user-provided data. LibFuzzer implements `int main`, and expects to be linked with an object file which provides the function under test. You will achieve this by writing a cpp file which implements ```cpp extern "C" int LLVMFuzzerTestOneInput(const uint8t *Data, sizet Size) { // Your code here } ``` `LLVMFuzzerTestOneInput` will be called repeatedly, with fuzzer generated bytes in `Data`. `Size` will always truthfully tell your implementation how many bytes are in `Data`. If your function crashes or induces an AUBSAN fault, LibFuzzer will consider that to be a finding worth reporting. Keep in mind that your function will often "just" be adapting `Data` to whatever format our internal C++ functions requires. However, you have a lot of freedom in exactly what you choose to do. Just make sure your function crashes or produces an invariant when something interesting happens! As just a few ideas: You might choose to call multiple implementations of a single operation, and validate that they produce the same output when presented the same input. You could tease out individual bytes from `Data` and provide them as different arguments to the function under test. Finally, your cpp file will need a SCons target. There is a method which defines fuzzer targets, much like how we define unittests. For example: ```python env.CppLibfuzzerTest( target='opmsgfuzzer', source=[ 'opmsgfuzzer.cpp', ], LIBDEPS=[ '$BUILD_DIR/mongo/base', 'opmsgfuzzer_fixture', ], ) ``` Your test's object file and all of its dependencies must be compiled with the "fuzzer" sanitizer, plus a set of sanitizers which might produce interesting runtime errors like AUBSAN. Evergreen has a build variant, whose name will include the string "FUZZER", which will compile and run all of the fuzzer tests. The fuzzers can be built locally, for development and debugging. Check our Evergreen configuration for the current SCons arguments. LibFuzzer binaries will accept a path to a directory containing its "corpus". A corpus is a list of examples known to produce interesting outputs. LibFuzzer will start producing interesting results more quickly if starts off with a set of inputs which it can begin mutating. When its done, it will write down any new inputs it discovered into its corpus. Re-using a corpus across executions is a good way to make LibFuzzer return more results in less time. Our Evergreen tasks will try to acquire and re-use a corpus from an earlier commit, if it can. [LibFuzzer's official documentation](https://llvm.org/docs/LibFuzzer.html)
Project: ShardingSphere (App Definition and Development / Database)
File: shadow-rule.en.md

+++ title = "Shadow" weight = 5 +++ ```sql REGISTER STORAGE UNIT ds_0 ( HOST="127.0.0.1", PORT=3306, DB="ds_0", USER="root", PASSWORD="root" ),ds_1 ( HOST="127.0.0.1", PORT=3306, DB="ds_1", USER="root", PASSWORD="root" ),ds_2 ( HOST="127.0.0.1", PORT=3306, DB="ds_2", USER="root", PASSWORD="root" ); ``` Create shadow rule ```sql CREATE SHADOW RULE group_0( SOURCE=ds_0, SHADOW=ds_1, torder(TYPE(NAME="SQLHINT"),TYPE(NAME="REGEXMATCH", PROPERTIES("operation"="insert","column"="userid", "regex"='[1]'))), torderitem(TYPE(NAME="SQL_HINT"))); ``` Alter shadow rule ```sql ALTER SHADOW RULE group_0( SOURCE=ds_0, SHADOW=ds_2, torderitem(TYPE(NAME="SQL_HINT"))); ``` Drop shadow rule ```sql DROP SHADOW RULE group_0; ``` Unregister storage unit ```sql UNREGISTER STORAGE UNIT ds0,ds1,ds_2; ``` Drop distributed database ```sql DROP DATABASE foo_db; ```
Project: KICS (Provisioning / Security & Compliance)
File: d7ba74da-2da0-4d4b-83c8-2fd72a3f6c28.md

title: Unrestricted SQL Server Access hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: d7ba74da-2da0-4d4b-83c8-2fd72a3f6c28 Query name: Unrestricted SQL Server Access Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Networking and Firewall URL: Azure SQL Server Accessibility should be set to a minimal address range to grant the principle of least privileges, which means the difference between the values of the 'endipaddress' and 'startipaddress' must be less than 256. Additionally, both ips must be different from '0.0.0.0'.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="27 19" resource "azurermresourcegroup" "positive1" { name = "acceptanceTestResourceGroup1" location = "West US" } resource "azurermsqlserver" "positive2" { name = "mysqlserver" resourcegroupname = azurermresourcegroup.example.name location = "West US" version = "12.0" administrator_login = "4dm1n157r470r" administratorloginpassword = "4-v3ry-53cr37-p455w0rd" } resource "azurermsqlfirewall_rule" "positive3" { name = "FirewallRule1" resourcegroupname = azurermresourcegroup.example.name servername = azurermsql_server.example.name startipaddress = "0.0.0.0" endipaddress = "10.0.27.62" } resource "azurermsqlfirewall_rule" "positive4" { name = "FirewallRule1" resourcegroupname = azurermresourcegroup.example.name servername = azurermsql_server.example.name startipaddress = "10.0.17.62" endipaddress = "10.0.27.62" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermresourcegroup" "negative1" { name = "acceptanceTestResourceGroup1" location = "West US" } resource "azurermsqlserver" "negative2" { name = "mysqlserver" resourcegroupname = azurermresourcegroup.example.name location = "West US" version = "12.0" administrator_login = "4dm1n157r470r" administratorloginpassword = "4-v3ry-53cr37-p455w0rd" } resource "azurermsqlfirewall_rule" "negative3" { name = "FirewallRule1" resourcegroupname = azurermresourcegroup.example.name servername = azurermsql_server.example.name startipaddress = "10.0.17.62" endipaddress = "10.0.17.62" } ```