cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.0.20.204.0.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Major | Batch the calls in DataStorage to FileUtil.createHardLink(), so we call it once per directory instead of once per file* Batch hardlinking during "upgrade" snapshots, cutting time from aprx 8 minutes per volume to aprx 8 seconds. Validated in both Linux and Windows. Depends on prior integration with patch for HADOOP-7133. | Major | Backport MAPREDUCE-1568 to hadoop security branch* Added mapreduce.tasktracker.distributedcache.checkperiod to the task tracker that defined the period to wait while cleaning up the distributed cache. The default is 1 min. | Major | Create an rpm integration project* Added RPM/DEB packages to build system. | Minor | Backport trunk heuristics for failing maps when we get fetch failures retrieving map output during shuffle* Added a new configuration option: mapreduce.reduce.shuffle.maxfetchfailures, and removed a no longer used option: mapred.reduce.copy.backoff. | Major | Recognize Jetty bug 1342 and handle it* Added 2 new config parameters: mapreduce.reduce.shuffle.catch.exception.stack.regex mapreduce.reduce.shuffle.catch.exception.message.regex | Blocker | Disable TestHdfsProxy.testHdfsProxyInterface in 0.20-security and branch-1 until HDFS-2217 is fixed* Test case TestHdfsProxy.testHdfsProxyInterface has been temporarily disabled for this release, due to failure in the Hudson automated test environment. | Blocker | a small % of all tasks fail with DefaultTaskController* Fixed a race condition in writing the log index file that caused tasks to 'fail'. | Blocker | "Creation of symlink to attempt log dir failed." message is not useful* Removed duplicate chmods of job log dir that were vulnerable to race conditions between tasks. Also improved the messages when the symlinks failed to be created.
Project: KICS (Provisioning / Security & Compliance)
File: c1032cf7-3628-44e2-bd53-38c17cf31b6b.md

title: Shared Service Account hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: c1032cf7-3628-44e2-bd53-38c17cf31b6b Query name: Shared Service Account Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Secret Management URL: A Service Account token is shared between workloads<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="16 6" apiVersion: v1 kind: Pod metadata: name: pod1 spec: serviceAccountName : service1 containers: name: mycontainer image: redis apiVersion: v1 kind: Pod metadata: name: pod2 spec: serviceAccountName : service1 containers: name: envars-test-container image: nginx ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: pod1 spec: serviceAccountName : service1 containers: name: mycontainer image: redis apiVersion: v1 kind: Pod metadata: name: pod2 spec: serviceAccountName : service2 containers: name: envars-test-container image: nginx ```
Project: ArangoDB (App Definition and Development / Database)
File: unchecked.md

+++ title = "`unchecked<T, E = varies>`" description = "A type alias to a `stdunchecked<T, E>` (standalone edition) or `boostunchecked<T, E>` (Boost edition)." +++ A type alias to either {{% api "stdunchecked<T, E = std::errorcode>" %}} (standalone edition) or {{% api "boostunchecked<T, E = boost::system::errorcode>" %}} (Boost edition). This means that `unchecked<T>` uses the appropriate default alias depending on which edition of Outcome is in use. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/result.hpp>`
Project: Harbor (Provisioning / Container Registry)
File: 1-10-admin-update-account-settings.md

Test 1-10 - Admin User update account settings (DB Mode) ======= To verify that the admin user can update his/her account settings. User guide This test requires that a Harbor instance is running and available. Harbor is set to authenticate against a local database. ( auth_mode is set to db_auth* .) The user data is stored in a local database. A linux host with Docker CLI installed (Docker client). The admin user logs in to UI. The user changes his/her account settings, including email, full name and comments. The user logs out. The admin user logs in again using new email, and verify the account settings had been changed. Account settings can be changed in Step 2. User can log in using new email in Step 4 and the settings are the same as input in Step 2. None
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.0-rc-5f.md

layout: release date: 2022-03-22 tag: v0.6.0-rc-5f language: en Style the version component @AbhishekJamhoriya (#5054) Thank you to our contributors for making this release possible: @AbhishekJamhoriya and @leecalcote
Project: Meshery (Provisioning / Automation & Configuration)
File: open-service-mesh.md

layout: integration title: Open Service Mesh subtitle: Access all that Open Service Mesh has to offer image: /assets/img/integrations/open-service-mesh/icons/color/open-service-mesh-color.svg permalink: extensibility/integrations/open-service-mesh docURL: https://docs.meshery.io/extensibility/adapters/osm description: integrations-category: Cloud Native Network integrations-subcategory: Service Mesh registrant: Artifact Hub components: featureList: [ "Configuration an simplier understanding of your Open Service Mesh deployments and microservices", "Configure and chain Envoy WASM filters", "Conformance to Service Mesh Interface specifications" ] 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: OpenYurt (Provisioning / Automation & Configuration)
File: RELEASES.md

This document describes how OpenYurt handles versioning, releases new versions and communicates about them. OpenYurt uses semantic versioning so that their users can reliably upgrade according to their needs. OpenYurt is using a release schedule of 2 to 3 months and uses to provide an indication of when the next release is planned. It can, however, happen that releases get delayed which will be reflected on the milestone. You can learn about our release process . We provide a changelog that includes every change per version must be available as part of the repo, for example, here is the . Next to that, every closed issue and PR should be added to a GitHub Milestone that provides an overview of everything that will be included and provide an indication of what the current intended release date is. However, the release date is subject to change and only provides an indication. Lastly, every new release will come with a GitHub Release which provides the exact changelog for that release. If you want to be notified of new releases, we recommend our on GitHub and ensure you are subscribing for releases. Next to that, you can join the conversation for every new release on GitHub Discussions. Community - () DingTalkSearch GroupID 31993519 or GroupID 12640034121 (Chinese)
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: openfaas-function-authorization.md

title: OpenFaaS Serverless Function Authorization labels: layer: application category: serverless software: openfaas code: https://github.com/adaptant-labs/openfaas-function-auth-opa tutorials: https://github.com/adaptant-labs/openfaas-function-auth-opa/blob/master/README.md inventors: adaptant OpenFaaS is a serverless function framework that runs on Docker Swarm and Kubernetes. OPA makes it possible to provide fine-grained context-aware authorization on a per-function basis.
Project: BigchainDB (App Definition and Development / Database)
File: log-rotation.md

<! Copyright 2020 Interplanetary Database Association e.V., BigchainDB and IPDB software contributors. SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0) Code is Apache-2.0 and docs are CC-BY-4.0 > Each BigchainDB node runs: MongoDB BigchainDB Server Tendermint When running a BigchainDB node for long periods of time, we need to consider doing log rotation, i.e. we do not want the logs taking up large amounts of storage and making the node unresponsive or getting it into a bad state. See the MongoDB docs about and . BigchainDB Server writes its logs to two files: normal logs and error logs. The names of those files, and their locations, are set as part of the BigchainDB configuration settings. The default names and locations are: `~/bigchaindb.log` `~/bigchaindb-errors.log` Log rotation is baked into BigchainDB Server using Python's `logging` module. The logs for BigchainDB Server are rotated when any of the above mentioned files exceeds 209715200 bytes (i.e. approximately 209 MB). For more information, see the docs about . Tendermint writes its logs to the files: `tendermint.out.log` `tendermint.err.log` If you started BigchainDB Server and Tendermint using Monit, as suggested by our guide on , then the logs will be written to `$HOME/.bigchaindb-monit/logs/`. Moreover, if you started BigchainDB Server and Tendermint using Monit, then Monit monitors the Tendermint log files. Tendermint logs are rotated if any of the above mentioned log files exceeds 200 MB.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: sysctl.md

Configure namespaced kernel parameters <<at runtime|for all containers in the pod>>. For the IPC namespace, the following sysctls are allowed: kernel.msgmax kernel.msgmnb kernel.msgmni kernel.sem kernel.shmall kernel.shmmax kernel.shmmni kernel.shmrmidforced Sysctls beginning with fs.mqueue.\* Note: <<if using the --ipc=host option|if the ipc namespace is not shared within the pod>>, the above sysctls are not allowed. For the network namespace, only sysctls beginning with net.\* are allowed. Note: <<if using the --network=host option|if the network namespace is not shared within the pod>>, the above sysctls are not allowed.
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: RELEASE_PROCESS.md

Update version in all Cargo.toml files in the repository ./Cargo.toml ./tremor-api/Cargo.toml ./tremor-cli/Cargo.toml ./tremor-common/Cargo.toml ./tremor-influx/Cargo.toml (if we have changes compared to the previous release) ./tremor-pipeline/Cargo.toml ./tremor-script/Cargo.toml (don't forget the reference to the other tremor packages) ./tremor-value/Cargo.toml (if we have changes compared to the previous release) Update version in `./tremor-cli/src/cli.yaml` (minor version update only) Update version in `Dockerfile.learn` Update CHANGELOG.md Change unreleased section to have the new version for the upcoming release Update tests in tremor-cli/tests/ that match against the current version number ./tremor-cli/tests/api/command.yml (the version test) ./tremor-cli/tests/api-cli/command.yml (the version test) run `cargo test --all` (this will ensure the Cargo.lock is up to date) enter the sub crate directories and run `cargo test` in each one (this is important to make sure they compile stand alone!) `./tremor-common` `./tremor-value` `./tremor-script` Create a PR with those changes Pull the PR once accepted and merged `git tag -a -m"Release v<MAJOR>.<MINOR>.<BUGFIX>" v<MAJOR>.<MINOR>.<BUGFIX> <COMMIT>` `git push origin --tag` Draft a new release on github This will trigger the docker image build jobs Add a catchy title Add the relevant changelog entries for this release in the description Release crates to crates.io: Make sure you are an owner of the crates to publish Execute `cargo publish` in these folders in the following order: ./tremor-common ./tremor-value ./tremor-script Wait for the docker image to build and publish Verify docker image with some usage examples Tag the published dockerhub image as latest: ```sh export VERSION=<version> docker rmi --force tremorproject/tremor:$VERSION && \ docker pull tremorproject/tremor:$VERSION && \ docker tag tremorproject/tremor:$VERSION tremorproject/tremor:latest && \ docker push tremorproject/tremor:latest ``` Create a corresponding release on tremor-www-docs. See Release https://github.com/tremor-rs/tremor-language-server Bump version and update dependency `tremor-script` to the new version. Checkout the new tremor-www-docs release tag in the `tremor-www-docs` submodule. Create a github tag and draft a release from it: `git tag -a -m"Release v<MAJOR>.<MINOR>.<BUGFIX>" v<MAJOR>.<MINOR>.<BUGFIX> <COMMIT>` `git push origin --tag` Execute `cargo publish` from the language server repository root. Verify new language server installation via `cargo install tremor-language-server` If syntax changed: Update the highlighters: https://github.com/tremor-rs/tremor-vim https://github.com/tremor-rs/highlightjs-tremor https://github.com/tremor-rs/tremor-mkdocs-lexer https://github.com/tremor-rs/tremor-vscode Go to bed. Any or all of the following (whichever makes sense) Tremor Discord (announcements channel) Tremor Twitter CNCF Slack Tremor channel Tremor Blog
Project: StarRocks (App Definition and Development / Database)
File: seconds_add.md

displayed_sidebar: "English" ```Haskell DATETIME SECONDS_ADD(DATETIME expr1,INT expr2) ``` Add a specified time interval to the date. Unit is second. The expr1 parameter is a valid datetime expression. The expr2 parameter is the seconds you want to add. ```Plain Text select seconds_add('2010-11-30 23:50:50', 2); ++ | seconds_add('2010-11-30 23:50:50', 2) | ++ | 2010-11-30 23:50:52 | ++ select seconds_add('2010-11-30', 2); ++ | seconds_add('2010-11-30', 2) | ++ | 2010-11-30 00:00:02 | ++ ``` SECONDS_ADD,ADD
Project: ArangoDB (App Definition and Development / Database)
File: assume_exception_lvalue_const.md

+++ title = "`const exceptiontype &assumeexception() const & noexcept`" description = "Narrow contract const lvalue reference observer of the stored exception. Constexpr propagating, never throws." categories = ["observers"] weight = 781 +++ Narrow contract const lvalue reference observer of the stored exception. `NoValuePolicy::narrowexceptioncheck()` is first invoked, then the reference to the exception is returned. As a valid default constructed exception is always present, no undefined behaviour occurs unless `NoValuePolicy::narrowexceptioncheck()` does that. Note that if `exception_type` is `void`, only a `const` overload returning `void` is present. Requires: Always available. Complexity: Depends on `NoValuePolicy::narrowexceptioncheck()`. Guarantees: An exception is never thrown.
Project: YugabyteDB (App Definition and Development / Database)
File: managed-cli-backup-policy.md

title: ybm CLI backup policy resource headerTitle: ybm backup policy linkTitle: backup policy description: YugabyteDB Managed CLI reference backup policy resource. headcontent: Manage cluster backup policies menu: preview_yugabyte-cloud: identifier: managed-cli-backup-policy parent: managed-cli-reference weight: 20 type: docs Use the `backup policy` resource to change the cluster backup policy, including the following: update the cluster backup policy enable and disable the backup policy display the cluster backup policy The default policy for clusters is to back up every day with 8-day retention. ```text Usage: ybm backup policy [command] [flags] ``` Modify the cluster backup policy: ```sh ybm backup policy update \ --cluster-name=test-cluster \ --full-backup-frequency-in-days=2 \ --retention-period-in-days=14 ``` Disable the backup policy for a specified cluster. | Flag | Description | | : | : | | --cluster-name | Required. Name of the cluster to disable the backup policy for. | Enable the backup policy for a specified cluster. | Flag | Description | | : | : | | --cluster-name | Required. Name of the cluster to enable the backup policy for. | Display the backup policy of a specified cluster. | Flag | Description | | : | : | | --cluster-name | Required. Name of the cluster whose policy you want to view. | Update the backup policy of a specified cluster. | Flag | Description | | : | : | | --cluster-name | Required. Name of the cluster to update the backup policy for. | | --full-backup-frequency-in-days | Frequency of full backup in days. Default is 1. | | --full-backup-schedule-days-of-week | Days of the week to run backups. Specify a comma-separated list of the first two letters of the days. For example, MO,WE,SA. | | --full-backup-schedule-time | Time of day to run backups. Specify local time in 24 hr HH:MM format. For example, 15:04. | | --incremental-backup-frequency-in-minutes | Frequency of incremental backups in minutes. Default is 60. | | --retention-period-in-days | Required. Retention period for the backup in days. Default is 1. |
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: release.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: StarRocks (App Definition and Development / Database)
File: json_exists.md

displayed_sidebar: "English" Checks whether a JSON object contains an element that can be located by the `jsonpath` expression. If the element exists, the JSONEXISTS function returns `1`. Otherwise, the JSON_EXISTS function returns `0`. ```Haskell jsonexists(jsonobjectexpr, jsonpath) ``` `jsonobjectexpr`: the expression that represents the JSON object. The object can be a JSON column, or a JSON object that is produced by a JSON constructor function such as PARSE_JSON. `json_path`: the expression that represents the path to an element in the JSON object. The value of this parameter is a string. For more information about the JSON path syntax that is supported by StarRocks, see . Returns a BOOLEAN value. Example 1: Check whether the specified JSON object contains an element that can be located by the `'$.a.b'` expression. In this example, the element exists in the JSON object. Therefore, the json_exists function returns `1`. ```plaintext mysql> SELECT jsonexists(PARSEJSON('{"a": {"b": 1}}'), '$.a.b') ; -> 1 ``` Example 2: Check whether the specified JSON object contains an element that can be located by the `'$.a.c'` expression. In this example, the element does not exist in the JSON object. Therefore, the json_exists function returns `0`. ```plaintext mysql> SELECT jsonexists(PARSEJSON('{"a": {"b": 1}}'), '$.a.c') ; -> 0 ``` Example 3: Check whether the specified JSON object contains an element that can be located by the `'$.a[2]'` expression. In this example, the JSON object, which is an array named a, contains an element at index 2. Therefore, the json_exists function returns `1`. ```plaintext mysql> SELECT jsonexists(PARSEJSON('{"a": [1,2,3]}'), '$.a[2]') ; -> 1 ``` Example 4: Check whether the specified JSON object contains an element that can be located by the `'$.a[3]'` expression. In this example, the JSON object, which is an array named a, does not contain an element at index 3. Therefore, the json_exists function returns `0`. ```plaintext mysql> SELECT jsonexists(PARSEJSON('{"a": [1,2,3]}'), '$.a[3]') ; -> 0 ```
Project: Tinkerbell (Provisioning / Automation & Configuration)
File: README.md

](https://github.com/tinkerbell/tink/actions/workflows/ci.yaml) ](https://codecov.io/gh/tinkerbell/tink) ](https://bestpractices.coreinfrastructure.org/projects/4512) Tinkerbell is licensed under the Apache License, Version 2.0. See for the full license text. Some of the projects used by the Tinkerbell project may be governed by a different license, please refer to its specific license. Tinkerbell is part of the CNCF Projects. ](https://landscape.cncf.io/?item=provisioning--automation-configuration--tinkerbell) The Tinkerbell community meets bi-weekly on Tuesday. The meeting details can be found . Community Resources: The Tinkerbell stack consists of several microservices, and a gRPC API: is the short-hand name for the tink-server and tink-worker. `tink-worker` and `tink-server` communicate over gRPC, and are responsible for processing workflows. The CLI is the user-interactive piece for creating workflows and their building blocks, templates and hardware data. is Tinkerbell's DHCP server. It handles DHCP requests, hands out IPs, and serves up iPXE. It uses the Tinkerbell client to pull and push hardware data. It only responds to a predefined set of MAC addresses so it can be deployed in an existing network without interfering with existing DHCP infrastructure. is the metadata service used by Tinkerbell and OSIE. It collects data from both and transforms it into a JSON format to be consumed as metadata. is Tinkerbell's default an in-memory installation environment for bare metal. It installs operating systems and handles deprovisioning. is the newly introduced alternative to OSIE. It's the next iteration of the in-memory installation environment to handle operating system installation and deprovisioning. is an optional microservice that can communicate with baseboard management controllers (BMCs) to control power and boot settings. Use `make help`. The most interesting targets are `make all` (or just `make`) and `make images`. `make all` builds all the binaries for your host OS and CPU to enable running directly. `make images` will build all the binaries for Linux/x86_64 and build docker images with them. Rather than adding a bunch of command line options or a config file, OpenTelemetry is configured via environment variables. The most relevant ones are below, for others see https://github.com/equinix-labs/otel-init-go Currently this is just for tracing, metrics needs to be discussed with the community. | Env Variable | Required | Default | | -- | -- | | | `OTELEXPORTEROTLP_ENDPOINT` | n | localhost | | `OTELEXPORTEROTLP_INSECURE` | n | false | | `OTELLOGLEVEL` | n | info | To work with a local , try the following. For examples of how to set up the collector to relay to various services take a look at ``` export OTELEXPORTEROTLP_ENDPOINT=localhost:4317 export OTELEXPORTEROTLP_INSECURE=true ./cmd/tink-server/tink-server <stuff> ``` For complete documentation, please visit the Tinkerbell project hosted at .