cwielenb/CNCF-Dataset huggingface dataset:
Project: YugabyteDB (App Definition and Development / Database)
File: third-party-software.md

title: Third-party software headerTitle: Third-party software linkTitle: Third-party software description: Learn about the third-party software contained in YugabyteDB. menu: preview: parent: legal identifier: third-party-software weight: 30 type: docs Yugabyte proudly participates in the open source community and appreciates all open source contributions that have been incorporated into the YugabyteDB open source project. The YugabyteDB codebase has leveraged several open source projects as a starting point, including the following: PostgreSQL stateless language layer for implementing YSQL. PostgreSQL scanner and parser modules (`.y` and `.l` files) were used as a starting point for implementing the YCQL scanner and parser in C++. The DocDB document store uses a customized and enhanced version of . Some of the customizations and enhancements are described in . The Apache Kudu Raft implementation and server framework were used as a starting point. Since then, Yugabyte has implemented several enhancements, such as leader leases and pre-voting state during learner mode for correctness, improvements to the network stack, auto balancing of tablets on failures, zone/DC aware data placement, leader-balancing, ability to do full cluster moves in a online manner, and more. Google libraries (`glog`, `gflags`, `protocol buffers`, `snappy`, `gperftools`, `gtest`, `gmock`). Yugabyte products incorporate third party software, which includes the copyrighted, patented, or otherwise legally protected software of third parties. The release notes for every include a list of the third-party open-source software components that are incorporated into YugabyteDB products, along with license information for each of those third-party components.
Project: Beam (App Definition and Development / Streaming & Messaging)
File: prosimo.md

title: "Prosimo" icon: /images/logos/powered-by/prosimo.png hasLink: "https://prosimo.io/building-blocks-of-an-analytics-pipeline/" <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->
Project: TiDB (App Definition and Development / Database)
File: 2020-09-12-utf8mb4-pinyin-order.md

Author(s): Last updated: 2020-11-06 Discussion at: https://github.com/pingcap/tidb/issues/19747 This proposal proposes a new feature that supports `pinyin` order for chinese character. It's unable now to order by a column based on its pinyin order. For example: ```sql create table t( a varchar(100) ) charset = 'utf8mb4' collate = 'utf8mb4zh0900ascs'; insert into t values (""), (""); select * from t order by a; +--+ | a | +--+ | | | | +--+ 2 rows in set (0.00 sec) ``` `pinyin` order for Chinese character supported by this proposal will add a new collation named `utf8mb4zhpinyintidbascs` which is support all Unicode and sort Chinese characters correctly according to the PINYIN collation in zh.xml file of , and only support those Chinese characters with `pinyin` in zh.xml currently, we support neither those CJK characters whose category defined in Unicode are Symbol with the same shape as Chinese characters nor the PINYIN characters. In `utf8mb4zhpinyintidbascs`, `utf8mb4` means charset utf8mb4, `zh` means Chinese language, `pinyin` means it has pinyin order, `tidb` means a special(tidb) version, and `as_cs` means it is accent-sensitive and case-sensitive. It's a lot of work if we implement `utf8mb4zh0900ascs`. The implementation of MySQL looks complicated with weight reorders, magic numbers, and some tricks. Implementing `utf8mb4zhpinyintidbas_cs` is much easier. It supports all Chinese characters and sorts Chinese characters in pinyin order. It is good enough. It is not compatible with MySQL. MySQL does not have a collation named `utf8mb4zhpinyintidbas_cs`. For any Chinese character, which has non-zero seq NO. defined in zh.xml according to its gb18030 code, the final weight shall be 0xFFA00000+(seq No.) For any non-Chinese gb18030 character 2 bytes C, the final weight shall be C itself. For any non-Chinese gb18030 character 4 bytes C, the final weight shall be 0xFF000000+diff(C)(we get diff by Algorithm). Choose collation ID `2048` for `utf8mb4zhpinyintidbas_cs` and add it into parser. MySQL supports two-byte collation IDs. The range of IDs from 1024 to 2047 is reserved for user-defined collations. `utf8mb4zhpinyintidbascs` has same priority with `utf8mb4unicodeci` and `utf8mb4general_ci`, which means these three collations incompatible with each other. MySQL has a lot of language specific collations, for `pinyin` order, MySQL uses collation `utf8mb4zh0900ascs`. There is no `utf8mb4zhpinyintidbascs` collation in MySQL. We can comment `utf8mb4zhpinyintidbascs` when users need to replicate their data from TiDB to MySQL. https://github.com/pingcap/tidb/issues/19747 https://github.com/pingcap/tidb/issues/10192
Project: CockroachDB (App Definition and Development / Database)
File: hotranges-response.md

<a name="cockroach.server.serverpb.HotRangesResponse"></a> HotRangesResponse is the payload produced in response to a HotRangesRequest. Support status: | Field | Type | Label | Description | Support status | | -- | - | -- | -- | -- | | node_id | | | NodeID is the node that received the HotRangesRequest and forwarded requests to the selected target node(s). | | | hotrangesbynodeid | | repeated | HotRangesByNodeID contains a hot range report for each selected target node ID in the HotRangesRequest. | |
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-machine-reset.1.md

% podman-machine-reset 1 podman\-machine\-reset - Reset Podman machines and environment podman machine reset [options] Reset your Podman machine environment. This command stops any running machines and then removes them. Configuration and data files are then removed. Data files would include machine disk images and any previously pulled cache images. When this command is run, all of your Podman machines will have been deleted. Reset without confirmation. Print usage statement. ``` $ podman machine reset Warning: this command will delete all existing podman machines and all of the configuration and data directories for Podman machines The following machine(s) will be deleted: dev podman-machine-default Are you sure you want to continue? [y/N] y $ ``` , Feb 2024, Originally compiled by Brent Baude<bbaude@redhat.com>
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-secret-exists.1.md

% podman-secret-exists 1 podman\-secret\-exists - Check if the given secret exists podman secret exists secret podman secret exists checks if a secret exists. Podman returns an exit code of `0` when the secret is found. A `1` is returned otherwise. An exit code of `125` indicates there was another issue. Print usage statement Check if a secret called `mysecret` exists (the secret does actually exist). ``` $ podman secret exists mysecret $ echo $? 0 $ ``` Check if a secret called `mypassword` exists (the secret does not actually exist). ``` $ podman secret exists mypassword $ echo $? 1 $ ``` , April 2023, Originally compiled by Ygal Blum `<ygal.blum@gmail.com>`
Project: external-secrets (Provisioning / Security & Compliance)
File: passbolt.md

External Secrets Operator integrates with to sync Passbolt to secrets held on the Kubernetes cluster. Be sure the `passbolt` provider is listed in the `Kind=SecretStore` and auth and host are set. The API requires a password and private key provided in a secret. ```yaml {% include 'passbolt-secret-store.yaml' %} ``` To sync a Passbolt secret to a Kubernetes secret, a `Kind=ExternalSecret` is needed. By default the secret contains name, username, uri, password and description. To only select a single property add the `property` key. ```yaml {% include 'passbolt-external-secret-example.yaml' %} ``` The above external secret will lead to the creation of a secret in the following form: ```yaml {% include 'passbolt-secret-example.yaml' %} ``` Instead of retrieving secrets by ID you can also use `dataFrom` to search for secrets by name. ```yaml {% include 'passbolt-external-secret-findbyname.yaml' %} ```
Project: Apache CarbonData (App Definition and Development / Database)
File: supported-data-types-in-carbondata.md

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Numeric Types SMALLINT INT/INTEGER BIGINT DOUBLE DECIMAL FLOAT BYTE NOTE: Float and Bytes are only supported for SDK and FileFormat. Date/Time Types TIMESTAMP DATE String Types STRING NOTE: For string longer than 32000 characters, use `LONGSTRINGCOLUMNS` in table property. Please refer to TBLProperties in for more information. Complex Types arrays: ARRAY``<data_type>`` structs: STRUCT``<colname : datatype COMMENT col_comment, ...>`` maps: MAP``<primitivetype, datatype>`` NOTE: Only 2 level complex type schema is supported for now. Other Types BOOLEAN BINARY
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: sup_update.md

+++ title = "Updating the Supervisor" description = "Updating the Supervisor" gh_repo = "habitat" [menu] [menu.habitat] title = "Updating Supervisors" identifier = "habitat/supervisors/updating" parent = "habitat/supervisors" weight = 130 +++ Each new Chef Habitat release brings a new Supervisor that includes all bug fixes and enhancements since the last release. It's a good idea to stay relatively up to date with your running Supervisors. When updating Supervisors in production, you usually will not want to shut down all of your running services while you perform the update. That could incur an outage or require a maintenance window. Chef Habitat provides a couple of ways for you to update a Supervisor without stopping your running services. While an older version of the Supervisor is running, install the newer Supervisor into your local Chef Habitat package repository: ```bash hab pkg install core/hab-sup ``` This will not update the running Supervisor. It simply downloads the new Supervisor and stores it in your `/hab/pkgs` store. To update the running Supervisor, restart it with: ```bash hab sup restart ``` This will not restart the running services; it will only restart the supervisor service. You can configure the Supervisor to automatically update itself when new Supervisor releases become available. This is done by adding the `--auto-update` flag to `hab sup run` or by setting `auto_update` to `true` in `/hab/sup/default/config/sup.toml`. By default, the Supervisor will check for updates every 60 seconds. This can be adjusted by changing the `--auto-update-period` to a different number of seconds. If you want the Supervisor to look for updated Supervisor releases in a on-prem depot or in a channel other than `stable`, then use the `--url` and `--channel` arguments of `hab sup run` to point to the desired Builder URL and release channel.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: health-start-period.md

The initialization time needed for a container to bootstrap. The value can be expressed in time format like 2m3s. The default value is 0s. Note: The health check command is executed as soon as a container is started, if the health check is successful the container's health state will be updated to `healthy`. However, if the health check fails, the health state will stay as `starting` until either the health check is successful or until the `--health-start-period` time is over. If the health check command fails after the `--health-start-period` time is over, the health state will be updated to `unhealthy`. The health check command is executed periodically based on the value of `--health-interval`.
Project: StarRocks (App Definition and Development / Database)
File: dayofyear.md

displayed_sidebar: "English" Returns the day of the year for a given date. The `date` parameter must be of the DATE or DATETIME type. ```Haskell INT DAYOFYEAR(DATETIME|DATE date) ``` ```Plain Text MySQL > select dayofyear('2007-02-03 00:00:00'); +-+ | dayofyear('2007-02-03 00:00:00') | +-+ | 34 | +-+ ``` DAYOFYEAR
Project: VMClarity (Provisioning / Security & Compliance)
File: ARCHITECTURE.md

Today, VMClarity has two halves, the VMClarity control plane, and the VMClarity CLI. The VMClarity control plane includes several microservices: API Server: The VMClarity API for managing all objects in the VMClarity system. This is the only component in the system which talks to the DB. Orchestrator: Orchestrates and manages the life cycle of VMClarity scan configs, scans and asset scans. Within the Orchestrator there is a pluggable "provider" which connects the orchestrator to the environment to be scanned and abstracts asset discovery, VM snapshotting as well as creation of the scanner VMs. (Note The only supported provider today is AWS, other hyperscalers are on the roadmap) UI Backend: A separate backend API which offloads some processing from the browser to the infrastructure to process and filter data closer to the source. UI Webserver: A server serving the UI static files. DB: Stores the VMClarity objects from the API. Supported options are SQLite and Postgres. Scanner Helper services: These services provide support to the VMClarity CLI to offload work that would need to be done in every scanner, for example downloading the latest vulnerability or malware signatures from the various DB sources. The components included today are: grype-server: A rest API wrapper around the grype vulnerability scanner trivy-server: Trivy vulnerability scanner server exploitDB server: A test API which wraps the Exploit DB CVE to exploit mapping logic freshclam-mirror: A mirror of the ClamAV malware signatures The VMClarity CLI contains all the logic for performing a scan, from mounting attached volumes and all the pluggable infrastructure for all the families, to exporting the results to VMClarity API. These components are containerized and can be deployed in a number of different ways. For example our cloudformation installer deploys VMClarity on a VM using docker in a dedicated AWS Virtual Private Cloud (VPC). Once the VMClarity server instance has been deployed, and the scan configurations have been created, VMClarity will discover VM resources within the scan range defined by the scan configuration (e.g., by region, instance tag, and security group). Once the asset list has been created, snapshots of the assets are taken, and a new scanner VM are launched using the snapshots as attached volumes. The VMClarity CLI running within the scanner VM will perform the configured analysis on the mounted snapshot, and report the results to the VMClarity API. These results are then processed by the VMClarity backend into findings.
Project: ArangoDB (App Definition and Development / Database)
File: boost_unchecked.md

+++ title = "`boostunchecked<T, E = boost::system::errorcode>`" description = "A type alias to a `basicresult` configured with `boost::system::errorcode` and `policy::all_narrow`." +++ A type alias to a {{% api "basicresult<T, E, NoValuePolicy>" %}} configured with `boost::system::errorcode` and `policy::`{{% api "all_narrow" %}}. This type alias always references the `boost` edition of things, unlike {{% api "unchecked<T, E = varies>" %}} which references either this alias or {{% api "stdunchecked<T, E = std::errorcode>" %}}. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/boost_result.hpp>`
Project: ClickHouse (App Definition and Development / Database)
File: rename.md

slug: /en/sql-reference/statements/rename sidebar_position: 48 sidebar_label: RENAME Renames databases, tables, or dictionaries. Several entities can be renamed in a single query. Note that the `RENAME` query with several entities is non-atomic operation. To swap entities names atomically, use the statement. Syntax ```sql RENAME [DATABASE|TABLE|DICTIONARY] name TO new_name [,...] [ON CLUSTER cluster] ``` Renames databases. Syntax ```sql RENAME DATABASE atomicdatabase1 TO atomicdatabase2 [,...] [ON CLUSTER cluster] ``` Renames one or more tables. Renaming tables is a light operation. If you pass a different database after `TO`, the table will be moved to this database. However, the directories with databases must reside in the same file system. Otherwise, an error is returned. If you rename multiple tables in one query, the operation is not atomic. It may be partially executed, and queries in other sessions may get `Table ... does not exist ...` error. Syntax ``` sql RENAME TABLE [db1.]name1 TO [db2.]name2 [,...] [ON CLUSTER cluster] ``` Example ```sql RENAME TABLE tableA TO tableAbak, tableB TO tableBbak; ``` And you can use a simpler sql: ```sql RENAME tableA TO tableAbak, tableB TO tableBbak; ``` Renames one or several dictionaries. This query can be used to move dictionaries between databases. Syntax ```sql RENAME DICTIONARY [db0.]dictA TO [db1.]dictB [,...] [ON CLUSTER cluster] ``` See Also
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: sql-ref-syntax-aux-describe.md

layout: global title: Describe Commands displayTitle: Describe Commands license: | Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. * *
Project: CloudNativePG (App Definition and Development / Database)
File: use_cases.md

CloudNativePG has been designed to work with applications that reside in the same Kubernetes cluster, for a full cloud native experience. However, it might happen that, while the database can be hosted inside a Kubernetes cluster, applications cannot be containerized at the same time and need to run in a traditional environment such as a VM. In a typical situation, the application and the database run in the same namespace inside a Kubernetes cluster. The application, normally stateless, is managed as a standard `Deployment`, with multiple replicas spread over different Kubernetes node, and internally exposed through a `ClusterIP` service. The service is exposed externally to the end user through an `Ingress` and the provider's load balancer facility, via HTTPS. The application uses the backend PostgreSQL database to keep track of the state in a reliable and persistent way. The application refers to the read-write service exposed by the `Cluster` resource defined by CloudNativePG, which points to the current primary instance, through a TLS connection. The `Cluster` resource embeds the logic of single primary and multiple standby architecture, hiding the complexity of managing a high availability cluster in Postgres. Another possible use case is to manage your PostgreSQL database inside Kubernetes, while having your applications outside of it (for example in a virtualized environment). In this case, PostgreSQL is represented by an IP address (or host name) and a TCP port, corresponding to the defined Ingress resource in Kubernetes. The application can still benefit from a TLS connection to PostgreSQL.
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: feat-11581.en.md

Preview Feature: Support for Version 2 Bridge Design Introduction of Action with a new 'connector' concept In the original Bridge v1 design, each connector was exclusively tied to a single bridge. This design prioritized error isolation and performance but posed challenges for users setting up multiple bridges to the same service. For instance, setting up 10 bridges to a single Kafka cluster required the same configuration to be repeated for each bridge. The revamped Action design provides more flexibility and better scalability: Users have the option to either share a connector across multiple bridges or retain it exclusively for one bridge, as in v1. For the majority of data bridges, sharing a connector among too many bridges might lead to performance degradation but avoids overloading the external system with too many connections if the number of bridges is very high. In some cases, specific data bridges always utilize dedicated connections, even when the connector is shared. Right now these are: Kafka Producer Azure Event Hub Producer Management of Connectors Connectors can now be managed separately, bringing in more flexibility. New API endpoints have been introduced under the `/connectors` path for connector management. Actions can be managed via the `/actions` endpoint. Limitations in e5.3.1 Currently, only the Kafka and Azure Event Hub producer bridges have been upgraded to the action design. The action feature is accessible through config files and HTTP APIs. However, it's not yet available on the dashboard UI.
Project: Druid (App Definition and Development / Database)
File: downloads.md

title: Download <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at * http://www.apache.org/licenses/LICENSE-2.0 * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Edit this page in the repo. To see your changes, navigate to them from the .
Project: Beam (App Definition and Development / Streaming & Messaging)
File: CVE-2020-1929.md

title: CVE-2020-1929 <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->