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

Vitess Components currently disallow changing of configuration parameters while a process is running. There are a few reasons why this was not allowed: The command line used to launch the process will cease to be an authoritative source. It is difficult to audit any values that were changed in real-time or keep track of history if changes were made multiple times. If a process is restarted for any reason, the changes will be reverted. However, if there is an ongoing high severity incident, it may be beneficial to allow human operators to make temporary changes to a system. This, of course, comes with the caveat that they will eventually revert the changes or make them permanent by deploying the binaries with the new flags. Given that this should be generally discouraged as common practice, these capabilities should not be made openly available. For example, you should not be able to make such changes using SQL statements. Well export a `/debug/env` endpoint from vttablet, protected by `ADMIN` access. The URL will display the current values of the various parameters and will allow you to modify and submit any of those. Values like connection pool sizes, query timeouts, query consolidation settings, etc. will be changeable. Well iterate on this list as more use cases arise. The initial list will be in an upcoming PR. SET Statements: These would be issued via VTGate. The problem with this approach is that the commands would be too widely available. Also, VTGate doesnt allow targeting of specific tablets. vtctld ExecuteFetchAsDba SET statements: This could be made to work. However, this is currently implemented as a pass-through in tablet manager. Significant changes will be needed to parse the statements and make them do other things. vtcltd alternate command, like `SetTabletEnv`: This could be made to work. However, it is a lot more work than what is proposed, and may not be worth it for a feature that is meant to be used so rarely. We still have the option of implementing this if the need arises in the future.
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: linux-pam.md

title: SSH and Sudo Authorization with Linux software: linuxpam labels: layer: server tutorials: https://www.openpolicyagent.org/docs/ssh-and-sudo-authorization.html code: https://github.com/open-policy-agent/contrib/tree/master/pam_opa inventors: styra Host-level access controls are an important part of every organization's security strategy. OPA provides fine-grained, context-aware controls for SSH and sudo using Linux-PAM.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: v1.14.0.md

title: v1.14.0 weight: 998986000 Note that to ensure the backwards compatibility SDK tool will try to downgrade the versions used if you need to still scaffold the v1beta1 for CRDs and Webhooks to publish your solutions into older cluster versions. However, note that this version is no longer supported in Kubernetes 1.22+, `sigs.k8s.io/controller-runtime v0.10.0` or `controller-gen v0.7.0`. Following are the changes to be addressed in your `Makefile` and `go.mod` file if you are not using the `v1beta1` K8s APIs which are no longer supported from k8s `1.22` version. 1) Update your `go.mod` file to upgrade the dependencies and run `go mod tidy` to download then ``` k8s.io/api v0.22.1 k8s.io/apimachinery v0.22.1 k8s.io/client-go v0.22.1 sigs.k8s.io/controller-runtime v0.10.0 ``` 2) Update your Makefile by making the following replacements: ```diff ENVTESTK8SVERSION = 1.21 ENVTESTK8SVERSION = 1.22 ``` ```diff $(CONTROLLERGEN) $(CRDOPTIONS) rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases $(CONTROLLER_GEN) rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases ``` 3) Remove from the `Makefile` the `CRD_OPTIONS`, see below: ``` CRD_OPTIONS ?= "crd:trivialVersions=true,preserveUnknownFields=false" ``` 4) Replace your `admissionReviewVersions={v1,v1beta1}` markers with `admissionReviewVersions=v1` 5) Run `make manifest` to re-generate your manifests with latest versions. See for more details. Add the ``kubernetes.core`` collection (>= 2.2.0) to the requrements.yml file name: kubernetes.core version: "2.2.0" See for more details.
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: sidecar-containers.md

Additional "" containers can be provided for `udf` and `sink` vertices. `source` vertices do not currently support sidecars. The following example shows how to add a sidecar container to a `udf` vertex. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: vertices: name: my-udf sidecars: name: my-sidecar image: busybox:latest command: ["/bin/sh", "-c", "echo \"my-sidecar is running!\" && tail -f /dev/null"] udf: container: image: my-function:latest ``` There are various use-cases for sidecars. One possible use-case is a `udf` container that needs functionality from a library written in a different language. The library's functionality could be made available through gRPC over Unix Domain Socket. The following example shows how that could be accomplished using a shared . It is the sidecar owner's responsibility to come up with a protocol that can be used with the UDF. It could be volume, gRPC, TCP, HTTP 1.x, etc., ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: vertices: name: my-udf-vertex volumes: name: my-udf-volume emptyDir: medium: Memory sidecars: name: my-sidecar image: alpine:latest command: ["/bin/sh", "-c", "apk add socat && socat UNIX-LISTEN:/path/to/my-sidecar-mount-path/my.sock - && tail -f /dev/null"] volumeMounts: mountPath: /path/to/my-sidecar-mount-path name: my-udf-volume udf: container: image: alpine:latest command: ["/bin/sh", "-c", "apk add socat && echo \"hello\" | socat UNIX-CONNECT:/path/to/my-udf-mount-path/my.sock,forever - && tail -f /dev/null"] volumeMounts: mountPath: /path/to/my-udf-mount-path name: my-udf-volume ```
Project: SPIRE (Provisioning / Key Management)
File: plugin_agent_nodeattestor_jointoken.md

Must be used in conjunction with the server-side join_token plugin The `join_token` is responsible for attesting the agent's identity using a one-time-use pre-shared key. As a special case for node attestors, the join token itself is configured by a CLI flag (`-joinToken`) or by configuring `join_token` in the agent's main config body.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.5.4.md

layout: release date: 2021-04-29 tag: v0.5.4 API endpoints for WASM filter CRUD @navendu-pottekkat (#2748) Fix Release Notes Publisher CI workflow @ramrodo (#2769) [CI] - Fixes code-ql analysis workflow @adithyaakrishna (#2759) [Meshery] - Fixed Provider UI Dropdown Issue @adithyaakrishna (#2764)
Project: ko (App Definition and Development / Application Definition & Image Build)
File: ko_run.md

A variant of `kubectl run` that containerizes IMPORTPATH first. This sub-command combines "ko build" and "kubectl run" to support containerizing and running Go binaries on Kubernetes in a single command. ``` ko run IMPORTPATH [flags] ``` ``` ko run github.com/foo/bar/cmd/baz ko run ./cmd/baz ko run ./cmd/baz -- -v arg1 arg2 --yes ``` ``` --bare Whether to just use KODOCKERREPO without additional context (may not work properly with --tags). -B, --base-import-paths Whether to use the base path without MD5 hash after KODOCKERREPO (may not work properly with --tags). --disable-optimizations Disable optimizations when building Go code. Useful when you want to interactively debug the created container. -h, --help help for run --image-label strings Which labels (key=value) to add to the image. --image-refs string Path to file where a list of the published image references will be written. --insecure-registry Whether to skip TLS verification on the registry -j, --jobs int The maximum number of concurrent builds (default GOMAXPROCS) -L, --local Load into images to local docker daemon. --oci-layout-path string Path to save the OCI image layout of the built images --platform strings Which platform to use when pulling a multi-platform base. Format: all | <os>* -P, --preserve-import-paths Whether to preserve the full import path after KODOCKERREPO. --push Push images to KODOCKERREPO (default true) --sbom string The SBOM media type to use (none will disable SBOM synthesis and upload, also supports: spdx, cyclonedx, go.version-m). (default "spdx") --sbom-dir string Path to file where the SBOM will be written. --tag-only Include tags but not digests in resolved image references. Useful when digests are not preserved when images are repopulated. -t, --tags strings Which tags to use for the produced image instead of the default 'latest' tag (may not work properly with --base-import-paths or --bare). (default [latest]) --tarball string File to save images tarballs ``` ``` -v, --verbose Enable debug logs ``` - Rapidly iterate with Go, Containers, and Kubernetes.
Project: Meshery (Provisioning / Automation & Configuration)
File: osm.md

layout: default title: Meshery Adapter for Open Service Mesh name: Meshery Adapter for Open Service Mesh component: Open Service Mesh port: 10009/gRPC project_status: archived lab: osm-meshery-adapter github_link: https://github.com/meshery/meshery-osm image: /assets/img/service-meshes/osm.svg white_image: /assets/img/service-meshes/osm.svg permalink: extensibility/adapters/osm redirect_from: service-meshes/adapters/osm earliest_version: v0.9.2 language: en {% assign sortedtestsgroup = site.compatibility | group_by: "meshery-component" %} {% for group in sortedtestsgroup %} {% if group.name == "meshery-osm" %} {% assign items = group.items | sort: "meshery-component-version" | reverse %} {% for item in items %} {% if item.meshery-component-version != "edge" %} {% if item.overall-status == "passing" %} {% assign adapterversiondynamic = item.meshery-component-version %} {% break %} {% elsif item.overall-status == "failing" %} {% continue %} {% endif %} {% endif %} {% endfor %} {% endif %} {% endfor %} {% include compatibility/adapter-status.html %} <!-- {% include adapter-labs.html %} --> The {{page.name}} can install {{page.earliest_version}} of the {{page.component}}. Sample applications for {{page.component}} can also be installed using Meshery. Using the {{page.name}}, you may also run the complete suite of Service Mesh Interface (SMI) conformance tests to validate OSMs compliance with the SMI specification. Choose the Meshery Adapter for {{ page.component }}. <a href="{{ site.baseurl }}/assets/img/adapters/osm/osm-adapter.png"> <img style="width:500px;" src="{{ site.baseurl }}/assets/img/adapters/osm/osm-adapter.png" /> </a> Click on (+) and choose the `{{page.earliest_version}}` of the {{page.component}}. <a href="{{ site.baseurl }}/assets/img/adapters/osm/osm-install.png"> <img style="width:500px;" src="{{ site.baseurl }}/assets/img/adapters/osm/osm-install.png" /> </a> Meshery allows you to analyze the compliance status and functional capabilities of your service mesh. This allows you to compare high-level functional differences between service meshes and verify whether your service mesh is conformant with the SMI specification. Learn more about the SMI specification and . The {{page.name}} will connect to Open Service Mesh's Prometheus and Grafana instances running in the control plane (typically found in the `osm-system` namespace). You can also connect Meshery to Prometheus and Grafana instances not running in the service mesh's control plane. The {{ page.name }} does not support Sample Applications yet. Examine and how adapters fit in as a component. Learn more about .
Project: Beam (App Definition and Development / Streaming & Messaging)
File: beam-2.7.0.md

title: "Apache Beam 2.7.0" date: 2018-10-03 00:00:01 -0800 categories: blog release aliases: /blog/2018/10/03/beam-2.7.0.html authors: ccy <!-- 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. --> We are happy to present the new 2.7.0 release of Beam. This release includes both improvements and new functionality. See the for this release.<!--more--> For more information on changes in 2.7.0, check out the . KuduIO Amazon SNS sink Amazon SqsIO Apache Calcite dependency upgraded to 1.17.0 Apache Derby dependency upgraded to 10.14.2.0 Apache HTTP components upgraded (see release notes). Experimental support for Python on local Flink runner for simple examples, see latest information . KinesisIO, fixed dependency issue According to git shortlog, the following 72 people contributed to the 2.7.0 release. Thank you to all contributors! Ahmet Altay, Alan Myrvold, Alexey Romanenko, Aljoscha Krettek, Andrew Pilloud, Ankit Jhalaria, Ankur Goenka, Anton Kedin, Boyuan Zhang, Carl McGraw, Carlos Alonso, cclauss, Chamikara Jayalath, Charles Chen, Cory Brzycki, Daniel Oliveira, Dariusz Aniszewski, devinduan, Eric Beach, Etienne Chauchot, Eugene Kirpichov, Garrett Jones, Gene Peters, Gleb Kanterov, Henning Rohde, Henry Suryawirawan, Holden Karau, Huygaa Batsaikhan, Ismal Meja, Jason Kuster, Jean- Baptiste Onofr, Joachim van der Herten, Jozef Vilcek, jxlewis, Kai Jiang, Katarzyna Kucharczyk, Kenn Knowles, Krzysztof Trubalski, Kyle Winkelman, Leen Toelen, Luis Enrique Ortz Ramirez, Lukasz Cwik, ukasz Gajowy, Luke Cwik, Mark Liu, Matthias Feys, Maximilian Michels, Melissa Pashniak, Mikhail Gryzykhin, Mikhail Sokolov, mingmxu, Norbert Chen, Pablo Estrada, Prateek Chanda, Raghu Angadi, Ravi Pathak, Reuven Lax, Robert Bradshaw, Robert Burke, Rui Wang, Ryan Williams, Sindy Li, Thomas Weise, Tim Robertson, Tormod Haavi, Udi Meiri, Vaclav Plajt, Valentyn Tymofieiev, xiliu, XuMingmin, Yifan Zou, Yueyang Qiu.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_organization_policy.md

+++ title = "googleorganizationpolicy resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleorganizationpolicy" identifier = "inspec/resources/gcp/googleorganizationpolicy.md googleorganizationpolicy resource" parent = "inspec/resources/gcp" +++ Use the `googleorganizationpolicy` InSpec audit resource to test constraints set on a GCP organization. Google organization policies can restrict certain GCP services. For more information see https://cloud.google.com/resource-manager/docs/organization-policy/understanding-constraints A `googleorganizationpolicy` resource block declares the tests for a single GCP organization constraint identified by the pair of the `name` of the organization and the `constraint`: describe googleorganizationpolicy(name: 'organizations/123456', constraint: 'constraints/compute.disableGuestAttributesAccess') do it { should exist } its('boolean_policy.enforced') { should be true } end The following examples show how to use this InSpec audit resource. describe googleorganizationpolicy(name: 'organizations/123456', constraint: 'constraints/compute.disableGuestAttributesAccess') do it { should exist } its('boolean_policy.enforced') { should be true } end describe googleorganizationpolicy(name: 'organizations/123456', constraint: 'constraints/someListConstraint') do it { should exist } its('listpolicy.allowedvalues') { should include 'included_val' } its('listpolicy.allowedvalues') { should_not include 'excluded' } its('listpolicy.deniedvalues') { should include 'denied' } end `update_time` : The time stamp this policy was last updated. `boolean_policy` : Only available for constraints that are boolean policies. `enforced` : Boolean for if this policy is enforced. `list_policy` : Available for list policies. `allowed_values` : List of values allowed at this resource. `denied_values` : List of values denied at this resource. Ensure the is enabled for the project.
Project: Meshery (Provisioning / Automation & Configuration)
File: 11-02-2023-23-48-11_2a9823d3.md

timestamp: "2023-11-02 23:47:58 UTC Thu" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "*name" k8s-distro: minikube k8s-version: "v1.21.5" service-mesh: Consul service-mesh-version: "v1.2.3" tests: consul-client: null consul-server: null overall-status: "failing"
Project: YDB (App Definition and Development / Database)
File: column-oriented.md

Unlike row-oriented {{ ydb-short-name }} tables, you can't partition column-oriented tables by primary keys but only by specially designated partitioning keys. Inside each partition, data is distributed by the table's primary key. In this context, to ensure high performance of column-oriented {{ ydb-short-name }} tables, you need to properly select both the primary key and partitioning key. Because the partitioning key determines the partition where the data is stored, select it so that the Hash(partition_key) enables uniform distribution of data across partitions. The optimal situation is when the partitioning key includes 100 to 1,000 times more unique values than the number of partitions in the table. Keys with many unique values have high cardinality. On the other hand, keys with a few unique values have low cardinality. Using a partitioning key with low cardinality might result in uneven distribution of data across partitions, and some partitions might become overloaded. Overloading of partitions might result in suboptimal query performance and/or capping of the maximum stream of inserted data. The primary key determines how the data will be stored inside the partition. That's why, when selecting a primary key, you need to keep in mind both the effectiveness of reading data from the partition and the effectiveness of inserting data into the partition. The optimum insert use case is to write data to the beginning or end of the table, making rare local updates of previously inserted data. For example, an effective use case would be to store application logs by timestamps, adding records to the end of the partition using the current time in the primary key. {% note warning %} Currently, you need to select the primary key so that the first column in the primary key has high cardinality. An example of an effective first column is the column with the `Timestamp` type. For example, the first column is ineffective if it has the `Uint16` type and 1,000 unique values. {% endnote %} Column-oriented tables do not support automatic repartitioning at the moment. That's why it's important to specify a realistic number of partitions at table creation. You can evaluate the number of partitions you need based on the expected data amounts you are going to add to the table. The average insert throughput for a partition is 1 MB/s. The throughput is mostly affected by the selected primary keys (the need to sort data inside the partition when inserting data). We do not recommend setting up more than 128 partitions for small data streams. Example: When your data stream is 1 GB per second, an analytical table with 1,000 partitions is an optimal choice. Nevertheless, it is not advisable to create tables with an excessive number of partitions: this could raise resource consumption in the cluster and negatively impact the query rate.
Project: The Update Framework (TUF) (Provisioning / Security & Compliance)
File: GOVERNANCE.md

This document covers the project's governance and committer process. The project consists of the TUF and . The project is maintained by the people indicated in . A maintainer is expected to (1) submit and review GitHub pull requests and (2) open issues or [submit vulnerability reports](https://github.com/theupdateframework/python-tuf#security-issues-and-bugs). A maintainer has the authority to approve or reject pull requests submitted by contributors. More significant changes in the project, such as those that require a TAP or changes in governance, are guided by a maintainer called the Consensus Builder (CB). The project's Consensus Builder (CB) is Justin Cappos <jcappos@nyu.edu, @JustinCappos>, who has a lifetime appointment. [A contributor can submit GitHub pull requests](CONTRIBUTING.rst) to the project's repositories. They must follow the project's [code of conduct](CODE-OF-CONDUCT.md), the [developer certificate of origin](https://developercertificate.org/), the [code style guidelines](https://github.com/secure-systems-lab/code-style-guidelines), and must unit test any new software feature or change. Submitted pull requests undergo review and automated testing, including, but not limited to: Unit and build testing via and . Static code analysis via and . Auto-formatting with and . Checks for Signed-off-by commits via . Review by one or more . A contributor can propose changes to the specification with a [TUF Augmentation Proposal](https://github.com/theupdateframework/taps) (TAP). It is a design document providing information to the TUF community, or describing a new feature for TUF or its processes or environment. A can be approved or rejected by the CB after it has been reviewed and discussed. Discussions take place on the project's [mailing list](https://groups.google.com/forum/?fromgroups#!forum/theupdateframework) or the TAPs GitHub issue tracker. A contributor to the project must express interest in becoming a maintainer. The CB has the authority to add or remove maintainers. The CB supervises changes in governance, but a majority of maintainers must vote +1 on the PR. The consensus builder may be appointed for a fixed term or it may be a lifetime appointment. To initiate a change of consensus builder, or a change in the length of the appointment, a GitHub PR must be opened. If a fixed term is specified, the PR should be opened no earlier than 6 weeks before the end of the CB's term. If there is not a fixed term appointment, the PR may be opened at any time. In either case, the PR must be kept open for no less than 4 weeks. Additionally, the PR can only be merged with more +1 than -1 in the binding votes. Anyone from the community can vote on the PR with either +1 or -1. Only votes from maintainers that have been listed in the top-level file before the PR is opened are binding. When there are conflicting PRs about changes in the consensus builder, the PR with the most binding +1 votes is merged. The consensus builder can volunteer to step down.
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.11.2.md

RabbitMQ `3.11.2` is a maintenance release in the `3.11.x` . Please refer to the upgrade section from if upgrading from a version prior to 3.11.0. This release requires Erlang 25. has more details on Erlang version requirements for RabbitMQ. As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases. Erlang 25 as our new baseline means much improved performance on ARM64 architectures, across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users. Release notes can be found on GitHub at . Partially reverts an unsafe inter-node communication that could affect classic mirrored queue operation ordering. Kudos to @bording for providing an automated way to reproduce the issue. GitHub issue: Classic mirrored queue leader replica issued to much credit to follower replicas, resulting in an uneven load and memory footprint between them. GitHub issue: Intra-cluster communication link metric collector could run into an exception when peer connection has just been re-established, e.g. after a peer node restart. GitHub issue: When a node was , it closed all MQTT client connections cluster-wide instead of just local client connections. GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.11.2.tar.xz` instead of the source tarball produced by GitHub.