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

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="665" height="70" viewbox="0 0 665 70"><path class="connector" d="M0 22h15m53 0h10m74 0h30m32 0h10m64 0h20m-141 0q5 0 5 5v8q0 5 5 5h116q5 0 5-5v-8q0-5 5-5m5 0h10m54 0h10m38 0h10m91 0h30m77 0h22m-109 25q0 5 5 5h5m79 0h5q5 0 5-5m-104-25q5 0 5 5v33q0 5 5 5h89q5 0 5-5v-33q0-5 5-5m5 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="53" height="25" rx="7"/><text class="text" x="25" y="22">DROP</text><rect class="literal" x="78" y="5" width="74" height="25" rx="7"/><text class="text" x="88" y="22">TRIGGER</text><rect class="literal" x="182" y="5" width="32" height="25" rx="7"/><text class="text" x="192" y="22">IF</text><rect class="literal" x="224" y="5" width="64" height="25" rx="7"/><text class="text" x="234" y="22">EXISTS</text><a xlink:href="../../../syntaxresources/grammardiagrams#name"><rect class="rule" x="318" y="5" width="54" height="25"/><text class="text" x="328" y="22">name</text></a><rect class="literal" x="382" y="5" width="38" height="25" rx="7"/><text class="text" x="392" y="22">ON</text><a xlink:href="../../../syntaxresources/grammardiagrams#table-name"><rect class="rule" x="430" y="5" width="91" height="25"/><text class="text" x="440" y="22">table_name</text></a><rect class="literal" x="551" y="5" width="77" height="25" rx="7"/><text class="text" x="561" y="22">CASCADE</text><rect class="literal" x="551" y="35" width="79" height="25" rx="7"/><text class="text" x="561" y="52">RESTRICT</text><polygon points="661,29 665,29 665,15 661,15" style="fill:black;stroke-width:0"/></svg>
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: introduction.md

title: KubeBlocks overview description: KubeBlocks, kbcli, multicloud keywords: [kubeblocks, overview, introduction] sidebar_position: 1 KubeBlocks is an open-source control plane software that runs and manages databases, message queues and other data infrastructure on K8s. The name KubeBlocks is inspired by Kubernetes and LEGO blocks, signifying that running and managing data infrastructure on K8s can be standard and productive, like playing with LEGO blocks. KubeBlocks could manage various type of engines, including RDBMSs (MySQL, PostgreSQL), Caches(Redis), NoSQLs (MongoDB), MQs(Kafka, Pulsar), and vector databases(Milvus, Qdrant, Weaviate), and the community is actively integrating more types of engines into KubeBlocks. Currently it has supported 32 types of engines! The core of KubeBlocks is a K8s operator, which defines a set of CRDs to abstract the common attributes of various engines. KubeBlocks helps developers, SREs, and platform engineers deploy and maintain dedicated DBPaaS, and supports both public cloud vendors and on-premise environments. Kubernetes has become the de facto standard for container orchestration. It manages an ever-increasing number of stateless workloads with the scalability and availability provided by ReplicaSet and the rollout and rollback capabilities provided by Deployment. However, managing stateful workloads poses great challenges for Kubernetes. Although StatefulSet provides stable persistent storage and unique network identifiers, these abilities are far from enough for complex stateful workloads. To address these challenges, and solve the problem of complexity, KubeBlocks introduces ReplicationSet and ConsensusSet, with the following capabilities: Role-based update order reduces downtime caused by upgrading versions, scaling, and rebooting. Maintains the status of data replication and automatically repairs replication errors or delays. Be compatible with AWS, GCP, Azure, and Alibaba Cloud. Supports MySQL, PostgreSQL, Redis, MongoDB, Kafka, and more. Provides production-level performance, resilience, scalability, and observability. Simplifies day-2 operations, such as upgrading, scaling, monitoring, backup, and restore. Contains a powerful and intuitive command line tool. Sets up a full-stack, production-ready data infrastructure in minutes.
Project: secureCodeBox (Provisioning / Security & Compliance)
File: adr_0018.md

title: "ADR-0018: Spaces in File Names Are Not Allowed" sidebar_label: "ADR-0018" | <!-- --> | <!-- --> | |-|-| | Status: | ACCEPTED | | Date: | 2022-09-20 | | Author(s): | Sven Strittmatter | We have the that most of our targets fail, if this repository working copy is cloned into a file location which contains white spaces in its file path. We chose as build tool because of its maturity and capabilities, but it lacks one essential feature: Handling of white spaces in paths. Of course, it is possible to escape paths, but this has only an effect to paths passed as string to a make target's command which will be evaluated by the shell. itself ignores such escaping which leads to bugs especially in constructs such as: ```makefile @for chart in $(HOOKSCHARTLIST); do \ $(BINDIR)/generate-helm-docs.sh --hook $${chart} $(HELMDOCS_DIR); \ done ``` The for-construct of shell does word splitting on any whitespace, not only newline. We assume lists of directories delimited by newlines. We heavily rely on looping subdirectories with such loops to build our modules (scanners, hooks etc.). Using a different sentinel character (e.g. `:`) is not a possible fix because setting `IFS` in the `Makefile` has no effect on word splitting, even for while-read loops. To fix this we need to extract all of these loop constructs into shell scripts (like `bin/npm-ci-all.sh` for the `npm-ci-all` target). That's lot of work and counteracts the sense of . Use another build tool which can deal with this will also result in a lot of work. We just did this to use . Luckily we cleaned up lot of things, so this may take less effort than the migration to . Simply forbid white spaces in file names. We decided to simply forbid white spaces in file paths. If one clones the repository to a location with white spaces in the path we exit make with an error message. We must not use white spaces for filenames in our repository. Windows users will possibly have a slightly worse user experience. Someone who can't freely modify or change the target path for his working copy can't make the secureCodeBox.
Project: Beam (App Definition and Development / Streaming & Messaging)
File: java-thirdparty.md

type: languages title: "Beam 3rd Party Java Extensions" <!-- 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. --> These are some of the 3rd party Java libraries that may be useful for specific applications. The Apache HTTPD webserver creates logfiles that contain valuable information about the requests that have been done to the webserver. The format of these log files is a configuration option in the Apache HTTPD server so parsing this into useful data elements is normally very hard to do. To solve this problem in an easy way a library was created that works in combination with Apache Beam and is capable of doing this for both the Apache HTTPD and NGINX. The basic idea is that the logformat specification is the schema used to create the line. This parser is simply initialized with this schema and the list of fields you want to extract. Apache License 2.0 <dependency> <groupId>nl.basjes.parse.httpdlog</groupId> <artifactId>httpdlog-parser</artifactId> <version>5.0</version> </dependency> Assuming a WebEvent class that has a setters setIP, setQueryImg and setQueryStringValues PCollection<WebEvent> filledWebEvents = input .apply("Extract Elements from logline", ParDo.of(new DoFn<String, WebEvent>() { private Parser<WebEvent> parser; @Setup public void setup() throws NoSuchMethodException { parser = new HttpdLoglineParser<>(WebEvent.class, "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\""); parser.addParseTarget("setIP", "IP:connection.client.host"); parser.addParseTarget("setQueryImg", "STRING:request.firstline.uri.query.img"); parser.addParseTarget("setQueryStringValues", "STRING:request.firstline.uri.query.*"); } @ProcessElement public void processElement(ProcessContext c) throws InvalidDissectorException, MissingDissectorsException, DissectionFailure { c.output(parser.parse(c.element())); } }) ); Parse and analyze the useragent string and extract as many relevant attributes as possible. Apache License 2.0 <dependency> <groupId>nl.basjes.parse.useragent</groupId> <artifactId>yauaa-beam</artifactId> <version>4.2</version> </dependency> PCollection<WebEvent> filledWebEvents = input .apply("Extract Elements from Useragent", ParDo.of(new UserAgentAnalysisDoFn<WebEvent>() { @Override public String getUserAgentString(WebEvent record) { return record.useragent; } @YauaaField("DeviceClass") public void setDC(WebEvent record, String value) { record.deviceClass = value; } @YauaaField("AgentNameVersion") public void setANV(WebEvent record, String value) { record.agentNameVersion = value; } }));
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_create_cast.md

title: CREATE CAST statement [YSQL] headerTitle: CREATE CAST linkTitle: CREATE CAST description: Use the CREATE CAST statement to create a cast. menu: v2.18: identifier: ddlcreatecast parent: statements type: docs Use the `CREATE CAST` statement to create a cast. {{%ebnf%}} create_cast, createcastwith_function, createcastwithout_function, createcastwith_inout, cast_signature {{%/ebnf%}} See the semantics of each option in the . `WITH FUNCTION` example. ```plpgsql yugabyte=# CREATE FUNCTION sqltodate(integer) RETURNS date AS $$ SELECT $1::text::date $$ LANGUAGE SQL IMMUTABLE STRICT; yugabyte=# CREATE CAST (integer AS date) WITH FUNCTION sqltodate(integer) AS ASSIGNMENT; yugabyte=# SELECT CAST (3 AS date); ``` `WITHOUT FUNCTION` example. ```plpgsql yugabyte=# CREATE TYPE myfloat4; yugabyte=# CREATE FUNCTION myfloat4_in(cstring) RETURNS myfloat4 LANGUAGE internal IMMUTABLE STRICT PARALLEL SAFE AS 'float4in'; yugabyte=# CREATE FUNCTION myfloat4_out(myfloat4) RETURNS cstring LANGUAGE internal IMMUTABLE STRICT PARALLEL SAFE AS 'float4out'; yugabyte=# CREATE TYPE myfloat4 ( INPUT = myfloat4_in, OUTPUT = myfloat4_out, LIKE = float4 ); yugabyte=# SELECT CAST('3.14'::myfloat4 AS float4); yugabyte=# CREATE CAST (myfloat4 AS float4) WITHOUT FUNCTION; yugabyte=# SELECT CAST('3.14'::myfloat4 AS float4); ``` `WITH INOUT` example. ```plpgsql yugabyte=# CREATE TYPE myint4; yugabyte=# CREATE FUNCTION myint4_in(cstring) RETURNS myint4 LANGUAGE internal IMMUTABLE STRICT PARALLEL SAFE AS 'int4in'; yugabyte=# CREATE FUNCTION myint4_out(myint4) RETURNS cstring LANGUAGE internal IMMUTABLE STRICT PARALLEL SAFE AS 'int4out'; yugabyte=# CREATE TYPE myint4 ( INPUT = myint4_in, OUTPUT = myint4_out, LIKE = int4 ); yugabyte=# SELECT CAST('2'::myint4 AS int4); yugabyte=# CREATE CAST (myint4 AS int4) WITH INOUT; yugabyte=# SELECT CAST('2'::myint4 AS int4); ```
Project: KubeEdge (Provisioning / Automation & Configuration)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: designing-lean-operators.md

title: "Designing Lean Operators" linkTitle: "Designing Lean Operators" weight: 5 description: This guide describes good practices concepts to designing lean Operators. One of the pitfalls that many operators are failing into is that they watch resources with high cardinality like secrets possibly in all namespaces. This has a massive impact on the memory used by the controller on big clusters. Such resources can be filtered by label or fields. The original doc design for `Filter cache ListWatch using selectors` can be accessed from IMPORTANT NOTE Requests to a client backed by a filtered cache for objects that do not match the filter will never return anything. In other words, filtered caches make the filtered-out objects invisible to the client. When creating the manager, you can add an Options struct to configure the Cache Each client.Object can be filtered with labels and fields In this scenario, the user will configure the Cache to filter the secret object by it's label. This will return a filtered cache for objects that match the filter. ```yaml mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{ Cache: cache.Options{ ByObject: map[client.Object]cache.ByObject{ &corev1.Secret{}: cache.ByObject{ Label: labels.SelectorFromSet(labels.Set{"app": "app-name"}), }, }, }, }) ``` In this scenario, the user will configure the Cache to filter the node object by it's field name. This will return a filtered cache for objects that match the filter. ```yaml mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{ Cache: cache.Options{ ByObject: map[client.Object]cache.ByObject{ &corev1.Node{}: cache.ByObject{ Fields: labels.SelectorFromSet(fields.Set{"metadata.name": "node01"}), }, }, }, }) ```
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: SDK-001-releases.md

Accepted Dapr exposes APIs for building blocks which can be invoked over http/gRPC by the user code. Making raw http/gRPC calls from user code works but it doesn't provide a good strongly typed experience for developers. Dapr provides language specific SDKs for developers for C#, Java, Javascript, Python, Go, Rust, C++. There may be others in the future For the current release, the SDKs are auto-generated from the Dapr proto specifications using gRPC tools. In future releases, we will work on creating and releasing strongly typed SDKs for the languages, which are wrappers on top of the auto-generated gRPC SDKs (e.g. C# SDK shipped for state management APIs with the 0.1.0 release.) This is the preferred approach. Creating purely handcrafted SDKs is discouraged. For Actors, language specific SDKs are written as Actor specific handcrafted code is preferred since this greatly simplifies the user experience. e.g. The C# Actor SDK shipped with the 0.1.0 release. Auto-generation of gRPC client side code from Dapr proto files allows Dapr to provide SDKs for the major languages with the 0.1.0 release and set us on the correct path to generate more user friendly SDKs by wrapping the auto-generated gRPC ones. There will be no auto-generated code for actor SDKs, which are also handcrafted to focus on API usability.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: linux_audit_system.md

+++ title = "linuxauditsystem resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "linuxauditsystem" identifier = "inspec/resources/os/linuxauditsystem.md linuxauditsystem resource" parent = "inspec/resources/os" +++ Use the `linuxauditsystem` Chef InSpec audit resource to test the configuration of Linux audit system. The Chef InSpec distributes this resource. A `linuxauditsystem` Chef InSpec audit resource allows you to test the configuration of Linux audit system. ```ruby describe linuxauditsystem do it { should be_enabled } it { should be_running } its('rules') { should include 'some_rule' } end ``` where `rules` is a property of this resource. `some_rule` is the expected rule to be included in the rules list. `beenabled` and `berunning` are matchers of this resource. The property of this resource is `rules`. The `rules` property returns an array of audit rules of the system. It allows testing by passing an argument as a string or a regular expression to a valid matcher. ```ruby its('rules') { should include 'RULE' } its('rules') { should include %r{someregexrule} } ``` For a full list of available matchers, please visit our . The specific matchers of this resource are `beenabled` and `berunning`. The `be_enabled` matcher tests if auditing is enabled on the system. ```ruby it { should be_enabled } ``` The `be_running` matcher tests if the audit daemon runs on the system. ```ruby it { should be_running } ``` The following examples show how to use this Chef InSpec audit resource. `be_enabled` checks if auditing is enabled on the system. ```ruby describe linuxauditsystem do it { should be_enabled } end ``` `be_running` checks for if the audit daemon runs on the system. ```ruby describe linuxauditsystem do it { should be_running } end ``` `rules` returns an array of audit rules of the system. ```ruby describe linuxauditsystem do its('rules') { should include '-w /etc -p wa' } its('rules') { should include %r!-w /etc -p wa! } its('rules') { should include %r{-w /etc -p wa} } its('rules') { should_not include %r!-a entry,always -S all -F pid=1005! } end ```
Project: Chef Infra (Provisioning / Automation & Configuration)
File: running_cookbook_as_hab+effortless_package.md

The Effortless Config application uses the Policyfiles feature of Chef to encapsulate an application which runs chef-solo against a compiled Policyfile and the collection of cookbooks it needs. Following directories will comprise the application: cookbooks: This directory contains the cookbooks our application will run. habitat: This directory contains the plan.sh and plan.ps1 files to build the habitat application for Effortless Config policyfiles: This directory contains the chef Policyfiles that will control what Effortless Config runs and the attributes used to configure it Install habitat as per steps given Set up Origin and access token at habitat builder https://bldr.habitat.sh For additional details about Habitat builder refer Set up Habitat CLI `hab cli setup` For additional about Habitat CLI refer Generate the cookbook repo using `chef generate repo REPO_NAME` For more information on chef-repo generation refer doc Once you are done creating your recipes, define the runlist inside a policy file under `policyfiles` directory of chef-repo e.g `policyfiles/base.rb` Navigate to the root of cookbook repo and run `hab plan init` It will create a new `habitat` sub-directory with a `plan.sh` (or `plan.ps1` on Windows), a `default.toml` file as well as `config` and `hooks` directories. Since we are running the cookbook as Hab + Effortless package, we need let the plan file know what is the run list which will be used by Infra Client. This can be done by setting following package configuration variables in the plan file: ``` $pkg_scaffolding="chef/scaffolding-chef-infra" # This pulls in latest Infra Client released from stable channel $scaffoldpolicyfilepath="{pathtoyourpolicyfilerelativetoplanfile}" # e.g "$PLANCONTEXT/../policyfiles" $scaffoldpolicyname="{nameofyour_policyfile}" ``` If we want to run the cookbook with a specific version of Infra Client, set the following variable with corresponding version details: `$scaffoldchefclient="chef/chef-infra-client/17.10.3/20220516153835"` For more details about plan file configuration refer The process for building the Effortless package is same as habitat package. Enter the hab studio to build the package and then load the service to run it. Since we have specified the run list and Infra Client version in the plan file, the cookbook will now run as an Effortless package Enter hab studio `hab studio enter` Build the package. Note this name has to match your cookbook repo name `build {yourpackagename}` Run the package as service `hab svc load {yourorigin}/{packagename}` See Supervisor logs `sup-log` # On linux `Get-SuperVisorLog` # On windows Check status of Habitat services `hab svc status` Stop a service `hab svc unload {yourorigin}/{packagename}`
Project: Pinniped (Provisioning / Key Management)
File: bug_report.md

name: Bug report about: Explain a problem you are experiencing title: '' labels: '' assignees: '' <!-- Hey! Thanks for opening an issue! IMPORTANT: If you believe this bug is a security issue, please don't use this template and follow our . It is recommended that you include screenshots and logs to help everyone achieve a shared understanding of the bug. --> What happened? Please be specific and include screenshots and logs! What did you expect to happen? Please be specific and include proposed behavior! What is the simplest way to reproduce this behavior? In what environment did you see this bug? Pinniped server version: Pinniped client version: Pinniped container image (if using a public container image): Pinniped configuration (what IDP(s) are you using? what downstream credential minting mechanisms are you using?): Kubernetes version (use `kubectl version`): Kubernetes installer & version (e.g., `kubeadm version`): Cloud provider or hardware configuration: OS (e.g: `cat /etc/os-release`): Kernel (e.g. `uname -a`): Others: What else is there to know about this bug?