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

List instance types of a YugabyteDB Anywhere on-premises provider List instance types of a YugabyteDB Anywhere on-premises provider ``` yba provider onprem instance-types list [flags] ``` ``` -h, --help help for list ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the provider for the action. Required for create, delete, describe, instance-types and nodes. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage YugabyteDB Anywhere onprem instance types
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.78.md

layout: release date: 2023-04-13 tag: v0.6.78 removed helm meshery-cpx chart and update chart.yaml and values.yaml @harsh-del (#7520) update login and logout flow @MUzairS15 (#7511) Register K8s components with existing models @Revolyssup (#7525) Update Playground's configuration with extending timeout @Revolyssup (#7528) Changed default value of provider to 'Meshery' @abdullah1308 (#7510) [update] Meshmodel categories icons updated @ritiksaxena124 (#7531) Add workflow to perform nightly cleanup on playground cluster @Revolyssup (#7523) [DOCS] Added a contributing to Docker Extension page @Ambareen09 (#7524) Bump commonmarker from 0.23.7 to 0.23.9 in /docs @dependabot (#7529) Add entry for `system provider` in mesheryctl index @alphaX86 (#7536) Bump nokogiri from 1.14.0 to 1.14.3 in /docs @dependabot (#7530) Thank you to our contributors for making this release possible: @Ambareen09, @MUzairS15, @Revolyssup, @abdullah1308, @alphaX86, @dependabot, @dependabot[bot], @harsh-del, @leecalcote and @ritiksaxena124
Project: Gradle Build Tool (App Definition and Development / Application Definition & Image Build)
File: README.md

This project contains the Gradle performance test suite. For information about the test infrastructure, see A performance test scenario is made up of 2 parts: A test build to use. The test builds are generated from templates and are defined in the plugin. Details for how to invoke Gradle (or Maven). This includes the tasks to run, the JVM args, whether the daemon or tooling API should be used to invoke Gradle, etc. A performance test configures various fixtures to describe each scenario. The fixtures will then run the scenario several times to warm up and then several more times, capturing metrics. The metrics are collected in a database under `~/.gradle-performance-test-data` and a report is generated into `build/performance-tests/report`. The build templates live in . Each template build is parameterized to some degree. For example, it is possible to define how many projects, source or test files to generate for a performance test build. There is a task defined in for each performance test build, that specifies which templates to use and the build parameters. Total build execution time. Build configuration time. Task execution time. Heap consumption at the end of the build. Total heap usage during the build A `performance:report` task generates a static HTML report from the contents of the database in `~/.gradle-performance-test-data`. This report allows the results over time to be visualized. The reports for the most recent test suite run against master can be found at: Running all the tests at once will be resource-intensive and long (multiple hours). However, you can find instructions for running a single performance test at the top of each Graph page. The result of that local run will not include comparisons with previous executions. Still, you can then look at the numbers and verify that your changes do not introduce a regression. For tracking down performance regressions, see .
Project: KICS (Provisioning / Security & Compliance)
File: a7b520bb-2509-4fb0-be05-bc38f54c7a4c.md

title: MySQL Instance With Local Infile On hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a7b520bb-2509-4fb0-be05-bc38f54c7a4c Query name: MySQL Instance With Local Infile On Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: MySQL Instance should not have Local Infile On<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="10" name: sql_instance google.cloud.gcpsqlinstance: auth_kind: serviceaccount databaseversion: MYSQL5_6 name: "{{ resource_name }}-2" project: test_project region: us-central1 serviceaccountfile: /tmp/auth.pem settings: database_flags: name: local_infile value: on tier: db-n1-standard-1 state: present ``` ```yaml title="Negative test num. 1 - yaml file" name: sql_instance google.cloud.gcpsqlinstance: auth_kind: serviceaccount databaseversion: SQLSERVER13_1 name: '{{ resource_name }}-2' project: test_project region: us-central1 serviceaccountfile: /tmp/auth.pem settings: database_flags: name: name1 value: value1 tier: db-n1-standard-1 state: present ```
Project: Sonobuoy (Provisioning / Security & Compliance)
File: sonobuoy_images_inspect.md

Inspect images Inspect if image is available in the registry ``` sonobuoy images inspect [flags] ``` ``` --context string Context in the kubeconfig to use. --dry-run If true, only print the image operations that would be performed. -h, --help help for inspect --kubeconfig Kubeconfig Path to explicit kubeconfig file. --kubernetes-version string Use default E2E image, but override the version. Default is 'auto', which will be set to your cluster's version if detected, erroring otherwise. 'ignore' will try version resolution but ignore errors. 'latest' will find the latest dev image/version upstream. -p, --plugin strings Describe which plugin's images to interact with (Valid plugins are 'e2e', 'systemd-logs'). (default [e2e,systemd-logs]) ``` ``` --level level Log level. One of {panic, fatal, error, warn, info, debug, trace} (default info) ``` - Manage images used in a plugin to facilitate running them in airgapped (or similar) environments. Supported plugins are: 'e2e'
Project: Chef Infra (Provisioning / Automation & Configuration)
File: cookbook_root_aliases.md

There are several common cases when writing Chef cookbooks that result in a folder containing a single file, usually called `default.rb`. Root aliases allow for using a single file instead of a folder. As a cookbook author, I want to less complex directory layouts, so that learning and maintenance is easier. There are two common cases where a single-file-in-folder comes up: `attributes/default.rb` `recipes/default.rb` With `attributes`, this single-file-in-folder case is common to the point of almost complete irrelevance of other layouts, given that all attribute files are always loaded. `recipes` are not exclusively a single-file-in-folder case, but it is common enough to warrant a special case. With this in mind, aliases are available for each: `attributes.rb` `recipe.rb` It is an error for a cookbook to contain both an alias and its target, or two aliases for the same target. No aliases are provided for other types as they are generally a more advanced use case where the worry about learning curve is reduced. Aliases are equivalent to their target file for purposes of loading either via standard cookbook loading, or methods like `include_recipe`. This meshes well with RFC017 towards a goal of reducing the file layout complexity of simple cookbooks. There can be compatibility issues with tools that parse the cookbook manifest data and presume that all files from a given segment reside under the previously required folder. The author knows of no such tools, and given that the manifest format is mostly an internal representation, this is not considered a blocker. Overall, the goal of these RFCs is to remove the frequent use of single-child folders. The choice of which aliases to provide and what to name them is mostly driven by the common cases, but is not exhaustive. `attributes.rb` and `recipe.rb` are chosen to match their usage grammatically. An additional alias of `recipes.rb` could be provided to match the folder name, but this is left for a future improvement based on usage feedback.
Project: KICS (Provisioning / Security & Compliance)
File: b16e8501-ef3c-44e1-a543-a093238099c9.md

title: Using Platform Flag with FROM Command hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b16e8501-ef3c-44e1-a543-a093238099c9 Query name: Using Platform Flag with FROM Command Platform: Dockerfile Severity: <span style="color:#edd57e">Low</span> Category: Best Practices URL: 'FROM' instruction should use the flag '--platform'<br> ```dockerfile title="Positive test num. 1 - dockerfile file" hl_lines="6" FROM alpine:3.5 RUN apk add --update py2-pip RUN pip install --upgrade pip LABEL maintainer="SvenDowideit@home.org.au" COPY requirements.txt /usr/src/app/ FROM baseimage as baseimage-build ``` ```dockerfile title="Negative test num. 1 - dockerfile file" FROM alpine:3.5 RUN apk add --update py2-pip RUN pip install --upgrade pip LABEL maintainer="SvenDowideit@home.org.au" COPY requirements.txt /usr/src/app/ FROM --platform=arm64 baseimage as baseimage-build ```
Project: Salt Project (Provisioning / Automation & Configuration)
File: 3006.6.md

(release-3006.6)= <! Do not edit this file. This is auto generated. Edit the templates in doc/topics/releases/templates/ for a given release. --> <!-- Add release specific details below --> <!-- Do not edit the changelog below. This is auto generated. --> Salt no longer time bombs user installations on code using `salt.utils.versions.warnuntildate` Fix un-closed transport in tornado netapi CVE-2024-22231 Prevent directory traversal when creating syndic cache directory on the master CVE-2024-22232 Prevent directory traversal attacks in the master's serve_file method. These vulerablities were discovered and reported by: Yudi Zhao(Huawei Nebula Security Lab),Chenwei Jiang(Huawei Nebula Security Lab) Update some requirements which had some security issues: Bump to `pycryptodome==3.19.1` and `pycryptodomex==3.19.1` due to https://github.com/advisories/GHSA-j225-cvw7-qrx7 Bump to `gitpython==3.1.41` due to https://github.com/advisories/GHSA-2mqj-m65w-jghx Bump to `jinja2==3.1.3` due to https://github.com/advisories/GHSA-h5c8-rqwp-cp95
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: labels-and-annotations.md

Sometimes customized Labels or Annotations are needed for the vertices, for example, adding an annotation to enable or disable sidecar injection. To do that, a `metadata` with labels or annotations can be added to the vertex. ```yaml apiVersion: numaflow.numaproj.io/v1alpha1 kind: Pipeline metadata: name: my-pipeline spec: vertices: name: my-vertex metadata: labels: key1: val1 key2: val2 annotations: key3: val3 key4: val4 ```
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: CHANGELOG.md

Updated dependencies @backstage/core-plugin-api@0.6.0 @backstage/test-utils@0.2.3 @backstage/core-app-api@0.5.0 Updated dependencies @backstage/core-plugin-api@0.6.0-next.0 @backstage/core-app-api@0.5.0-next.0 @backstage/test-utils@0.2.3-next.0 Updated dependencies @backstage/test-utils@0.2.2 @backstage/core-plugin-api@0.5.0 @backstage/core-app-api@0.4.0 Updated dependencies [ae5983387] Updated dependencies [0d4459c08] @backstage/theme@0.2.0
Project: ArangoDB (App Definition and Development / Database)
File: basic_result.md

+++ title = "`basic_result<T>`" description = "A boolean concept matching types which are convertible to a `basic_result<T, E, NoValuePolicy>`." +++ If on C++ 20 or the Concepts TS is enabled, a boolean concept matching types which have `valuetype`, `errortype` and `novaluepolicytype` member typedefs; that the type is convertible to `basicresult<valuetype, errortype, novaluepolicytype>`; that `basicresult<valuetype, errortype, novaluepolicy_type>` is a base of the type. If without Concepts, a static constexpr bool which is true for types matching the same requirements, using a SFINAE based emulation. This concept matches any type which provides the same typedefs as a {{% api "basicresult<T, E, NoValuePolicy>" %}}, has that `basicresult` as a base class, and is implicitly convertible to `basicresult`. Whilst not guaranteed, it is very likely that the type is a `basicresult`, or inherits publicly from a `basicresult`. If you want something which matches any value-or-error type, consider {{% api "valueorerror<T>" %}}. If you want something which exactly matches `basicresult`, use {{% api "isbasicresult<T>" %}}. Namespace: `BOOSTOUTCOMEV2_NAMESPACE::concepts` Header: `<boost/outcome/basic_result.hpp>`
Project: Shifu (Provisioning / Automation & Configuration)
File: develop-on-linux.md

Welcome developers! This guide will help you on setting up development environment for `Shifu` on `Linux` ```text Ubuntu 20.04 LTS ``` Please submit an to GitHub if you are having issue following this guide/you have noticed anything wrong with this guide. Use the following command to clone *Shifu*: ```bash git clone https://github.com/Edgenesis/shifu.git ``` Follow the official from Docker official website. the installation `deb` and install. After installation, use "File --> Open Folder" to open *Shifu* directory: A prompt should show up automatically to open this project in remote container: Click on that, VSCode should open your project in remote container. Your development environment is ready! *Note*: If you use `Visual Studio Code` with `Dev Container` you can skip all below environment setup steps. From , download and install go using the following command: ```bash wget https://go.dev/dl/go1.22.0.linux-amd64.tar.gz rm -rf /usr/local/go && tar -C /usr/local -xzf go1.22.0.linux-amd64.tar.gz echo "export PATH=$PATH:/usr/local/go/bin" >> $HOME/.profile ``` from , install with: ```bash curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.16.0/kind-linux-amd64 \ && chmod +x ./kind \ && mv ./kind /usr/local/bin/kind ``` from , install with: ```bash curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl ``` from , install with: ```bash curl -L -o kubebuilder https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH) chmod +x kubebuilder && mv kubebuilder /usr/local/bin/ ``` Navigate to `shifu`'s directory, issue: ```bash GO111MODULE=on go mod download ``` *(Optional)* If you are having issue download dependencies, add a proxy by using: ```bash GOPROXY=https://goproxy.cn,direct GO111MODULE=on go mod download ``` Follow our and start building `Shifu`.
Project: KubeZoo (Provisioning / Automation & Configuration)
File: faq.md

Does kubezoo have any other restrictions except for not supporting daemonset resources? Kubezoo supports most of the resources such as pod, deployment and statefulset by default, while restrict the cluster sharing resources such as daemonset and node. The reason is that when multiple tenants share a cluster, no tenant is expected to sense and manipulate nodes(including daemonset) for security and isolation purpose. Does kubezoo support RBAC for tenants? Yes, kubezoo impersonates tenant identities through the impersonate mechanism, so the RBAC API is consistent with native API of kubernetes. Does CRD share across the tenants? KubeZoo divides CRD into two categories: one is tenant CRD which among tenants are completely isolated. The other is system CRD in a public cloud scenario, which will be handled by the same controller in the backend cluster. System CRD can be configured with a special policy to ensure that they are available to one or more tenants who can create objects. What if pods of different tenants are deployed on the same Node and their performance affects each other? In the public cloud scenario, we could implement the data plane through some services such as elastic container instance with higher isolation to ensure the complete isolation of computing, storage, and network resources. Does kubezoo need a dedicated kubectl? No, kubezoo supports the full kubernetes API, so each tenant could use kubectl exactly the same way as a single cluster. What are the advantages and disadvantages of kubezoo and kubernetes's HNC? The HNC solution implements a hierarchical namespace structure that is still evolving and has not yet become the standard API of kubernetes yet. The advantage of kubezoo is that it provides the standard kubernetes API. In other words, if HNC will be supported by the standard kubernetes API in the future, then every tenant of kubezoo will be able to use HNC. What is the landing scene of kubezoo? From the perspective of private cloud, many small service resources have small demands. However, if a cluster is independently maintained for these small services, the operation and resource costs are high. Therefore, private cloud has a clear scenario. In the public cloud scenario, most tenants need only a lit resources, so the construction of serverless kubernetes based on kubezoo has the advantages of high efficiency and low cost.
Project: Sonobuoy (Provisioning / Security & Compliance)
File: 2020-12-11-decoupling-sonobuoy-and-kubernetes.md

title: Decoupling Sonobuoy and Kubernetes image: /img/sonobuoy.svg excerpt: Sonobuoy 0.20.0 release and the future of Sonobuoy project author_name: Wilson Husin author_url: https://github.com/wilsonehusin author_avatar: https://avatars3.githubusercontent.com/u/14004487 categories: [kubernetes, sonobuoy] tags: ['Sonobuoy Team', 'Wilson Husin'] date: 2020-12-11 slug: decoupling-sonobuoy-and-kubernetes Historically, we have been following Kubernetes releases to ensure the usability of Sonobuoy with the most recent Kubernetes version. We are excited to announce that beginning Sonobuoy 0.20, Sonobuoy releases will no longer be attached to Kubernetes releases. Sonobuoy provides a one-stop solution to run Kubernetes conformance testing. It also handles airgapped testing nicely for users to prepare container images used by the test suite. This feature, however, is also the reason why Sonobuoy releases are tied to Kubernetes releases -- Sonobuoy maintains a copy of list of images internally for each Kubernetes minor. With this release, Sonobuoy no longer maintains that list and will determine the images at runtime. This change only applies to `sonobuoy images` workflow, where one can pull and push container images from official registries to custom registries. Previously, not all `sonobuoy images` subcommand required Docker client to be present. With this release, Docker client is required for all `sonobuoy images` subcommands. Specifically, `sonobuoy images list` now runs `docker exec` under the hood. This allowed us to always dynamically determine required container images based on the matching Kubernetes conformance image. Were working on having this API exposed for all plugins, on this! We have future plans for Sonobuoy beyond conformance testing which we're excited to announce. .
Project: FOSSA (Provisioning / Security & Compliance)
File: rpm.md

RPM packages managed by system package managers like `dnf` and `yum` are built using SPEC files. We are able to analyze these files to determine runtime dependencies. | Strategy | Direct Deps | Transitive Deps | Edges | Tags | Container Scanning | | -- | | | -- | -- | | | rpm-spec | :whitecheckmark: | :x: | :x: | Environment | :whitecheckmark: | RPM SPEC files have strict naming conventions. They must be in the form of `<package-name>.spec`, e.g.: `binutils.spec`. We scan any file with a `.spec` file extension. Currently, we scan for lines which start with `Requires:`, followed by at least one space. On this line we extract EXACTLY ONE package, which may optionally specify a single version constraint. This package and its constraint are considered a single, direct, runtime dependency. The SPEC file format is simple, yet robust. We currently do not support all of its features yet. Notably, we do not support the following: Combinatoric version constraints, such as `(>= 1.2 and != 1.4) or = 0.9` Parentheses, as well as the `and` and `or` constructs are not supported yet. Build-time requirements We currently parse these, since the form is identical to runtime dependencies (`BuildRequires:` vs. `Requires:`), but we do not know if this is valuable for users, since some of these dependencies are tools like compilers (`gcc` is a common build-time dependency). Macros, such as `xxxxxx-%{?_isa}`, or `xxxxx = %{version}-%{release}` SPEC files allow for a few macros to dynamically determine package names/versions. We do not yet support this, although we may support it in the future.
Project: YugabyteDB (App Definition and Development / Database)
File: ybmaster.md

title: YB-Master metrics headerTitle: YB-Master metrics linkTitle: YB-Master metrics headcontent: Monitor table and tablet operations description: Learn about YugabyteDB's YB-Master metrics, and how to select and use the metrics. menu: v2.18: identifier: yb-master-metrics parent: metrics-overview weight: 140 type: docs The hosts system metadata, records about tables in the system and locations of their tablets, users, roles, permissions, and so on. YB-Masters are also responsible for coordinating background operations such as schema changes, handling addition and removal of nodes from the cluster, automatic re-replication of data on permanent failures, and so on. All handler latency metrics include additional attributes. Refer to . The following are key metrics for evaluating YB-Master performance. All metrics are counters and units are microseconds. | Metric (Counter \| microseconds) | Description | | : | : | | `handlerlatencyybmasterMasterClient_GetTabletLocations` | Time spent on fetching the replicas from the master servers. This metric includes the number of times the locations of the replicas are fetched from the master server. | `handlerlatencyybtserverTabletServerService_Read` | Time toread the PostgreSQL system tables (during DDL). This metric includes the count or number of reads. | `handlerlatencyybtserverTabletServerService_Write` | Time towrite the PostgreSQL system tables (during DDL). This metric includes the count or number of writes. | `handlerlatencyybmasterMasterDdl_CreateTable` | Time to create a table (during DDL). This metric includes the count of create table operations. | `handlerlatencyybmasterMasterDdl_DeleteTable` | Time to delete a table (during DDL). This metric includes the count of delete table operations. <!-- | Metrics | Unit | Type | Description | | : | : | : | :- | | `handlerlatencyybmasterMasterClient_GetTabletLocations` | The number of microseconds spent on fetching the replicas from the master servers. This metric includes the number of times the locations of the replicas are fetched from the master server. | | `handlerlatencyybtserverTabletServerService_Read` | The time in microseconds toread the PostgreSQL system tables (during DDL). This metric includes the count or number of reads. | | `handlerlatencyybtserverTabletServerService_Write` | The time in microseconds towrite the PostgreSQL system tables (during DDL). This metric includes the count or number of writes. | | `handlerlatencyybmasterMasterDdl_CreateTable` | The time in microseconds to create a table (during DDL). This metric includes the count of create table operations.| | `handlerlatencyybmasterMasterDdl_DeleteTable` | The time in microseconds to delete a table (during DDL). This metric includes the count of delete table operations.| --> These metrics can be aggregated for nodes across the entire cluster using appropriate aggregations.