cwielenb/CNCF-Dataset huggingface dataset:
Project: The Update Framework (TUF) (Provisioning / Security & Compliance)
File: 2022-02-21-release-1-0-0.md

title: "Python-TUF reaches version 1.0.0" author: Jussi Kukkonen and Lukas Phringer The Python-TUF community is proud to announce the release of Python-TUF 1.0.0. The release, which is available on and , introduces new stable and more ergonomic APIs. <img align="right" src="../../../tuf-icon-200.png" width="200"/> Python-TUF is the reference implementation of [The Update Framework](https://theupdateframework.io/) specification, an open source framework for securing content delivery and updates. It protects against various types of supply chain attacks and provides resilience to compromise. For the past 7 releases the project has introduced new designs and implementations, which have gradually formed two new stable APIs: : A client API that offers a robust internal design providing implementation safety and flexibility to application developers. : A low-level interface for both consuming and creating TUF metadata. Metadata API is a flexible and easy-to-use building block for any higher level tool or library. Python-TUF 1.0.0 is the result of a comprehensive rewrite of the project, removing several hard to maintain modules and replacing them with safer and easier to use APIs: The project was reduced from 4700 lines of hard to maintain code to 1400 lines of modern, maintainable code The implementation details are now easier to reason about, which should accelerate future improvements on the project Metadata API provides a solid base to build other tools on top of as proven by the ngclient implementation and the [repository code examples](https://github.com/theupdateframework/python-tuf/tree/develop/examples/repo_example) Both new APIs are highly extensible and allow application developers to include custom network stacks, file storage systems or public-key cryptography algorithms, while providing easy-to-use default implementations With this foundation laid, Python-TUF developers are currently planning next steps. At the very least, you can expect improved repository side tooling, but we're also open to new ideas. Pop in to on CNCF Slack or and lets talk.
Project: VoltDB (App Definition and Development / Database)
File: RunAnExampleInACluster.md

VoltDB requires you to initialize a root directory before starting a new cluster. If you want to run with no data redundancy (kfactor=0) you do not need a configuration file. You can log into each node and run: ```bash voltdb init --force ``` If you want to run with data redundancy you will need a configuration file that specifies the redundancy. This example configures two copies of all the data (kfactor=1): ```xml <?xml version="1.0"?> <deployment> <cluster kfactor="1"/> <httpd enabled="true"> <jsonapi enabled="true" /> </httpd> </deployment> ``` Save this file as config.xml, or use the HOWTOS/deployment-file-examples/deployment-with-redundancy.xml file provided in the VoltDB kit. To initialize with a config file, log into each node and run: ```bash voltdb init --force --config=config.xml ``` To start a 3 node cluster you will provide the server count using --count= or -c. On your 3 servers, `voltserver1`, `voltserver2`, `voltserver3` and run: ```bash voltdb start -c 3 -H voltserver1,voltserver2,voltserver3 & ``` The servers will all connect to each other and form a running cluster. On all machines you should see the `Server Completed Initialization.` log message. For the purposes of this example, we will use 3 servers: `voltserver1`, `voltserver2`, and `voltserver3`. On any machines where you're going to run the client, you're going to need to edit the `run.sh` file. Find the line that says: ``` SERVERS="localhost" ``` And change it to say: ``` SERVERS="voltserver1,voltserver2,voltserver3" ``` Note that this is equivalent to: ``` SERVERS="voltserver1:21212,voltserver2:21212,voltserver3:21212" ``` If your servers are configured with different ports, you would need to change this, but the defaults should be fine for almost all cases. Now save the `run.sh` file. Run the client script: ```bash ./run.sh client ```
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: feature-flags.md

Some Lagoon features can be controlled by setting feature flags. This is designed to assist users and administrators to roll out new platform features in a controlled manner. The following environment variables can be set on an environment or project to toggle feature flags. | Environment Variable Name | Active scope | Version introduced | Version removed | Default Value | Description | | | | | | | | | `LAGOONFEATUREFLAGROOTLESSWORKLOAD` | `global` | 2.2.0 | - | `disabled` | Set to `enabled` to set a non-root pod security context on the pods in this environment or project.<br><br>This flag will eventually be deprecated, at which point non-root workloads will be enforced. | | `LAGOONFEATUREFLAGISOLATIONNETWORKPOLICY` | `global` | 2.2.0 | - | `disabled` | Set to `enabled` to add a default namespace isolation network policy to each environment on deployment.<br><br>This flag will eventually be deprecated, at which point the namespace isolation network policy will be enforced.<br><br>NOTE: enabling and then disabling this feature will not_ remove any existing network policy from previous deployments. Those must be removed manually. | Feature flags may also be controlled at the cluster level. There is support for this in the . For each feature flag there are two flavours of values which can be set: `default` and `force`. `default` controls the default policy for environments deployed to the cluster, but can be overridden at the project or environment level by the environment variables documented above. `force` also controls the policy for environments deployed to the cluster, but cannot be overridden by the environment variables documented above.
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: bot.md

The bot is configured via and some other GitHub . By default, users with write access to the repo is allowed to use the comments, the file is for adding additional members who do not have access and want to contribute to the issue triage. Comment commands: Write the word `/needsInvestigation` in a comment, and the bot will add the corresponding label. Write the word `/needsMoreInfo` in a comment, and the bot will add the correct label and standard message. Write the word `/duplicate #<number>` to have `type/duplicate` label, the issue number is required for remind where is the other issue. Write the word `/type/` in a comment, and the bot will add the corresponding label `/type/*`. Write the word `/area/` in a comment, and the bot will add the corresponding label `/area/*`. Write the word `/priority/` in a comment, and the bot will add the corresponding label `/priority/*`. The `*` mention above represent a specific word. Please read the details about label category in Label commands: Add label `bot/question` the bot will close with standard question message and add label `type/question` Add label `bot/needs more info` for bot to request more info (or use comment command mentioned above) Add label `bot/no new info` for bot to close an issue where we asked for more info but has not received any updates in at least 14 days. Add label `bot/duplicate` to have `type/duplicate` label & the bot will close issue with an appropriate message. Add label `bot/close feature request` for bot to close a feature request with standard message. Assign: When you participating in an issue area, and you want to assign to others to distribute this task or self-assign to give a solution. You can use the comment bellow. Write the word `/assign githubname` in a comment, the robot will automatically assign to the corresponding person. Specially, write the word `/assign` in a comment, you can assgin this task to yourself.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_regional_disk.md

+++ title = "googlecomputeregional_disk resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputeregional_disk" identifier = "inspec/resources/gcp/googlecomputeregionaldisk.md googlecomputeregionaldisk resource" parent = "inspec/resources/gcp" +++ A `googlecomputeregional_disk` is used to test a Google Regional Disk resource ```ruby describe googlecomputeregionaldisk(project: 'chef-gcp-inspec', name: 'mydisk', region: 'region') do it { should exist } its('type') { should match 'pd-standard' } end describe.one do googlecomputeregionaldisk(project: 'chef-gcp-inspec', name: 'mydisk', region: 'region').labels.each_pair do |key, value| describe key do it { should cmp "environment" } end end end describe googlecomputeregional_disk(project: 'chef-gcp-inspec', name: 'nonexistent', region: 'region') do it { should_not exist } end ``` Properties that can be accessed from the `googlecomputeregional_disk` resource: `label_fingerprint` : The fingerprint used for optimistic locking of this resource. Used internally during updates. `creation_timestamp` : Creation timestamp in RFC3339 text format. `description` : An optional description of this resource. Provide this property when you create the resource. `id` : The unique identifier for the resource. `name` : Name of the resource. Provided by the client when the resource is created. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash. `size_gb` : Size of the persistent disk, specified in GB. You can specify this field when creating a persistent disk using the sourceImage or sourceSnapshot parameter, or specify it alone to create an empty persistent disk. If you specify this field along with sourceImage or sourceSnapshot, the value of sizeGb must not be less than the size of the sourceImage or the size of the snapshot. `physicalblocksize_bytes` : Physical block size of the persistent disk, in bytes. If not present in a request, a default value is used. Currently supported sizes are 4096 and 16384, other sizes may be added in the future. If an unsupported value is requested, the error message will list the supported values for the caller's project. `type` : URL of the disk type resource describing which disk type to use to create the disk. Provide this when creating the disk. `region` : A reference to the region where the disk resides. `replica_zones` : A reference to the zones where the disk resides. Ensure the is enabled for the current project.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: no-top-level-material-ui-4-imports.md

Forbid top level import from Material UI v4 packages. Add the rules as follows, it has no options: ```js '@backstage/no-top-level-material-ui-4-imports': 'error' ``` Automatically fixes imports from named to default imports. This will help you comply with and make migrating to Material UI v5 easier. ```tsx import { Box, Typography } from '@material-ui/core'; ``` ```tsx import Box from '@material-ui/core'; ``` ```tsx import { Box, DialogActions, DialogContent, DialogTitle, Grid, makeStyles, } from '@material-ui/core'; ``` ```tsx import Typography from '@material-ui/core/Typography'; import Box from '@material-ui/core/Box'; ``` This rule provides automatic fixes for the imports, but it has some known issues: The fix will handle correctly 3 groups of imports: Any import from related to styles (i.e `makeStyles`, `styled`, `WithStyles`) will be auto fixed to the `@material-ui/core/styles` import. Any import with `Props` suffix will be auto fixed to actual component for example `DialogProps` will be imported from `@material-ui/core/Dialog`. Any other import will be considered as a component import and will be auto fixed to the actual component import. This means that some types of imports without `Props` suffix will be wrongly auto fixed to the component import, for example this fix will be wrong: ```diff import { Alert, Color } from '@material-ui/lab'; import Alert from '@material-ui/lab/Alert'; import Color from '@material-ui/lab/Color'; // this import is wrong ``` The correct import should look like this: ```diff import { Alert, Color } from '@material-ui/lab'; import Alert, {Color} from '@material-ui/lab/Alert'; ``` Because `Color` is a type coming from the Alert component. Some components do not have a default export, for example `@material-ui/pickers/DateTimePicker` does not have a default export, so the fix will not work for these cases. The fix will be wrong for this import: ```diff import { DateTimePicker } from '@material-ui/pickers'; import DateTimePicker from '@material-ui/pickers/DateTimePicker'; // this default import does not exist ``` The correct import should look like this: ```diff import { DateTimePicker } from '@material-ui/pickers'; import { DateTimePicker } from '@material-ui/pickers/DateTimePicker'; // this is the correct import ```
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: aws-fargate-deployment.md

There are any number of ways to deploy backstage containers on AWS. One of the simplest from a management and ops perspective is to leverage AWS Fargate and Aurora PostgreSQL, where both the container orchestration and database clusters are AWS managed services. However, to use them properly there are a large number of supporting resources (VPCs, Security Groups, Load Balancers, Certificate, etc) required. One approach is to use to simplify and automate the creation of the entire infrastructure stack along with automating the build and deploy of the container. Check out the repository, for a ready to use CDK application for deploying your custom Backstage app onto AWS ECS Fargate and Aurora.
Project: Docker Compose (App Definition and Development / Application Definition & Image Build)
File: compose_ls.md

<!MARKERGENSTART--> List running compose projects | Name | Type | Default | Description | |:-|:|:--|:-| | `-a`, `--all` | | | Show all stopped Compose projects | | `--dry-run` | | | Execute command in dry run mode | | `--filter` | `filter` | | Filter output based on conditions provided | | `--format` | `string` | `table` | Format the output. Values: [table \| json] | | `-q`, `--quiet` | | | Only display IDs | <!MARKERGENEND--> Lists running Compose projects
Project: MongoDB (App Definition and Development / Database)
File: poetry_execution.md

We frequently encounter Python errors that are caused by a python dependency author updating their package that is backward breaking. The following tickets are a few examples of this happening: , , , , , , , , and . We have always known this was a problem and have known there was a way to fix it. We finally had the bandwidth to tackle this problem. First, we wanted to test out using poetry so we converted mongo-container project to use poetry . This showed promise and we considered this a green light to move forward on converting the server python to use poetry. Before we could start the project we had to upgrade python to a version that was not EoL. This work is captured in . We upgraded python to 3.10 on every system except windows. Windows could not be upgraded due to a test problem relating to some cipher suites . After the prework was done we wrote, tested, and merged which is converting the mongo python dependencies to poetry. This ticket had an absurd amount of dependencies and required a significant amount of patch builds. The total number of changes was pretty small but it affected a lot of different projects. Knowing there was a lot this touched we expected to see some bugs and were quick to try to fix them. Some of these were caught before merge and some were caught after. required the build team to rebuild python on macosx arm. This was caught before merging. found that poetry broke the spawnhost script. This was caught after merge. and were found by sys-perf since they run their own build and do not use the standard build process. Therefore it was very hard to test for this one. This was caught post merge. found that poetry broke mongo tooling metrics collection (not OTel). This was only found since an engineer on the team saw this bug in the code. This was caught post merge. Overall, when changing something so foundational it is inevitable that some things will break.
Project: KICS (Provisioning / Security & Compliance)
File: 235236ee-ad78-4065-bd29-61b061f28ce0.md

title: Containers With Sys Admin Capabilities hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 235236ee-ad78-4065-bd29-61b061f28ce0 Query name: Containers With Sys Admin Capabilities Platform: Kubernetes Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: Containers should not have CAPSYSADMIN Linux capability<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="12" apiVersion: v1 kind: Pod metadata: name: pod4 spec: containers: name: app image: images.my-company.example/app:v4 securityContext: allowPrivilegeEscalation: false capabilities: add: ["SYS_ADMIN"] resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" name: log-aggregator image: images.my-company.example/log-aggregator:v6 securityContext: allowPrivilegeEscalation: false resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: name: app image: images.my-company.example/app:v4 securityContext: allowPrivilegeEscalation: false resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" name: log-aggregator image: images.my-company.example/log-aggregator:v6 securityContext: allowPrivilegeEscalation: false resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" ```
Project: Tetragon (Provisioning / Security & Compliance)
File: LICENSE.md

Copyright (c) 2013-2020, Frank Schroeder All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: StarRocks (App Definition and Development / Database)
File: SHOW_STORAGE_VOLUMES.md

displayed_sidebar: "English" Shows the storage volumes in your StarRocks cluster. This feature is supported from v3.1. :::tip This operation does not require privileges. ::: ```SQL SHOW STORAGE VOLUMES [ LIKE '<pattern>' ] ``` | Parameter | Description | | - | - | | pattern | The pattern used to match the storage volumes. | | Return | Description | | -- | - | | Storage Volume | The name of the storage volume. | Example 1: Show all storage volumes in the StarRocks cluster. ```Plain MySQL > SHOW STORAGE VOLUMES; +-+ | Storage Volume | +-+ | mys3volume | +-+ 1 row in set (0.01 sec) ```
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: v1.1.0.md

title: v1.1.0 weight: 998999000 To disable fact gathering by default for your operator, you will need to add the following entry to the manager container in`config/manager/manager.yaml`: ```yaml env: name: ANSIBLE_GATHERING value: explicit ``` See for more details. The scorecard-test-kuttl image is updated to use kuttl:v0.5.2 as the base image. See for more details.
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-pattern-delete.md

layout: default title: mesheryctl-pattern-delete permalink: reference/mesheryctl/pattern/delete redirect_from: reference/mesheryctl/pattern/delete/ type: reference display-title: "false" language: en command: pattern subcommand: delete Delete pattern file delete pattern file will trigger deletion of the pattern file <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl pattern delete [flags] </div> </pre> delete a pattern file <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl pattern delete [file | URL] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -f, --file string Path to pattern file -h, --help help for delete </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -t, --token string Path to token file default from current context -v, --verbose verbose output </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: Meshery (Provisioning / Automation & Configuration)
File: kyverno-operator.md

layout: integration title: Kyverno Operator subtitle: Collaborative and visual infrastructure as code for Kyverno Operator image: /assets/img/integrations/kyverno-operator/icons/color/kyverno-operator-color.svg permalink: extensibility/integrations/kyverno-operator docURL: https://docs.meshery.io/extensibility/integrations/kyverno-operator description: integrations-category: Provisioning integrations-subcategory: Security & Compliance registrant: Artifact Hub components: name: kyverno-operator colorIcon: assets/img/integrations/kyverno-operator/components/kyverno-operator/icons/color/kyverno-operator-color.svg whiteIcon: assets/img/integrations/kyverno-operator/components/kyverno-operator/icons/white/kyverno-operator-white.svg description: featureList: [ "Use Meshery&ldquos GitHub Actions to test policies and validate resources without need for the Kyverno CLI.", "Use Meshery with Kyverno to inspect image metadata and match resources using label selectors and wildcards.", "Report Kyverno policy violations alongside your existing Meshery policy reports. " ] howItWorks: "Block non-conformant resources" howItWorksDetails: "Using MeshMap, apply best practice design templates for admission control over non-conformant resources." language: en list: include type: extensibility category: integrations