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

Generating tasks is a way to dynamically create tasks in Evergreen builds. This is done via the evergreen command. Task generation allow us to do things like dynamically split a task into sub-tasks that can be run in parallel, or generate sub-tasks to run against different mongodb versions. Task generation is typically done with the tool. Refer to its for details on how it works. In order to generate a task, we typically create a placeholder task. By convention the name of these tasks should end in "\_gen". Most of the time, generated tasks should inherit the which configures the required dependencies. The placeholder tasks needs to have the "generate resmoke tasks" function as one of its `commands`. This is how the `mongo-task-generator` knows that the task needs to be generated. You can also add `vars` to the function call to configure how the task will generated. You can refer to the documentation for details on what options are available. Once a placeholder task in defined, you can reference it just like a normal task. Task generation is performed as a 2-step process. The first step is to generator the configuration for the generated tasks and send that to evergreen to actually create the tasks. This is done by the `version_gen` task using the `mongo-task-generator` tool. This only needs to be done once for the entire version and rerunning this task will result in a no-op. The tasks will be generated in an "inactive" state. This allows us to generate all available tasks, regardless of whether they are meant to be run or not. This way if we choose to run additional tasks in the future, they will exist to be run. This step will also hide all the placeholder tasks into a display task called `generator_tasks` in each build variant. Once task generation is completed, the user should perform actions on the generated tasks instead of the placeholder tasks, we encourage this by hiding the placeholder tasks from view. After the tasks have been generated, the placeholder tasks are free to run. The placeholder tasks simply find the task generated for them and mark it activated. Since generated tasks are created in the "inactive" state, this will activate any generated tasks whose placeholder task runs. This enables users to select tasks to run on the initial task selection page even though the tasks have not yet been generated. Note: While this 2-step process allows a similar user experience to working with normal tasks, it does create a few UI quirks. For example, evergreen will hide "inactive" tasks in the UI, as a result, a task might disappear for some time after being created, until the placeholder task runs and activates it.
Project: Meshery (Provisioning / Automation & Configuration)
File: prometheus.md

layout: integration title: Prometheus subtitle: Meshery provides performance reports, including performance test results, node resource metrics etc. so that operators may easily understand the overhead of their service meshs control plane and data plane in context of the overhead incurred on nodes running within the cluster. In order to generate performance test reports of service meshes and their workloads, Meshery uses Grafana and/or Prometheus as visualization and metrics systems, respectively. This guide outlines the requirements necessary for Meshery to connect to these systems. The steps may vary depending upon the service mesh and its configuration. image: /assets/img/integrations/prometheus/icons/color/prometheus-color.svg permalink: extensibility/integrations/prometheus docURL: https://docs.meshery.io/extensibility/integrations/prometheus description: integrations-category: Observability and Analysis integrations-subcategory: Monitoring registrant: Artifact Hub components: featureList: [ "Native support for PromQL", "Create custom charts with your own Prometheus queries", "Keep charts in-sync with Mesherys panel viewer" ] howItWorks: "Meshery provides performance reports, including performance test results, node resource metrics etc. so that operators may easily understand the overhead of their service meshs control plane and data plane in context of the overhead incurred on nodes running within the cluster. In order to generate performance test reports of service meshes and their workloads, Meshery uses Grafana and/or Prometheus as visualization and metrics systems, respectively. This guide outlines the requirements necessary for Meshery to connect to these systems. The steps may vary depending upon the service mesh and its configuration." howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: v5.2.0.en.md

Added support for specifying username in Redis authentication. The bcrypt work factor is limited to the range 5-10, because higher values consume too much CPU resources. Bcrypt library is updated to allow parallel hash evaluation. Disabled the Erlang VM Prometheus exporter by default to improve performance and security. Enhanced broker metrics collection and export by adding new metrics for messages, overload protection, authorization, authentication, and improving naming consistency for OpenTelemetry. Added fast error handling for undefined passwords in various authentication backends. This improves the consistency and user-friendliness of the authentication process. Improve some error reasons when parsing invalid packets. Fixed a crash that occurred when setting the `ssl_options.ciphers` configuration option to an empty string (""). Improves the error handling and testing of SQL functions in the rule engine when rule functions receive bad arguments. Examples and documentation for /api/v5/publish bad request response have been fixed. Previously the documentation example said that the bad request response could return a list in the body which was not actually the case. Avoid downloading a trace log file if it is empty. After this fix, GET `/api/v5/trace/clientempty/download` returns 404 `{"code":"NOT_FOUND","message":"Trace is empty"}` If no events matching the trace condition occurred. Fixed issue where `packetsconnacksent` metric was not incremented on CONNACK packets sent with non-zero `ack_flag`. Improved error message for rule engine schema registry when schema name exceeds permissible length. Corrected a misleading prompt when specifying invalid certificates/keys for the `/configs` API. Fixed issue where authorization cache cleaning cli was not working properly for specific client ID. Fixed the increment on data bridge statistics when the bridge is unhealthy. Now, messages sent to unhealthy bridges are counted as dropped messages. Improved HTTP response when attempting to create a bridge with an invalid name. Fixed an issue that prevented the plugin order from being updated across the entire cluster. Fix cluster partition autoheal functionality. Implement autohealing for the clusters that split into multiple partitions.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: 02-configuring-extensions.md

id: configuring-extensions title: Configuring Extensions in the App sidebar_label: Configuring Extensions description: Documentation for how to configure extensions in a Backstage app All extensions in a Backstage app can be configured through static configuration. This configuration is all done under the `app.extensions` configuration key. For more general information on how to write configuration for Backstage, see the section on . This section focuses on the format of the `app.extensions` configuration and the various shorthands that are available. The most complete and verbose format for configuring an individual extensions is as follows: ```yaml app: extensions: <id>: attachTo: id: <parent-id> input: <input-name> disabled: <true/false> config: <extension-specific-config-> ``` All of the top-level fields are optional: `attachTo`, `disabled`, and `config`. Every extension implementation must provide defaults for all of these fields that will be used if they are not provided in the configuration. Note that `app.extensions` is always an array rather than an object. For example, the following is invalid: ```yaml title="INVALID" app: extensions: <id>: # Invalid, this should be an array item, `app.extensions` is now an object config: ... ``` In addition to this schema, there are a number of shorthands available: Rather than a full object, you can specify just the ID of the extension as a string. This is equivalent to setting `disabled` to `false`: ```yaml app: extensions: <id> ``` You can enable/disable individual extension by ID, in this case the value is a boolean: ```yaml app: extensions: <id>: <true/false> ```
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: sql-ref-syntax-aux-cache-cache-table.md

layout: global title: CACHE TABLE displayTitle: CACHE TABLE license: | Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. `CACHE TABLE` statement caches contents of a table or output of a query with the given storage level. If a query is cached, then a temp view will be created for this query. This reduces scanning of the original files in future queries. ```sql CACHE [ LAZY ] TABLE table_identifier [ OPTIONS ( 'storageLevel' [ = ] value ) ] [ [ AS ] query ] ``` LAZY* Only cache the table when it is first used, instead of immediately. table_identifier* Specifies the table or view name to be cached. The table or view name may be optionally qualified with a database name. Syntax: `[ databasename. ] tablename` OPTIONS ( 'storageLevel' [ = ] value )* `OPTIONS` clause with `storageLevel` key and value pair. A Warning is issued when a key other than `storageLevel` is used. The valid options for `storageLevel` are: `NONE` `DISK_ONLY` `DISKONLY2` `DISKONLY3` `MEMORY_ONLY` `MEMORYONLY2` `MEMORYONLYSER` `MEMORYONLYSER_2` `MEMORYANDDISK` `MEMORYANDDISK_2` `MEMORYANDDISK_SER` `MEMORYANDDISKSER2` `OFF_HEAP` An Exception is thrown when an invalid value is set for `storageLevel`. If `storageLevel` is not explicitly set using `OPTIONS` clause, the default `storageLevel` is set to `MEMORYANDDISK`. query* A query that produces the rows to be cached. It can be in one of following formats: a `SELECT` statement a `TABLE` statement a `FROM` statement ```sql CACHE TABLE testCache OPTIONS ('storageLevel' 'DISK_ONLY') SELECT * FROM testData; ```
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_cleanup.md

title: "Command - devspace cleanup" sidebar_label: devspace cleanup Cleans up resources ``` ``` ``` -h, --help help for cleanup ``` ``` --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: YDB (App Definition and Development / Database)
File: random.md

Generates a pseudorandom number: `Random()`: A floating point number (Double) from 0 to 1. `RandomNumber()`: An integer from the complete Uint64 range. `RandomUuid()`: . Signatures ``` Random(T1[, T2, ...])->Double RandomNumber(T1[, T2, ...])->Uint64 RandomUuid(T1[, T2, ...])->Uuid ``` No arguments are used for random number generation: they are only needed to control the time of the call. A new random number is returned at each call. Therefore: {% if ydbnondeterministic_functions %} If Random is called again within a same query* and with a same set of arguments does not guarantee getting the same sets of random numbers. The values will be equal if the Random calls fall into the same execution phase. {% else %} If Random is called again within a same query* and with a same set of arguments, the same set of random numbers is returned. Keep in mind that we mean the arguments themselves (i.e., the text between parentheses) rather than their values. {% endif %} Calling of Random with the same set of arguments in different queries* returns different sets of random numbers. {% note warning %} If Random is used in , its one-time calculation is not guaranteed. Depending on the optimizers and runtime environment, it can be counted both once and multiple times. To make sure it's only counted once, materialize a named expression into a table. {% endnote %} Use cases: `SELECT RANDOM(1);`: Get one random value for the entire query and use it multiple times (to get multiple random values, you can pass various constants of any type). `SELECT RANDOM(1) FROM table;`: The same random number for each row in the table. `SELECT RANDOM(1), RANDOM(2) FROM table;`: Two random numbers for each row of the table, all the numbers in each of the columns are the same. `SELECT RANDOM(some_column) FROM table;`: Different random numbers for each row in the table. `SELECT RANDOM(somecolumn), RANDOM(somecolumn) FROM table;`: Different random numbers for each row of the table, but two identical numbers within the same row. `SELECT RANDOM(somecolumn), RANDOM(somecolumn + 1) FROM table;` or `SELECT RANDOM(somecolumn), RANDOM(othercolumn) FROM table;`: Two columns, with different numbers in both. Examples ```yql SELECT Random(key) -- [0, 1) FROM my_table; ``` ```yql SELECT RandomNumber(key) -- [0, Max<Uint64>) FROM my_table; ``` ```yql SELECT RandomUuid(key) -- Uuid version 4 FROM my_table; ``` ```yql SELECT RANDOM(column) AS rand1, RANDOM(column) AS rand2, -- same as rand1 RANDOM(column, 1) AS randAnd1, -- different from rand1/2 RANDOM(column, 2) AS randAnd2 -- different from randAnd1 FROM my_table; ```
Project: Tetragon (Provisioning / Security & Compliance)
File: CHANGELOG.md

All notable changes to this project will be documented in this file. The format is based on , and this project adheres to . Fix initialization of `Value` wrappers. Add `String` method to `atomic.Pointer[T]` type allowing users to safely print underlying values of pointers. Add `atomic.Float32` type for atomic operations on `float32`. Add `CompareAndSwap` and `Swap` methods to `atomic.String`, `atomic.Error`, and `atomic.Value`. Add generic `atomic.Pointer[T]` type for atomic operations on pointers of any type. This is present only for Go 1.18 or higher, and is a drop-in for replacement for the standard library's `sync/atomic.Pointer` type. Deprecate `CAS` methods on all types in favor of corresponding `CompareAndSwap` methods. Thanks to @eNV25 and @icpd for their contributions to this release. Add `Float64.Swap` to match int atomic operations. Add `atomic.Time` type for atomic operations on `time.Time` values. Add `atomic.Uintptr` type for atomic operations on `uintptr` values. Add `atomic.UnsafePointer` type for atomic operations on `unsafe.Pointer` values. Support JSON serialization and deserialization of primitive atomic types. Support Text marshalling and unmarshalling for string atomics. Disallow incorrect comparison of atomic values in a non-atomic way. Remove dependency on `golang.org/x/{lint, tools}`. Drop library dependency on `golang.org/x/{lint, tools}`. Fix bug where `Bool.CAS` and `Bool.Toggle` do work correctly together causing `CAS` to fail even though the old value matches. With Go modules, only the `go.uber.org/atomic` import path is supported now. If you need to use the old import path, please add a `replace` directive to your `go.mod`. Add `atomic.Error` type for atomic operations on `error` values. Add `atomic.Duration` type for atomic operations on `time.Duration` values. Revert optimization for `atomic.String.Store("")` which caused data races. Add `atomic.Bool.CAS` for compare-and-swap semantics on bools. Optimize `atomic.String.Store("")` by avoiding an allocation. Shadow `atomic.Value` from `sync/atomic`. Add atomic `Float64` type. Support new `go.uber.org/atomic` import path. Initial release.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.11-patch.3.md

layout: release date: 2024-01-19 tag: v0.7.11-patch.3 [Relationships] Add selectors sets in `relationships`. @MUzairS15 (#9987) Update grafana_helper.go @eltociear (#9981) [Server] Fix remote pattern upload @MUzairS15 (#10014) [Server] Validate `userid` and handle remote provider responses on failure correctly. @MUzairS15 (#10015) [bug] Fix Remote Design file upload @theBeginner86 (#10013) [RTK] Connections api migrate to rtk @senali-d (#9992) [UI] Fix publishing design @Yashsharma1911 (#9990) [MeshModel Category] Database category icon added @ritiksaxena124 (#10006) [Bug] Reinitialise `models` and `keys` registration on Database reset. @MUzairS15 (#10024) [models] Consolidate Meshery Docs Generator @theBeginner86 (#9941) [docs] Fix YAML issue in Meshery Docs @theBeginner86 (#10021) [models] Consolidate Meshery Docs Generator @theBeginner86 (#9941) Made grammatical changes for the paragraph under 'Importing Applications'. @ayushgml (#10018) Thank you to our contributors for making this release possible: @MUzairS15, @Yashsharma1911, @ayushgml, @eltociear, @leecalcote, @ritiksaxena124, @senali-d and @theBeginner86
Project: KICS (Provisioning / Security & Compliance)
File: 48471392-d4d0-47c0-b135-cdec95eb3eef.md

title: Service Account Token Automount Not Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 48471392-d4d0-47c0-b135-cdec95eb3eef Query name: Service Account Token Automount Not Disabled Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Defaults URL: Service Account Tokens are automatically mounted even if not necessary<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="28 5 54" apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false apiVersion: v1 kind: Pod metadata: name: security.context.demo spec: automountServiceAccountToken: true securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false apiVersion: serving.knative.dev/v1 kind: Configuration metadata: name: dummy-config namespace: knative-sequence spec: template: spec: automountServiceAccountToken: true securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="5" apiVersion: v1 kind: ServiceAccount metadata: name: redistest-sa automountServiceAccountToken: true apiVersion: apps/v1 kind: Deployment metadata: name: demoenv labels: app: redis spec: selector: matchLabels: app: redis template: metadata: labels: app: redis spec: serviceAccountName: redistest-sa containers: name: redis image: redis:latest ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: automountServiceAccountToken: false securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: ServiceAccount metadata: name: redistest-sa automountServiceAccountToken: false apiVersion: apps/v1 kind: Deployment metadata: name: demoenv labels: app: redis spec: selector: matchLabels: app: redis template: metadata: labels: app: redis spec: serviceAccountName: redistest-sa containers: name: redis image: redis:latest ```
Project: ThreatMapper (Provisioning / Security & Compliance)
File: linux-host.md

title: Linux Host On a Linux-based bare-metal or virtual machine workload, the ThreatMapper sensor agents are deployed within a lightweight docker runtime which should be installed on the host Linux operating system. Install a docker runtime on the Linux host. Refer to the for minimum supported platforms. Run the following command to start the Sensor Agent on the host. You can find the Deepfence API key under `Setting>User Management>API Key`. ```bash docker run -dit \ --cpus=".2" \ --name=deepfence-agent \ --restart on-failure \ --pid=host \ --net=host \ --log-driver json-file \ --log-opt max-size=50m \ --privileged=true \ -v /sys/kernel/debug:/sys/kernel/debug:rw \ -v /var/log/fenced \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /:/fenced/mnt/host/:ro \ -e DFLOGLEVEL="info" \ -e USERDEFINEDTAGS="" \ -e MGMTCONSOLEURL="CONSOLE-IP" \ -e MGMTCONSOLEPORT="443" \ -e DEEPFENCE_KEY="DEEPFENCE-API-KEY" \ deepfenceio/deepfenceagentce:2.1.1 ``` Optionally the sensor container can be tagged using ```USERDEFINEDTAGS=""``` in the above command. Tags should be comma separated, for example, ```"dev,front-end"```.