cwielenb/CNCF-Dataset huggingface dataset:
Project: Distribution (Provisioning / Container Registry)
File: systemd.md

description: Using systemd to manage registry container keywords: registry, on-prem, systemd, socket-activated, recipe, advanced title: Start registry via systemd Using systemd to manage containers can make service discovery and maintenance easier by managing all services in the same way. Additionally, when using Podman, systemd can start the registry with socket-activation, providing additional security options: Run as non-root and expose on a low-numbered socket (< 1024) Run with `--network=none` When deploying the registry via Docker, a simple service file can be used to manage the registry: registry.service ```ini [Unit] Description=Distribution registry After=docker.service Requires=docker.service [Service] Restart=always ExecStartPre=-/usr/bin/docker stop %N ExecStartPre=-/usr/bin/docker rm %N ExecStart=/usr/bin/docker run --name %N \ -v registry:/var/lib/registry \ -p 5000:5000 \ registry:2 [Install] WantedBy=multi-user.target ``` In this case, the registry will store images in the named-volume `registry`. Note that the container is destroyed on restart instead of using `--rm` or destroy on stop. This is done to make accessing `docker logs ...` easier in the case of issues. Podman offers tighter integration with systemd than Docker does, and supports socket-activation of containers. ```sh podman create --name registry --network=none -v registry:/var/lib/registry registry:2 podman generate systemd --name --new registry > registry.service ``` registry.socket ```ini [Unit] Description=Distribution registry [Socket] ListenStream=5000 [Install] WantedBy=sockets.target ``` Installation can be either rootful or rootless. For Docker, rootless configurations often include additional setup steps that are beyond the scope of this recipe, whereas for Podman, rootless containers generally work out of the box. Run as root: Copy registry.service (and registry.socket if relevant) to /etc/systemd/service/ Run `systemctl daemon-reload` Enable the service: When using socket activation: `systemctl enable registry.socket` When not* using socket activation: `systemctl enable registry.service` Start the service: When using socket activation: `systemctl start registry.socket` When not* using socket activation: `systemctl start registry.service` Run as the target user: Copy registry.service (and registry.socket if relevant) to ~/.config/systemd/user/ Run `systemctl --user daemon-reload` Enable the service: When using socket activation: `systemctl --user enable registry.socket` When not* using socket activation: `systemctl --user enable registry.service` Start the service: When using socket activation: `systemctl --user start registry.socket` When not* using socket activation: `systemctl --user start registry.service` Note: To have rootless services start on boot, it may be necessary to enable linger via `loginctl enable-linger $USER`.
Project: KICS (Provisioning / Security & Compliance)
File: 49113af4-29ca-458e-b8d4-724c01a4a24f.md

title: Terminated Pod Garbage Collector Threshold Not Properly Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 49113af4-29ca-458e-b8d4-724c01a4a24f Query name: Terminated Pod Garbage Collector Threshold Not Properly Set Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Availability URL: When using kube-controller-manager commands, the '--terminated-pod-gc-threshold' should be set between 0 and 12501<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-controller-manager-amd64:v1.6.0 command: ["kube-controller-manager","--terminated-pod-gc-threshold=0"] args: [] restartPolicy: OnFailure ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-controller-manager-amd64:v1.6.0 command: ["kube-controller-manager"] args: ["--terminated-pod-gc-threshold=12501"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-controller-manager-amd64:v1.6.0 command: ["kube-controller-manager"] args: ["--terminated-pod-gc-threshold=10"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-controller-manager-amd64:v1.6.0 command: ["kube-controller-manager","--terminated-pod-gc-threshold=10"] args: [] restartPolicy: OnFailure ```
Project: Distribution (Provisioning / Container Registry)
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: KubeVela (App Definition and Development / Application Definition & Image Build)
File: topologyspreadconstraints.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: application-with-topologyspreadconstraints spec: components: name: busybox-runner type: worker properties: image: busybox cmd: sleep '1000' traits: type: topologyspreadconstraints properties: constraints: topologyKey: zone labelSelector: matchLabels: zone: us-east-1a maxSkew: 1 whenUnsatisfiable: DoNotSchedule minDomains: 1 nodeAffinityPolicy: Ignore nodeTaintsPolicy: Ignore topologyKey: node labelSelector: matchExpressions: key: foo operator: In values: abc maxSkew: 1 whenUnsatisfiable: ScheduleAnyway minDomains: 1 nodeAffinityPolicy: Ignore nodeTaintsPolicy: Ignore ```
Project: Carvel (App Definition and Development / Application Definition & Image Build)
File: README_Connect.md

The following is a sample Lambda function that receives an Amazon Connect event as an input and writes some of the record data to CloudWatch Logs. (Note that anything written to stdout or stderr will be logged as CloudWatch Logs events.) ```go package main import ( "context" "fmt" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" ) func main() { lambda.Start(handler) } func handler(ctx context.Context, connectEvent events.ConnectEvent) (events.ConnectResponse, error) { fmt.Printf("Processing Connect event with ContactID %s.\n", connectEvent.Details.ContactData.ContactID) fmt.Printf("Invoked with %d parameters\n", len(connectEvent.Details.Parameters)) for k, v := range connectEvent.Details.Parameters { fmt.Printf("%s : %s\n", k, v) } resp := events.ConnectResponse{ "Result": "Success", "NewAttribute": "NewValue", } return resp, nil } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.179.md

layout: release date: 2023-11-20 tag: v0.6.179 [Server] update status at the end of the final state @MUzairS15 (#9402) [Server] Handle events emitted by `Execute funcs` properly. @MUzairS15 (#9397) Add New shapes (Polygons) @aabidsofi19 (#9374) Enhance Dashboard @theBeginner86 (#9352) fix ui bug in dark mode of modal @vaibhavpnimkar (#9389) Registryui @ptdatta (#9370) [Connections] Connection State Management @MUzairS15 (#9383) Bump golang.org/x/oauth2 from 0.12.0 to 0.14.0 @dependabot (#9341) [Docs] Managing infrastructure with Meshery. @MUzairS15 (#9391) Filter "order by" parameter to fix sql inject vuln @phant0ms (#9372) Thank you to our contributors for making this release possible: @MUzairS15, @Yashsharma1911, @aabidsofi19, @dependabot, @leecalcote, @phant0ms, @ptdatta, @theBeginner86 and @vaibhavpnimkar
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.5.48.md

layout: release date: 2021-08-18 tag: v0.5.48 [UI] Filters delete files(single select) @Chadha93 (#3887) [UI] Snackbar Closing and Settings Btn Fixed @NikhilSharma03 (#3923) [UI] Fix 'Error communicating with Prometheus' error @sudo-NithishKarthik (#3928) Fix to unlock the db lock properly @dhruv0000 (#3927) pattern apply & delete unit test @suhaniii (#3921) [UI] fix formatting of string @bariqhibat (#3922) [mesheryctl] started writing tests for utils @Revolyssup (#3883) Added the OpenApi docs for filter endpoint @sayantan1413 (#3899) [UI] [Pattern + Application] Delete operation (single select) @Chadha93 (#3911) [UI] Fetch metrics only when metrics components are configured @sudo-NithishKarthik (#3913) [UI] Meshery Operator and MeshSync Chips overlapped fixed @NikhilSharma03 (#3882) Move the Performance tab in settings page to user preferences page @yagarwal1307 (#3903) Fix navigator sidebar to show help icon and chevron in mobile view @yagarwal1307 (#3904) Fixed the swagger workflow error @sayantan1413 (#3926) Added the unit test for mesheryctl system update command @Shreyas220 (#3909) Fix typo in the spanish documentation @jesus-lerma (#3906) [Documentation] Fixed broken GitHub link @Rubix982 (#3907) Thank you to our contributors for making this release possible: @Chadha93, @DelusionalOptimist, @NikhilSharma03, @Revolyssup, @Rubix982, @Shreyas220, @bariqhibat, @dhruv0000, @jesus-lerma, @leecalcote, @piyushsingariya, @sayantan1413, @sudo-NithishKarthik, @suhaniii, @utkarsh-pro, @yagarwal1307, jesuslerma and l5io
Project: ArangoDB (App Definition and Development / Database)
File: metaprogrammg1.md

+++ title = "Phase 3" description = "" weight = 40 +++ We have built our first two phases of construction for `file_handle`, and for some users they might be happy writing: {{% snippet "constructors.cpp" "static-use" %}} ... and be done with it. But wouldn't it be nicer if we could instead write: {{% snippet "constructors.cpp" "construct-use" %}} The eye is immediately drawn to the two-stage invocation pattern, so we are constructing a type `make<file_handle>` using the arguments with which we wish to invoke the `file_handle` constructor with, and then invoking the call operator on that `make<file_handle>` instance to do the actual construction. It may seem a bit clunky to use brace initialisation for parameters followed by a "spurious" set of empty brackets, but we think that this is a better approach than alternatives. We shall briefly cover those at the end of this section.
Project: KICS (Provisioning / Security & Compliance)
File: f0d8781f-99bf-4958-9917-d39283b168a0.md

title: DB Security Group Has Public Interface hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: f0d8781f-99bf-4958-9917-d39283b168a0 Query name: DB Security Group Has Public Interface Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: The CIDR IP should not be a public interface<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "awsdbsecurity_group" "positive1" { name = "rds_sg" ingress { cidr = "0.0.0.0/0" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="9" resource "awsdbsecurity_group" "positive1" { name = "rds_sg" ingress { cidr = "10.0.0.0/8" } ingress { cidr = "0.0.0.0/0" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsdbsecurity_group" "negative1" { name = "rds_sg" ingress { cidr = "10.0.0.0/8" } } ```
Project: Distribution (Provisioning / Container Registry)
File: MIGRATION_GUIDE.md

Starting from , the import path will be: "github.com/golang-jwt/jwt/v4" The `/v4` version will be backwards compatible with existing `v3.x.y` tags in this repo, as well as `github.com/dgrijalva/jwt-go`. For most users this should be a drop-in replacement, if you're having troubles migrating, please open an issue. You can replace all occurrences of `github.com/dgrijalva/jwt-go` or `github.com/golang-jwt/jwt` with `github.com/golang-jwt/jwt/v4`, either manually or by using tools such as `sed` or `gofmt`. And then you'd typically run: ``` go get github.com/golang-jwt/jwt/v4 go mod tidy ``` The original migration guide for older releases can be found at https://github.com/dgrijalva/jwt-go/blob/master/MIGRATION_GUIDE.md.
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: vela-plugin-registry-reference.md

`Registry` interface definitions have two methods: `GetCap` and `ListCaps`. Here "Cap" can represent trait or component definition ```go // Registry define a registry stores trait & component defs type Registry interface { GetCap(addonName string) (types.Capability, []byte, error) ListCaps() ([]types.Capability, error) } ``` Now we have implemented:`GithubRegistry`, `LocalRegistry` and `OssRegistry`, which represent three types of registry source. To create a `Registry` object you should and must call `NewRegistry()`. You could use `RegistryFile` to convert `[]byte` (easily got from all kinds of source) to `Capability`. Here is `RegistryFile`'s definition. ```go // RegistryFile describes a file item in registry type RegistryFile struct { data []byte // file content name string // file's name } ``` How they differ from each other? `Capcenter` is a type for vela CLI. It has some function to sync content from remote and local `~/.vela` directory and apply some `ComponentDefinition` or `TraitDefinition` to the cluster. In the contrast, `Registry` is a type for kubectl vela plugin, which focuses on cluster directly. In one word, `Registry` has no local operations. They share some basic function.
Project: Cyclops (App Definition and Development / Application Definition & Image Build)
File: feedback.md

We hope you found our installation tutorial and demo helpful. Your feedback is important to us, and we would appreciate it if you could take a moment to share your thoughts. Your input helps us improve and provide a better experience for our users. Please take a few minutes to fill out the . Your feedback is valuable to us, and we appreciate your time. If you encountered any issues during the ), please let us know. Your feedback will help us address any potential challenges that users may face. We hope the clearly explains how to use our product. If you have any suggestions for improvement or anything you'd like to see in future tutorials, please share your thoughts. We appreciate your time and effort in providing feedback. If you have any additional comments or questions, don't hesitate to contact us directly at . Happy deploying!
Project: CloudARK KubePlus (App Definition and Development / Application Definition & Image Build)
File: Contributing.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. This library adapts the stdlib `encoding/json` decoder to be compatible with Kubernetes JSON decoding, and is not expected to actively add new features. It may be updated with changes from the stdlib `encoding/json` decoder. Any code that is added must: Have full unit test and benchmark coverage Be backward compatible with the existing exposed go API Have zero external dependencies Preserve existing benchmark performance Preserve compatibility with existing decoding behavior of `UnmarshalCaseSensitivePreserveInts()` or `UnmarshalStrict()` Avoid use of `unsafe` We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers You can reach the maintainers of this project via the . - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: kubernetes-compatibility.md

Kubernetes supports 3 minor release concurrently. This means if the latest Kubernetes release is v1.19, that v1.18 and v1.17 will remain supported for backport fixes but that v1.16 will lose support. Similarly, each KubeVirt release maintains compatibility with the latest 3 Kubernetes releases that are out at the time the KubeVirt release is made. Here are some theoretical examples (note that the versions are made up to illustrate the example) KubeVirt release v0.1 is cut. At that point in time the latest Kubernetes version is v1.3. This means KubeVirt v0.1 will forever be compatible with Kubernetes v1.3, v1.2, and v1.1. KubeVirt main always follows the latest 3 Kubernetes releases. If a new Kubernetes v1.4 release is cut, that means support for v1.1 will be dropped for KubeVirt main. Note that this support for the latest Kubernetes releases doesn't happen immediately. There is a period of time, usually a few weeks, where the new version of Kubernetes must be integrated into KubeVirt's CI. The goal here is to integrate the latest Kubernetes version into CI before the next KubeVirt release is cut. KubeVirt main supports Kubernetes releases v1.4, v1.3, and v1.2. However, the KubeVirt v0.1 release was cut when the latest Kubernetes release was v1.3. This means that KubeVirt v0.1 supports Kubernetes v1.3, v1.2, v1.1 while KubeVirt main is tracking support for Kubernetes v1.4, v1.3, v1.2. The KubeVirt community maintains the ability to extend support for a KubeVirt release to older and newer Kubernetes versions that may fall outside of the latest 3 Kubernetes release present at the time of the KubeVirt release. The KubeVirt commitment to supporting the latest 3 Kubernetes release is a commitment that this is the minimum guarantee we support and test. We will not support less than this minimum, however there are times when we may choose to support more Kubernetes releases than our minimum guideline suggests. It is possible, and likely, that KubeVirt releases may continue to work with unsupported Kubernetes versions. Understand that we make no guarantees for this support. While it may technically work, there is no testing or CI being performed to guarantee it remains working with future KubeVirt patch releases.
Project: StarRocks (App Definition and Development / Database)
File: approx_count_distinct.md

displayed_sidebar: "English" Returns the approximate value of aggregate function similar to the result of COUNT(DISTINCT col). It is faster than the COUNT and DISTINCT combination and uses a fixed-size memory, so less memory is used for columns of high cardinality. ```Haskell APPROXCOUNTDISTINCT(expr) ``` ```plain text MySQL > select approxcountdistinct(queryid) from logstatis group by datetime; +--+ | approxcountdistinct(`query_id`) | +--+ | 17721 | +--+ ``` APPROXCOUNTDISTINCT
Project: ORY Hydra (Provisioning / Key Management)
File: PaginationHeaders.md

Name | Type | Description | Notes | - | - | - Link | Pointer to string | The link header contains pagination links. For details on pagination please head over to the . in: header | [optional] XTotalCount | Pointer to string | The total number of clients. in: header | [optional] `func NewPaginationHeaders() *PaginationHeaders` NewPaginationHeaders instantiates a new PaginationHeaders object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewPaginationHeadersWithDefaults() *PaginationHeaders` NewPaginationHeadersWithDefaults instantiates a new PaginationHeaders object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *PaginationHeaders) GetLink() string` GetLink returns the Link field if non-nil, zero value otherwise. `func (o PaginationHeaders) GetLinkOk() (string, bool)` GetLinkOk returns a tuple with the Link field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *PaginationHeaders) SetLink(v string)` SetLink sets Link field to given value. `func (o *PaginationHeaders) HasLink() bool` HasLink returns a boolean if a field has been set. `func (o *PaginationHeaders) GetXTotalCount() string` GetXTotalCount returns the XTotalCount field if non-nil, zero value otherwise. `func (o PaginationHeaders) GetXTotalCountOk() (string, bool)` GetXTotalCountOk returns a tuple with the XTotalCount field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *PaginationHeaders) SetXTotalCount(v string)` SetXTotalCount sets XTotalCount field to given value. `func (o *PaginationHeaders) HasXTotalCount() bool` HasXTotalCount returns a boolean if a field has been set.