cwielenb/CNCF-Dataset huggingface dataset:
Project: Docker Compose (App Definition and Development / Application Definition & Image Build)
File: compose_stop.md

<!MARKERGENSTART--> Stop services | Name | Type | Default | Description | |:|:|:--|:--| | `--dry-run` | | | Execute command in dry run mode | | `-t`, `--timeout` | `int` | `0` | Specify a shutdown timeout in seconds | <!MARKERGENEND--> Stops running containers without removing them. They can be started again with `docker compose start`.
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: annotations.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: myapp spec: components: name: express-server type: webservice properties: image: crccheck/hello-world port: 8000 traits: type: labels properties: "release": "stable" type: annotations properties: "description": "web application" ```
Project: Apache RocketMQ (App Definition and Development / Streaming & Messaging)
File: Example_Compaction_Topic.md

CompactionTopic relies on orderMessages to ensure consistency ```shell $ bin/mqadmin updateNamesrvConfig -k orderMessageEnable -v true ``` ```shell $ bin/mqadmin updateTopic -w 8 -r 8 -a +cleanup.policy=COMPACTION -n localhost:9876 -t ctopic -o true -c DefaultCluster create topic to 127.0.0.1:10911 success. TopicConfig [topicName=ctopic, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=false, attributes={+cleanup.policy=COMPACTION}] ``` the same with ordinary message ```java DefaultMQProducer producer = new DefaultMQProducer("CompactionTestGroup"); producer.setNamesrvAddr("localhost:9876"); producer.start(); String topic = "ctopic"; String tag = "tag1"; String key = "key1"; Message msg = new Message(topic, tag, key, "bodys".getBytes(StandardCharsets.UTF_8)); SendResult sendResult = producer.send(msg, (mqs, message, shardingKey) -> { int select = Math.abs(shardingKey.hashCode()); if (select < 0) { select = 0; } return mqs.get(select % mqs.size()); }, key); System.out.printf("%s%n", sendResult); ``` the message offset remains unchanged after compaction. If the consumer specified offset does not exist, return the most recent message after the offset. In the compaction scenario, most consumption was started from the beginning of the queue. ```java DefaultLitePullConsumer consumer = new DefaultLitePullConsumer("compactionTestGroup"); consumer.setNamesrvAddr("localhost:9876"); consumer.setPullThreadNums(4); consumer.start(); Collection<MessageQueue> messageQueueList = consumer.fetchMessageQueues("ctopic"); consumer.assign(messageQueueList); messageQueueList.forEach(mq -> { try { consumer.seekToBegin(mq); } catch (MQClientException e) { e.printStackTrace(); } }); Map<String, byte[]> kvStore = Maps.newHashMap(); while (true) { List<MessageExt> msgList = consumer.poll(1000); if (CollectionUtils.isNotEmpty(msgList)) { msgList.forEach(msg -> kvStore.put(msg.getKeys(), msg.getBody())); } } //use the kvStore ```
Project: Meshery (Provisioning / Automation & Configuration)
File: 02-17-2023-07-45-02_1d2a9534.md

timestamp: "2023-02-17 07:44:50 UTC Fri" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "v0.6.51" k8s-distro: minikube k8s-version: "v1.24.7" service-mesh: Consul service-mesh-version: "v1.0.4" tests: consul-client: null consul-server: null overall-status: "failing"
Project: Hazelcast Jet (App Definition and Development / Streaming & Messaging)
File: index.md

title: Introduction description: Introduction to Hazelcast Jet Enterprise Edition id: version-4.4-index original_id: index Hazelcast Jet Enterprise Edition is a commercial offering from Hazelcast built on top of the open source product, and offers some additional features such as: Management Center which allows for job monitoring and lifecycle management through a web-based UI. Additional security options such as TLS support Lossless cluster restart, which enables to shutdown and restart the cluster gracefully without losing the computational state. Job updates, which allows updating of a streaming job's pipeline from one version to the next without losing computational state. Blue/Green client support, which allows clients to switch from one cluster to the other when one of the clusters are down. Off-heap memory, which allows to large and efficient data storage inside `IMap` through the use of off-heap data structures. Besides these, Jet Enterprise edition offers all the features of the open-source version.
Project: YugabyteDB (App Definition and Development / Database)
File: private-cloud.md

title: Install YugabyteDB Anywhere on Private Cloud Overview headerTitle: Overview linkTitle: Overview description: Installing YugabyteDB Anywhere on private cloud menu: v2.18_yugabyte-platform: identifier: install-3-private-cloud parent: install-yugabyte-platform weight: 20 type: docs Before you get started, decide whether you are deploying on Public cloud, On-premises, or Kubernetes. In public cloud, YugabyteDB Anywhere (YBA) creates and launches virtual machine (VM) instances on the cloud to become nodes in a YugabyteDB universe, and YBA needs permissions to create VMs. In On-premises, you manually create VMs, and then provide the hostnames of these VMs to YBA, where they become "free nodes" to be used in creating universes. All of these process flows follow the same general steps: Install and configure YugabyteDB Anywhere. Create a Provider Configuration (choose among AWS, GCP, Azure, on-prem, or various Kubernetes options). Create a Universe using the configuration. <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../public-cloud/" class="nav-link"> <i class="fa-solid fa-cloud"></i> Public Cloud </a> </li> <li > <a href="../private-cloud/" class="nav-link active"> <i class="fa-solid fa-building"></i> On-premises </a> </li> <li> <a href="../kubernetes/" class="nav-link"> <i class="fa-regular fa-dharmachakra" aria-hidden="true"></i> Kubernetes </a> </li> </ul> The following diagram shows the YugabyteDB Anywhere installation process in a private cloud. Click elements of the chart to access detailed steps. <div class="image-with-map"> <img src="/images/ee/flowchart/yb-install-private-cloud.png" usemap="#image-map"> <map name="image-map"> <area alt="Pre reqs" title="Pre reqs" href="../../prerequisites/installer/" coords="323,255,572,412" shape="rect" style="top: 14%;height: 8.6%;left: 36%;width: 28%;"> <area alt="Online installation" title="Online installation" href="../../install-software/installer/" coords="239,707,396,770" shape="rect" style="top: 40.7%;height: 3.5%;left: 25%;width: 20%;"> <area alt="Airgapped installation" title="Airgapped installation" href="../../install-software/installer/" coords="512,709,663,767" shape="rect" style="top: 40.7%;height: 3.5%;left: 55%;width: 20%;"> <area alt="Online installation - pre reqs" title="Online installation - pre reqs" href="../../install-software/installer/" coords="" shape="rect" style="top: 47%;height: 6%;left: 23%;width: 24%;"> <area alt="Airgapped installation - pre reqs" title="Airgapped installation - pre reqs" href="../../install-software/installer/" coords="482,808,688,841" shape="rect" style="top: 47%;height: 10%;left: 53%;width: 24%;"> <area alt="Prepare on premises nodes" title="Prepare on premises nodes" href="../../prepare-on-prem-nodes/" coords="307,1200,597,1250" shape="rect" style="top: 70.4%;height: 3.6%;left: 33%;width: 34%;"> </map> </div>
Project: ShardingSphere (App Definition and Development / Database)
File: bug-report.md

name: "\U0001F41B Bug Report" about: Something isn't working as expected For English only, other languages will not accept. Before report a bug, make sure you have: Searched open and closed . Read documentation: . Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will close it. Please answer these questions before submitting your issue. Thanks!
Project: secureCodeBox (Provisioning / Security & Compliance)
File: 10-security.md

sidebar_label: Security title: "Security Policy" Our release cycle for new features (minor update) is roughly every two weeks (we will usually make a new release after each review). | Version | Security Fixes | Supported* | | - | | | | 4.x.x | :whitecheckmark: | :whitecheckmark: | | 3.15.x | :whitecheckmark: | :whitecheckmark: | | \<= 2.9.x | :x: | :x: | | \< 2.0 | :x: | :x: | Upcoming major updates will come with a time window in which both major versions (starting with v2.x.x) will receive security updates and bugfixes. The concrete support intervall will be probably a couple of months and will be published when the next major version will be released. We currently plan to provide support for the latest minor release only. We try to make bugfixes and high severity fixes available as patch release for the current minor release as early as possible. If you are interested in extended support for older versions with security updates of our project please get in touch with the project team via Slack or email . You have found a vulnerability in the project that shouldn't be disclosed as public issue before it's fixed? Please get in touch with the project team via Slack or email . You can expect a fast reaction within the next days. We will keep you updated about the next steps and inform you if the vulnerability is accepted and when its fixed or if its ordeclined somehow.
Project: Notary (Provisioning / Security & Compliance)
File: building.md

The notation repo contains the following: `notation` - A CLI for signing and verifying artifacts with Notation Building above binaries require with version `>= 1.22`. Build the binaries, installing them to: `~/bin/notation` ```sh git clone https://github.com/notaryproject/notation.git cd notation make install ``` Verify binaries are installed ```sh which notation /home/<user>/bin/notation ``` If you confront `notation not found`, please add `~/bin/` to your $PATH: ```sh PATH="$HOME/bin:$PATH" ``` If you would like to add the path permanently, add the command to your shell `profile`: ```sh echo 'PATH="$HOME/bin:$PATH"' >> $profile_path source $profile_path ``` The `profile_path` per shell: Bash: `~/.bash_profile` or `~/.profile` Zsh: `~/.zprofile` Ksh: `~/.profile`
Project: StarRocks (App Definition and Development / Database)
File: st_distance_sphere.md

displayed_sidebar: "English" Calculates the spherical distance between two points on the Earth in "meters". The parameters inputted are longitude at X, latitude at X, longitude at Y, latitude at Y. ```Haskell DOUBLE STDistanceSphere(DOUBLE xlng, DOUBLE xlat, DOUBLE ylng, DOUBLE xlat) ``` ```Plain Text MySQL > select stdistancesphere(116.35620117, 39.939093, 116.4274406433, 39.9020987219); +-+ | stdistancesphere(116.35620117, 39.939093, 116.4274406433, 39.9020987219) | +-+ | 7336.9135549995917 | +-+ ``` STDISTANCESPHERE,ST,DISTANCE,SPHERE
Project: LinuxKit (Provisioning / Automation & Configuration)
File: wireguard.md

is a modern VPN released for the Linux kernel that can replace IPSec. We can use WireGuard in Moby to better secure container networking. WireGuard transparently encrypts and authenticates traffic between all peers, and uses state-of-the-art cryptography from the . Moreover, WireGuard is implemented in less than a few thousand lines of code, making it auditable for security. Moreover, WireGuard provides a `wg0` (`wg1`, `wg2`,... etc) network interface that can be passed directly to containers, such that all intercontainer traffic would benefit from encrypted and authenticated networking. A full technical paper from NDSS 2017 is available . The protocol has been formally verified, with a paper describing the security proofs available . The default kernels build WireGuard in as a module. The userspace tools are now a package available in `tools/alpine`, which can be installed via `apk add wireguard-tools`. To give WireGuard a spin, the is a good way to get going. For containers, WireGuard has a that we could use for Moby's containers. We have yet to determine the best way to integrate WireGuard into Moby - at the node level or service level isolation. Node level: it's plausible that Moby's provisioner could allocate keys per Moby node Service level: swarmkit could set up WireGuard on a per-service basis, handing the container the wireguard interface Service Level: one proposal is to use WireGuard between container network . This is a natural fit because WireGuard associates public keys to IP addresses: a docker-compose link would simply need a reference to a key in addition to the existing IP address info for this to work. However there are some open questions: `containerd` does not intend to support networks from the roadmap `links` are not currently supported on swarm stack deploys at present
Project: Meshery (Provisioning / Automation & Configuration)
File: nats-operator.md

layout: integration title: NATS Operator subtitle: Collaborative and visual infrastructure as code for Mongodb Operator image: /assets/img/integrations/nats-operator/icons/color/nats-operator-color.svg permalink: extensibility/integrations/nats-operator docURL: https://docs.meshery.io/extensibility/integrations/nats-operator description: integrations-category: App Definition and Development integrations-subcategory: Streaming & Messaging registrant: Artifact Hub components: name: nats-cluster colorIcon: assets/img/integrations/nats-operator/components/nats-cluster/icons/color/nats-cluster-color.svg whiteIcon: assets/img/integrations/nats-operator/components/nats-cluster/icons/white/nats-cluster-white.svg description: name: nats-service-role colorIcon: assets/img/integrations/nats-operator/components/nats-service-role/icons/color/nats-service-role-color.svg whiteIcon: assets/img/integrations/nats-operator/components/nats-service-role/icons/white/nats-service-role-white.svg description: featureList: [ "With true multi-tenancy, securely isolate message topics", "Bring your own NATS server", "Meshery Broker with NATS inside" ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Crunchy Postgres Operator (App Definition and Development / Database)
File: README.md

This Kuttl routine runs through the following steps: 00: Creates the cluster and verifies that it exists and is ready for connection 01: Connects to the cluster with the PGO-generated password (both with env vars and with the URI) 02: Change the password (using Kuttl's update object method on the secret's `data` field) and verify that the password changes by asserting that the `verifier` field is not blank (using KUTTL's `errors` method, which makes sure that a state is not met by a certain time) 03: Connects to the cluster with the user-defined password (both with env vars and with the URI) 04: Change the password and verifier (using Kuttl's update object method on the secret's `stringData` field) and verify that the password changes by asserting that the `uri` field is not blank (using KUTTL's `errors` method, which makes sure that a state is not met by a certain time) 05: Connects to the cluster with the second user-defined password (both with env vars and with the URI) 06: Updates the postgrescluster spec with a custom user and password 07: Connects to the cluster with the PGO-generated password (both with env vars and with the URI) for the custom user 08: Change the custom user's password (using Kuttl's update object method on the secret's `data` field) and verify that the password changes by asserting that the `verifier` field is not blank (using KUTTL's `errors` method, which makes sure that a state is not met by a certain time) 09: Connects to the cluster with the user-defined password (both with env vars and with the URI) for the custom user 10: Change the custom user's password and verifier (using Kuttl's update object method on the secret's `stringData` field) and verify that the password changes by asserting that the `uri` field is not blank (using KUTTL's `errors` method, which makes sure that a state is not met by a certain time) 11: Connects to the cluster with the second user-defined password (both with env vars and with the URI) for the custom user
Project: CloudEvents (App Definition and Development / Streaming & Messaging)
File: text-verification.md

We check that the specs verification works correctly This is the reason we have a `<!-- no verify links -->` here You MUST NOT have the word Cloud Event or the word Cloud Events even if they are separated by newlines Cloud Event or CloudEvents Also we check that the following words are capitalized correctly MUST and not must MUST NOT and not must NOT even with newlines MUST NOT and not must not SHOULD and not sHoulD SHOULD NOT and not should not OPTIONAL but not optionaL optionally is ok though SHALL and not shall SHALL NOT and not shall not MARSHALL is ok though REQUIRED and not required "required" is ok though
Project: kube-hunter (Provisioning / Security & Compliance)
File: KHV047.md

vid: KHV047 title: Pod With Mount To /var/log categories: [Privilege Escalation] severity: high Kubernetes uses `/var/log/pods` on nodes to store Pods log files. When running `kubectl logs` the kubelet is fetching the pod logs from that directory. If a container has write access to `/var/log` it can create arbitrary files, or symlink to other files on the host. Those would be read by the kubelet when a user executes `kubectl logs`. Consider disallowing running as root: Using Kubernetes Pod Security Policies with `MustRunAsNonRoot` policy. Aqua users can use a Runtime Policy with `Volume Blacklist`. Consider disallowing writable host mounts to `/var/log`: Using Kubernetes Pod Security Policies with `AllowedHostPaths` policy. Aqua users can use a Runtime Policy with `Blacklisted OS Users and Groups`.
Project: YugabyteDB (App Definition and Development / Database)
File: jsonb-build-array.md

title: jsonbbuildarray() and jsonbuildarray() headerTitle: jsonbbuildarray() and jsonbuildarray() linkTitle: jsonbbuildarray() description: Build a JSON array from a variadic list of array values of arbitrary SQL data type. menu: v2.18: identifier: jsonbbuildarray-each parent: json-functions-operators weight: 110 type: docs Purpose: Create a JSON array from a variadic list of array values of arbitrary SQL data type. Signature For the `jsonb` variant: ``` input value: VARIADIC "any" return value: jsonb ``` Notes: Each function in this pair takes an arbitrary number of actual arguments of mixed SQL data types. The data type of each argument must have a direct JSON equivalent or allow implicit conversion to such an equivalent. Use this `ysqlsh` script to create the required type "t" and then to execute the `ASSERT`. ```plpgsql create type t as (a int, b text); do $body$ declare v_17 constant int := 17; v_dog constant text := 'dog'; v_true constant boolean := true; v_t constant t := (17::int, 'cat'::text); j constant jsonb := jsonbbuildarray(v17, vdog, vtrue, vt); expected_j constant jsonb := '[17, "dog", true, {"a": 17, "b": "cat"}]'; begin assert j = expected_j, 'unexpected'; end; $body$; ``` Using `jsonbbuildarray()` is straightforward when you know the structure of your target JSON value statically, and just discover the values dynamically. However, it doesn't accommodate the case that you discover the desired structure dynamically. The following `ysqlsh` script shows a feasible general workaround for this use case. The helper function "f()" generates the variadic argument list as the text representation of a comma-separated list of SQL literals of various data types. Then it invokes `jsonbbuildarray()` dynamically. Obviously this brings a performance cost. But you might not have an alternative. ```plpgsql create function f(variadicarrayelements in text) returns jsonb language plpgsql as $body$ declare stmt text := ' select jsonbbuildarray('||variadicarrayelements||')'; j jsonb; begin execute stmt into j; return j; end; $body$; -- Relies on "type t as (a int, b text)" created above. do $body$ declare v_17 constant int := 17; v_dog constant text := 'dog'; v_true constant boolean := true; v_t constant t := (17::int, 'cat'::text); expectedj constant jsonb := jsonbbuildarray(v17, vdog, vtrue, v_t); j constant jsonb := f( $$ 17::integer, 'dog'::text, true::boolean, (17::int, 'cat'::text)::t $$ ); begin assert j = expected_j, 'unexpected'; end; $body$; ```
Project: ClickHouse (App Definition and Development / Database)
File: v21.7.6.39-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : ParallelFormattingOutputFormat: Use mutex to handle the join to the collector_thread (https://github.com/ClickHouse/ClickHouse/issues/26694). (). Backported in : Do not remove data on ReplicatedMergeTree table shutdown to avoid creating data to metadata inconsistency. (). Backported in : Aggregate function parameters might be lost when applying some combinators causing exceptions like `Conversion from AggregateFunction(topKArray, Array(String)) to AggregateFunction(topKArray(10), Array(String)) is not supported`. It's fixed. Fixes and . (). Backported in : Fix error `Missing columns: 'xxx'` when `DEFAULT` column references other non materialized column without `DEFAULT` expression. Fixes . (). Backported in : Fix reading of custom TLDs (stops processing with lower buffer or bigger file). (). Backported in : Now partition ID in queries like `ALTER TABLE ... PARTITION ID xxx` validates for correctness. Fixes . (). Backported in : (). Backported in : Fixed `cache`, `complexkeycache`, `ssdcache`, `complexkeyssdcache` configuration parsing. Options `allowreadexpiredkeys`, `maxupdatequeuesize`, `updatequeuepushtimeoutmilliseconds`, `querywaittimeout_milliseconds` were not parsed for dictionaries with non `cache` type. (). Backported in : Fix synchronization in GRPCServer This PR fixes . (). Backported in : In rare cases `system.detached_parts` table might contain incorrect information for some parts, it's fixed. Fixes . (). library bridge fixes ().
Project: FOSSA (Provisioning / Security & Compliance)
File: test.md

The test command checks whether the most-recent scan of your FOSSA project raised license-policy or vulnerability issues. This command is usually run immediately after `fossa analyze` If there are issues, it prints them to stdout and fails with an exit code of 1 If there are no issues, it prints nothing and succeeds with an exit code of 0 `fossa test` supports the supported by all commands By default, `fossa test` waits a maximum of 3600 seconds (1 hour) for issue scan results. To override the default timeout, use, e.g.: ```sh fossa test --timeout 60 ``` Where `60` is the maximum number of seconds to wait for issue scan results. By default, `fossa test` displays issues in a human-readable format. To instead print issues as JSON, use: ```sh fossa test --format json ``` `--diff <REVISION>` configures FOSSA to only report new issues observed with the current revision that weren't already reported on the specified `<REVISION>`. ```sh fossa test --diff revisionToCompare ``` ```sh fossa test --revision 34021e --diff v2.0.0 ``` This only reports issues that are present in `34021e` revision, BUT are not present in revision `v2.0.0`. For instance, If the revision `v2.0.0` has issue: `A`, and the revision `34021e` has issue `A`, `fossa-cli` reports no new issues discovered and exits with status code of 0. If the revision `v2.0.0` has issue: `A`, and the revision `34021e` has 0 issues, `fossa-cli` reports no new issues discovered and exits with status code of 0. If the revision `v2.0.0` has issue: `A`, and the revision `34021e` has issues `A`, `B`, `fossa-cli` reports issue `B` and exits with status code of 1.