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

+++ title = "`basicresult(failuretype<T> &&)`" description = "Implicit error-from-failure-type-sugar move constructor. Available if `predicate::enablemakeerrorcodecompatible_conversion<void, T, void>` is true, or `T` is `void`. Constexpr, triviality and noexcept propagating." categories = ["constructors", "implicit-constructors", "tagged-constructors"] weight = 532 +++ Implicit error-from-failure-type-sugar move constructor used to disambiguate the construction of the error type. Note that if `T = void`, `errortype` will be default constructed. Calls {{% api "void onresultmoveconstruction(T *, U &&) noexcept" %}} with `this` and `failure_type<T> &&`. Requires: `predicate::enablemakeerrorcodecompatible_conversion<void, T, void>` is true, or `T` is `void`. Complexity: Same as for the `errortype` constructor which accepts `T`, or the `errortype` default constructor if `T` is `void`. Constexpr, triviality and noexcept of underlying operations is propagated.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: operator-sdk_version.md

title: "operator-sdk version" Print the operator-sdk version Print the operator-sdk version ``` operator-sdk version [flags] ``` ``` operator-sdk version ``` ``` -h, --help help for version ``` ``` --plugins strings plugin keys to be used for this subcommand execution --verbose Enable verbose logging ``` -
Project: KUDO (App Definition and Development / Application Definition & Image Build)
File: 0007-cli-generation.md

kep-number: 7 title: CLI Skeleton generator short-desc: Generate operator skeletons for operator developers authors: "@djannot" owners: "@djannot" "@fabianbaier" editor: "@fabianbaier" creation-date: 2019-04-18 status: provisional * Created by In order to develop a new operator using KUDO, you always need to create several `Plans` (`deploy`, `update`, `upgrade`, ...) and for each plan to create several `Phases`, `Steps` and `Tasks`. Also, any Operator will have a `Task` in the `deploy` plan to create similar Kubernetes objects (`StatefulSets`, `Services`, ...). A Skeleton generator could create `yaml` templates with the common `Plans`, `Phases`, `Steps` and `Tasks`. This generator should be part of the KUDO CLI. With the new proposed approach based on dynamic CRDs, these elements will be defined in separated `yaml` files, so it will be even easier to create a Skeleton generator with a clear directory structure. Having a Skeleton generator would help people getting started faster when they want to develop a new KUDO operator. It would also make the operator created using this generator more readable as they would follow a naming convention for the different objects (`StatefulSets`, `Services`, ...).
Project: KICS (Provisioning / Security & Compliance)
File: 80f93444-b240-4ebb-a4c6-5c40b76c04ea.md

title: PSP Allows Sharing Host IPC hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 80f93444-b240-4ebb-a4c6-5c40b76c04ea Query name: PSP Allows Sharing Host IPC Platform: Kubernetes Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: Pod Security Policy allows containers to share the host IPC namespace<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: hostIPC: true seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: hostIPC: false seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny ```
Project: Pulsar (App Definition and Development / Streaming & Messaging)
File: pip-318.md

Apache Pulsar is supported which is a key-based data retention mechanism. Currently, we retain all null-key messages during topic compaction, which I don't think is necessary because when you use topic compaction, it means that you want to retain the value according to the key, so retaining null-key messages is meaningless. Additionally, retaining all null-key messages will double the storage cost, and we'll never be able to clean them up since the compacted topic has not supported the retention policy yet. In summary, I don't think we should retain null-key messages during topic compaction. In order to avoid introducing break changes to release version, we need to add a configuration to control whether to retain null-key messages during topic compaction. If the configuration is true, we will retain null-key messages during topic compaction, otherwise, we will not retain null-key messages during topic compaction. Add config to broker.conf/standalone.conf ```properties topicCompactionRetainNullKey=false ``` Make `topicCompactionRetainNullKey=false` default in the 3.2.0. Cherry-pick it to a branch less than 3.2.0 make `topicCompactionRetainNullKey=true` default. Delete the configuration `topicCompactionRetainNullKey` in 3.3.0 and don't supply an option to retain null-keys. Make `topicCompactionRetainNullKey=true` in broker.conf/standalone.conf. Make `topicCompactionRetainNullKey=false` in broker.conf/standalone.conf. Mailing List discussion thread: https://lists.apache.org/thread/68k6vrghfp3np601lrfx5mbfmghbbrjh Mailing List voting thread: https://lists.apache.org/thread/36rfmvz5rchgnvqb2wcq4wb64k6st90p
Project: Vault (Provisioning / Key Management)
File: components.md

Components can range from small, highly reusable "atoms" to large units with lots of business logic specific to one workflow or action. In any scenario, these are things to keep in mind while developing components for the Vault UI. Please note that these guidelines are aspirational and you will see instances of antipatterns in the codebase. Many of these should be updated as we move forward. As with any ruleset, sometimes it is appropriate to break the rule. Route templates should render a `Page` component, which includes breadcrumbs, page title, and then renders whatever else should be on the page (often another scoped component). This component should be named something like `<Page::CreateFoo />` and you can create it like `ember g component page/create-foo -gc`. The Route should pass the model hook data into the component in the template. However, if the model hook returns multiple objects they should each be passed into the Page component as separate args. For example: within a route's template whose model hook returns two different data models, the route's template would look like: ```hbs <Page::CreateFoo @config={{this.model.config}} @foo={{this.model.foo}} /> ``` Generally, we want the burden of deciding whether a component should render to live in the parent rather than the child. Readability - it's easier to tell at a glance that a component will sometimes not render if the `{{#if}}` block is on the parent. Performance - when a component is in charge of its own rendering logic, the component's lifecycle hooks will fire whether or not the component will render on the page. This can lead to degraded performance, for example if hundreds of the same component are listed on the page. When developing components, make sure to: Add splattributes to the top level, eg: ```hbs <div data-test-stuff ...attributes>Stuff!</div> ``` Consider passing splattributes or yielding something instead of passing a new arg Instead of: passing a new arg that controls a style ``` <Block @title="Example" @hasPadding={{false}} /> ``` Prefer: passing a class or helper that controls a style ``` <Block @title="Example" class="padding-0" /> ``` Minimize the number of args that must be passed Instead of: Passing in separate args that are both required for icon to render ``` <Block @title="Example" @hasIcon={{true}} @iconName="key" /> ``` Prefer: One arg that is rendered if present ``` <Block @title="Example" @icon="key" /> ```
Project: KICS (Provisioning / Security & Compliance)
File: bb0db090-5509-4853-a827-75ced0b3caa0.md

title: Google Storage Bucket Level Access Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: bb0db090-5509-4853-a827-75ced0b3caa0 Query name: Google Storage Bucket Level Access Disabled Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: Google Storage Bucket Level Access should be enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="20 6" resource "googlestoragebucket" "positive1" { name = "image-store.com" location = "EU" force_destroy = true uniformbucketlevel_access = false website { mainpagesuffix = "index.html" notfoundpage = "404.html" } cors { origin = ["http://image-store.com"] method = ["GET", "HEAD", "PUT", "POST", "DELETE"] response_header = ["*"] maxageseconds = 3600 } } resource "googlestoragebucket" "positive2" { name = "image-store.com" location = "EU" force_destroy = true website { mainpagesuffix = "index.html" notfoundpage = "404.html" } cors { origin = ["http://image-store.com"] method = ["GET", "HEAD", "PUT", "POST", "DELETE"] response_header = ["*"] maxageseconds = 3600 } } ``` ```tf title="Negative test num. 1 - tf file" resource "googlestoragebucket" "negative1" { name = "image-store.com" location = "EU" force_destroy = true uniformbucketlevel_access = true website { mainpagesuffix = "index.html" notfoundpage = "404.html" } cors { origin = ["http://image-store.com"] method = ["GET", "HEAD", "PUT", "POST", "DELETE"] response_header = ["*"] maxageseconds = 3600 } } ```
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: software-emulation.md

By default KubeVirt uses the `/dev/kvm` device to enable hardware emulation. This is almost always desirable, however there are a few exceptions where this approach is problematic. For instance, running KubeVirt on a cluster where the nodes do not support hardware emulation. In the same way, by default KubeVirt requires presence of `/dev/vhost-net` in case that at least one network interface model is virtio (note: if the NIC model is not explicitly specified, by default virtio is chosen). If `useEmulation` is enabled, `qemu` will be used for software emulation, in case that hardware emulation via `/dev/kvm` is unavailable. QEMU userland virtio NIC emulation will be used for virtio-net interfaces, in case that in-kernel virtio-net backend emulation via `/dev/vhost-net` is unavailable. If `useEmulation` is disabled, and a required hardware emulation device is unavailable (`/dev/kvm`, or `/dev/vhost-net` for a VirtualMachine which uses virtio for at least one interface), the VirtualMachine will fail to start and an error will be reported. Note that software emulation, when enabled, is only used as a fallback when hardware emulation is not available. Hardware emulation is always attempted first, regardless of the value of the `useEmulation`. Enabling software emulation is a cluster-wide setting, and is activated by editing the `KubeVirt` CR as follows: ```bash cluster-up/kubectl.sh --namespace kubevirt edit kubevirt kubevirt ``` Add the following snippet to the spec: ```yaml spec: configuration: developerConfiguration: useEmulation: true ```
Project: YDB (App Definition and Development / Database)
File: options_multiple.md

If several of the above options are set simultaneously in the command line, the CLI returns an error asking you to specify only one: ``` $ {{ ydb-cli }} --use-metadata-credentials --iam-token-file ~/.ydb/token scheme ls More than one auth method were provided via options. Choose exactly one of them Try "--help" option for more info. ```
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_upgrade.md

title: "Command - devspace upgrade" sidebar_label: devspace upgrade Upgrade the DevSpace CLI to the newest version ``` devspace upgrade [flags] ``` ``` Upgrades the DevSpace CLI to the newest version ``` ``` -h, --help help for upgrade --version string The version to update devspace to. Defaults to the latest stable version available ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --disable-profile-activation If true will ignore all profile activations --inactivity-timeout int Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems (default 180) --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile strings The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified --profile-parent strings One or more profiles that should be applied before the specified profile (e.g. devspace dev --profile-parent=base1 --profile-parent=base2 --profile=my-profile) --profile-refresh If true will pull and re-download profile parent sources --restore-vars If true will restore the variables from kubernetes before loading the config --save-vars If true will save the variables to kubernetes after loading the config --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context DEPRECATED: Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) --vars-secret string The secret to restore/save the variables from/to, if --restore-vars or --save-vars is enabled (default "devspace-vars") ```
Project: KICS (Provisioning / Security & Compliance)
File: 34664094-59e0-4524-b69f-deaa1a68cce3.md

title: Security Contact Email hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 34664094-59e0-4524-b69f-deaa1a68cce3 Query name: Security Contact Email Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Best Practices URL: Security Contact Email should be defined<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "azurermsecuritycenter_contact" "positive" { phone = "+1-555-555-5555" alert_notifications = true alertstoadmins = true } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermsecuritycenter_contact" "negative" { email = "contact@example.com" phone = "+1-555-555-5555" alert_notifications = true alertstoadmins = true } ```
Project: YDB (App Definition and Development / Database)
File: flatten_columns.md

Converts a table where all columns must be structures to a table with columns corresponding to each element of each structure from the source columns. The names of the source column structures are not used and not returned in the result. Be sure that the structure element names aren't repeated in the source columns. Example ```sql SELECT x, y, z FROM ( SELECT AsStruct( 1 AS x, "foo" AS y), AsStruct( false AS z) ) FLATTEN COLUMNS; ```
Project: CloudNativePG (App Definition and Development / Database)
File: networking.md

CloudNativePG assumes the underlying Kubernetes cluster has the required connectivity already set up. Networking on Kubernetes is an important and extended topic; please refer to the for further information. If you're following the quickstart guide to install CloudNativePG on a local KinD or K3d cluster, you should not encounter any networking issues as neither platform will add any networking restrictions by default. However, when deploying CloudNativePG on existing infrastructure, networking restrictions might be in place that could impair the communication of the operator with PostgreSQL clusters. Specifically, existing might restrict certain types of traffic. Or, you might be interested in adding network policies in your environment for increased security. As mentioned in the , please ensure the operator can reach every cluster pod on ports 8000 and 5432, and that pods can connect to each other. Following the quickstart guide or using helm chart for deployment will install the operator in a dedicated namespace (`cnpg-system` by default). We recommend that you create clusters in a different namespace. The operator must be able to connect to cluster pods. This might be precluded if there is a `NetworkPolicy` restricting cross-namespace traffic. For example, the contains an example policy denying all ingress traffic by default. If your local kubernetes setup has this kind of restrictive network policy, you will need to create a `NetworkPolicy` to explicitly allow connection from the operator namespace and pod to the cluster namespace and pods. You can find an example in the file in this repository. Please note, you'll need to adjust the cluster name and cluster namespace to match your specific setup, and also the operator namespace if it is not the default namespace. While from another cluster or when using the `externalClusters` section, ensure connectivity among all clusters, object stores, and namespaces involved. Again, we refer you to the for setup information.
Project: KICS (Provisioning / Security & Compliance)
File: fe286195-e75c-4359-bd58-00847c4f855a.md

title: OSS Bucket Allows Put Action From All Principals hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fe286195-e75c-4359-bd58-00847c4f855a Query name: OSS Bucket Allows Put Action From All Principals Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Access Control URL: OSS Bucket should not allow put action from all principals, as to prevent leaking private information to the entire internet or allow unauthorized data tampering/deletion. This means the 'Effect' must not be 'Allow' when the 'Action' contains 'Put', for all Principals.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "alicloudossbucket" "bucket-policy4" { bucket = "bucket-4-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObjectAcl", "oss:PutObject" ], "Effect": "Allow", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="5" resource "alicloudossbucket" "bucket-policy5" { bucket = "bucket-5-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObject", "oss:RestoreObject" ], "Effect": "Allow", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudossbucket" "bucket-policy1" { bucket = "bucket-1-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:AbortMultipartUpload" ], "Effect": "Allow", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 2 - tf file" resource "alicloudossbucket" "bucket-policy2" { bucket = "bucket-2-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObjectAcl", "oss:PutObject" ], "Effect": "Allow", "Principal": [ "20214760404935xxxx" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ``` ```tf title="Negative test num. 3 - tf file" resource "alicloudossbucket" "bucket-policy3" { bucket = "bucket-3-policy" acl = "private" policy = <<POLICY {"Statement": [ { "Action": [ "oss:PutObjectAcl", "oss:PutObject" ], "Effect": "Deny", "Principal": [ "*" ], "Resource": [ "acs:oss:*:174649585760xxxx:examplebucket" ] } ], "Version":"1"} POLICY } ```
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.2.9.1.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Major | Incorporate Aliyun OSS file system implementation* Aliyun OSS is widely used among Chinas cloud users and this work implemented a new Hadoop compatible filesystem AliyunOSSFileSystem with oss scheme, similar to the s3a and azure support. | Major | AliyunOSS: backport Aliyun OSS module to branch-2* Aliyun OSS is widely used among Chinas cloud users and this work implemented a new Hadoop compatible filesystem AliyunOSSFileSystem with oss:// scheme, similar to the s3a and azure support. | Major | RBF: Document Router and State Store metrics* This JIRA makes following change: Change Router metrics context from 'router' to 'dfs'. | Major | RBF: Add ACL support for mount table* Mount tables support ACL, The users won't be able to modify their own entries (we are assuming these old (no-permissions before) mount table with owner:superuser, group:supergroup, permission:755 as the default permissions). The fix way is login as superuser to modify these mount table entries. | Major | Ensure only NM classpath in 2.x gets TSv2 related hbase jars, not the user classpath* Ensure only NM classpath in 2.x gets TSv2 related hbase jars, not the user classpath. | Major | backport HADOOP-15086 rename fix to branch-2* [WASB] Fix Azure implementation of Filesystem.rename to ensure that at most one operation succeeds when there are multiple, concurrent rename operations targeting the same destination file. | Major | AliyunOSS: Support multi-thread pre-read to improve sequential read from Hadoop to Aliyun OSS performance* Support multi-thread pre-read in AliyunOSSInputStream to improve the sequential read performance from Hadoop to Aliyun OSS. | Major | RBF: Fix doc error setting up client* Fix the document error of setting up HFDS Router Federation | Minor | RBF: Use the ZooKeeper as the default State Store* Change default State Store from local file to ZooKeeper. This will require additional zk address to be configured.
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: monitoring-guidelines.md

The KubeVirt metrics should align with the Kubernetes metrics names. The KubeVirt Users should have the same experience when searching for a node, container, pod and virtual machine metrics. Naming requirements: Check if a similar Kubernetes metric, for node, container or pod, exists and try to align to it. KubeVirt metric for a running VM should have a `kubevirtvmi` prefix For Example, see the following Kubernetes network metrics: nodenetworkreceivepacketstotal nodenetworktransmitpacketstotal containernetworkreceivepacketstotal containernetworktransmitpacketstotal The KubeVirt metrics for vmi should be: kubevirt_vminetworkreceivepacketstotal kubevirt_vminetworktransmitpacketstotal The Prometheus recording rules appear in Prometheus as metrics. In order to easily identify the KubeVirt recording rules, they should have a `kubevirt_` prefix. When creating a KubeVirt alert rule, please see the following : Use when doing calculations. Create an alert runbook at . Alert rule must include `runbook_url` with the link to your runbook from step #2. Alert rule must include `severity`. One of: `critical`, `warning`, `info`. NOTE: Critical alerts - When the service is down and you loss critical functionality, an action is required immediately. Warning alerts - When an alert require user intervention. A more serious issue may develop if this is not resolved soon. Info alerts - When a minor problem has been detected. It should be resolved relatively soon and not ignored. Alert `message` must be verbose, since it is being propagated to the file, when running `make-generate`.