cwielenb/CNCF-Dataset huggingface dataset:
Project: Sonobuoy (Provisioning / Security & Compliance)
File: 2022-07-01-july-drumbeat.md

title: "July Drumbeat" image: /img/sonobuoy.svg excerpt: An update about the recent improvements to Sonobuoy. author_name: John Schnake author_url: https://github.com/johnschnake categories: [kubernetes, sonobuoy, plugins] tags: ['Sonobuoy Team', 'John Schnake'] date: 2022-07-01 slug: july-drumbeat Now that we release on a fairly frequent basis (every 1-3 weeks) we like to present a summary of relevant changes periodically for users updating Sonobuoy. When running `sonobuoy results <tarball> --mode dump` you get the full results of the plugins in a YAML format. The problem is that often, newlines and tabs are encoded as "\n" and "\t" making it very difficult to read large blocks of text. We've now added a different mode `--mode=readable` which will dump the same YAML output but making it more human-friendly. This is for human-readability and not for machine parsing, which should still utilize modes `detailed` for JSON data or `dump` for the exact YAML source data. We've added the CLI documentation (e.g. `sonobuoy run -h`) to the documentation . This can make it easier to explore the CLI and share information about options with others. We've also re-added a `Makefile` to the repository in order to streamline the most common build functions. The old Makefile we had as too bloated and had multiple bugs throughout the years. The new Makefile will avoid this by simply being a wrapper around the build scripts for the most common use cases. All build logic will continue to be put into the Bash build scripts, but by putting basic build/test calls into the Makefile should simplify things for new developers and users. Pods for plugins get assigned names with generated values in them, meaning that in order to query them with `kubectl` you first have to query the Sonobuoy namespace then copy/paste the name into your command. To make this even easier to script with, we've added a new command `sonobuoy get pods` that will grab the pod names for the plugins you've launched. You can also add the `-p <plugin name>` option to just get one of them. We hope this will make Sonobuoy even easier to combine with other tools. Sonobuoy now supports `--service-account-name` and `--existing-service-account` flags which will allow you to customize the SA used for the aggregator/plugins. This gives you finer control of permission when necessary. We've published a roadmap for the project on the GitHub . We'll update it periodically but our hope is that it will give you a basic insight into what we're focusing on for the project. Star/watch us on GitHub and Get updates on Twitter () Chat with us on Slack (#sonobuoy on Kubernetes)
Project: ShardingSphere (App Definition and Development / Database)
File: keygen.en.md

+++ title = "Key Generate Algorithm" weight = 3 +++ In traditional database software development, automatic primary key generation is a basic requirement and various databases provide support for this requirement, such as MySQL's self-incrementing keys, Oracle's self-incrementing sequences, etc. After data sharding, it is a very tricky problem to generate global unique primary keys from different data nodes. Self-incrementing keys between different actual tables within the same logical table generate duplicate primary keys because they are not mutually perceived. Although collisions can be avoided by constraining the initial value and step size of self-incrementing primary keys, additional O&M rules must to be introduced, making the solution lack completeness and scalability. There are many third-party solutions that can perfectly solve this problem, such as UUID, which relies on specific algorithms to generate non-duplicate keys, or by introducing primary key generation services. In order to cater to the requirements of different users in different scenarios, Apache ShardingSphere not only provides built-in distributed primary key generators, such as UUID, SNOWFLAKE, but also abstracts the interface of distributed primary key generators to facilitate users to implement their own customized primary key generators. Type: SNOWFLAKE Attributes: | Name | DataType | Description | Default Value | |--||-|--| | worker-id (?) | long | The unique ID for working machine | 0 | | max-tolerate-time-difference-milliseconds (?) | long | The max tolerate time for different server's time difference in milliseconds | 10 milliseconds | | max-vibration-offset (?) | int | The max upper limit value of vibrate number, range `[0, 4096)`. Notice: To use the generated value of this algorithm as sharding value, it is recommended to configure this property. The algorithm generates key mod `2^n` (`2^n` is usually the sharding amount of tables or databases) in different milliseconds and the result is always `0` or `1`. To prevent the above sharding problem, it is recommended to configure this property, its value is `(2^n)-1` | 1 | Note: worker-id is optional In standalone mode, support user-defined configuration, if the user does not configure the default value of 0. In cluster mode, it will be automatically generated by the system, and duplicate values will not be generated in the same namespace. Type: UUID Attributes: None Policy of distributed primary key configurations is for columns when configuring data sharding rules. Snowflake Algorithms ```PlainText keyGenerators: snowflake: type: SNOWFLAKE ``` UUID ```PlainText keyGenerators: uuid: type: UUID ```
Project: KICS (Provisioning / Security & Compliance)
File: b3871dd8-9333-4d6c-bd52-67eb898b71ab.md

title: Response Object With Incorrect Ref (v3) hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b3871dd8-9333-4d6c-bd52-67eb898b71ab Query name: Response Object With Incorrect Ref (v3) Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Structure and Semantics URL: Response Object reference must always point to '#/components/responses'<br> ```json title="Positive test num. 1 - json file" hl_lines="44" { "openapi": "3.0.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "components": { "responses": { "Success": { "description": "200 response", "content": { "application/json": { "examples": { "foo": { "value": { "versions": [ { "status": "CURRENT", "updated": "2011-01-21T11:33:21Z", "id": "v2.0", "links": [ { "href": "http://127.0.0.1:8774/v2/", "rel": "self" } ] } ] } } } } } } } }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/components/schemas/Success" } } } } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="27" openapi: 3.0.0 info: title: Simple API overview version: 1.0.0 components: Success: description: 200 response content: application/json: examples: foo: value: versions: status: CURRENT updated: "2011-01-21T11:33:21Z" id: v2.0 links: href: http://127.0.0.1:8774/v2/ rel: self paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": $ref: "#/components/schemas/Success" ``` ```json title="Negative test num. 1 - json file" { "openapi": "3.0.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "components": { "responses": { "Success": { "description": "200 response", "content": { "application/json": { "examples": { "foo": { "value": { "versions": [ { "status": "CURRENT", "updated": "2011-01-21T11:33:21Z", "id": "v2.0", "links": [ { "href": "http://127.0.0.1:8774/v2/", "rel": "self" } ] } ] } } } } } } } }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "$ref": "#/components/responses/Success" } } } } } } ``` ```yaml title="Negative test num. 2 - yaml file" openapi: 3.0.0 info: title: Simple API overview version: 1.0.0 components: responses: Success: description: 200 response content: application/json: examples: foo: value: versions: status: CURRENT updated: "2011-01-21T11:33:21Z" id: v2.0 links: href: http://127.0.0.1:8774/v2/ rel: self paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": $ref: "#/components/responses/Success" ```
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-pod-exists.1.md

% podman-pod-exists 1 podman-pod-exists - Check if a pod exists in local storage podman pod exists pod podman pod exists checks if a pod exists in local storage. The ID or Name of the pod may be used as input. Podman returns an exit code of `0` when the pod is found. A `1` is returned otherwise. An exit code of `125` indicates there was an issue accessing the local storage. Check if specified pod exists in local storage (the pod does actually exist): ``` $ sudo podman pod exists web; echo $? 0 ``` Check if specified pod exists in local storage (the pod does not actually exist): ``` $ sudo podman pod exists backend; echo $? 1 ``` , December 2018, Originally compiled by Brent Baude (bbaude at redhat dot com)
Project: Harbor (Provisioning / Container Registry)
File: 11-01-system-admin-manage-global-level-labels.md

Test 11-01 - System admins manage global level labels ======= To verify that the system administrators can manage(CURD) the global level labels. User guide This test requires that a Harbor instance is running and available. The system admin user logs in to the UI. The admin user creates a global level label from the UI. The admin user edits the label created in Step1. The admin user deletes the label created in Step1. In Step2, the label can be created successfully. In Step3, the label can be updated successfully. In Step4, the label can be deleted successfully. None
Project: Quay (Provisioning / Container Registry)
File: CHANGELOG.tpl.md

{{ if .Versions -}} {{ if .Unreleased.CommitGroups -}} {{ range .Unreleased.CommitGroups -}} {{ range .Commits -}} : {{ .Subject }} {{ end -}} {{ end -}} {{ end -}} {{ range .Versions }} <a name="{{ .Tag.Name }}"></a> {{ range .CommitGroups -}} {{ range .Commits -}} : {{ .Subject }} {{ end -}} {{ end -}} {{- if .RevertCommits -}} {{ range .RevertCommits -}} {{ .Revert.Header }} {{ end }} {{ end -}} {{- if .MergeCommits -}} {{ range .MergeCommits -}} {{ .Header }} {{ end }} {{ end -}} {{- if .NoteGroups -}} {{ range .NoteGroups -}} {{ range .Notes }} {{ .Body }} {{ end }} {{ end -}} {{ end -}} {{ end -}} {{- if .Versions }} {{ range .Versions -}} {{ if .Tag.Previous -}} {{ end -}} {{ end -}} {{ end -}} {{ end -}}
Project: Keycloak (Provisioning / Security & Compliance)
File: tests-development.md

We focus primarily on integration/functional level tests. Unit tests are avoided and only recommended for isolated classes such as small utils. We do not use any mocking frameworks and we will not accept any contributions that adds a mocking framework. When writing tests please follow the same approach as we have taken in the other tests. There are many ways to test software and we have chosen ours, so please appreciate that. The main tests are provided in testsuite/integration-arquillian/tests/base. Most server tests are here. Integration tests can be executed from the IDE in the same way as you would run unit tests. When ran from within the IDE an embedded Keycloak server is executed automatically. A good test to start looking at is org.keycloak.testsuite.forms.LoginTest. It is reasonable straightforward to understand this test. When developing your test depending on the feature or enhancement you are testing you may find it best to add to an existing test, or to write a test from scratch. For the latter, we recommend finding another test that is close to what you need and use that as a basis. All tests don't have to be fully black box testing as the testsuite deploys a special feature to the Keycloak server that allows running code within the server. This allows writing tests that can execute functions not exposed through APIs as well as access data that is not exposed. For an example on how to do this look at org.keycloak.testsuite.runonserver.RunOnServerTest. As assertion method use `org.hamcrest.MatcherAssert.assertThat` where possible with a suitable matcher included in the `org.hamcrest.Matchers.*` package. It provides much better readability of test failures messages. Please avoid as much to use set of assertions from `org.junit.Assert.*` package.
Project: KICS (Provisioning / Security & Compliance)
File: f5342045-b935-402d-adf1-8dbbd09c0eef.md

title: AKS Network Policy Misconfigured hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: f5342045-b935-402d-adf1-8dbbd09c0eef Query name: AKS Network Policy Misconfigured Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Insecure Configurations URL: Azure Kubernetes Service should have the proper network policy configuration to ensure the principle of least privileges, which means that 'networkprofile.networkpolicy' should be defined<br> ```tf title="Positive test num. 1 - tf file" hl_lines="26 69 21" resource "azurermkubernetescluster" "positive1" { name = "example-aks1" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks1" defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { } } resource "azurermkubernetescluster" "positive2" { name = "example-aks2" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks2" defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } } resource "azurermkubernetescluster" "positive3" { name = "example-aks1" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks1" defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "roxanne" } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermkubernetescluster" "negative1" { name = "example-aks1" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks1" defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "azure" } } resource "azurermkubernetescluster" "negative2" { name = "example-aks2" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks2" defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "calico" } } ```
Project: KubeEdge (Provisioning / Automation & Configuration)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! Here are some tips for you: If this is your first time, please read our contributor guidelines: https://github.com/kubeedge/kubeedge/blob/master/CONTRIBUTING.md Ensure you have added or ran the appropriate tests for your PR --> What type of PR is this? <!-- Add one of the following kinds: /kind bug /kind cleanup /kind documentation /kind feature /kind test /kind design Optionally add one or more of the following kinds if applicable: /kind api-change /kind failing-test --> What this PR does / why we need it: Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`* --> Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". --> ```release-note ```
Project: Juju (Provisioning / Automation & Configuration)
File: entity-creation.md

Entity Creation =============== This document describes the circumstances in which fundamental state entities are created, from the perspective of the CLI. juju deploy -- The `juju deploy` command always creates services, may create relations, and may also create units and machines. New services can always be added. If the created service's charm defines any peer relations, a (runtime) peer relation will be created for each. BUG: this is not done in the same transaction as service creation; a connection failure at the wrong time will create a broken and unfixable service (because peer relations cannot be manipulated via the CLI). If the created service's charm is not subordinate, some number of units will be created; this number is controlled via the "--num-units" parameter which defaults to 1. If units were created, machines may also be created, as below. juju add-unit The `juju add-unit` command applies only to principal services. It always creates units, and may create machines. Different providers assign units to machines in different ways, and so machine creation can vary: for example, the ec2 provider creates a new machine for each unit that cannot be placed on an existing machine without assigned units. New units can only be added to Alive services. juju integrate -- The `juju integrate` command creates relations, and may -- if the relation has container scope, by virtue of one or more endpoints having container scope -- indirectly cause the creation of subordinate units. Subordinate units are in fact created by principal unit agents, at the point when they enter scope of a container-scoped relation and find that no suitable subordinate already exists. New relations can only be added between Alive services. New subordinate units will only be added as a consequence of an Alive principal unit's participation in an Alive relation (implying an Alive subordinate service).
Project: YDB (App Definition and Development / Database)
File: build-ya.md

Ya Make is a build and test system used historically for YDB development. Initially designed for C++, now it supports number of programming languages including Java, Go, and Python. Ya Make build configuration language is a primary one for YDB, with a `ya.make` file in each directory representing Ya Make targets. Setup the development environment as described in arcticle to work with `Ya Make`. There's a `ya` script in the YDB repository root to run `Ya Make` commands from the console. You can add it to the PATH evniromnet variable to enable launching without specifiying a full path. For Linux/Bash and GitHub repo cloned to `~/ydbwork/ydb` you can use the following command: ``` echo "alias ya='~/ydbwork/ydb/ya'" >> ~/.bashrc source ~/.bashrc ``` Run `ya` without parameters to get help: ``` $ ya Yet another build tool. Usage: ya [--precise] [--profile] [--error-file ERROR_FILE] [--keep-tmp] [--no-logs] [--no-report] [--no-tmp-dir] [--print-path] [--version] [-v] [--diag] [--help] <SUBCOMMAND> [OPTION]... Options: ... Available subcommands: ... ``` You can get detailed help on any subcommand launching it with a `--help` flag, for instance: ``` $ ya make --help Build and run tests To see more help use -hh/-hhh Usage: ya make [OPTION]... [TARGET]... Examples: ya make -r Build current directory in release mode ya make -t -j16 library Build and test library with 16 threads ya make --checkout -j0 Checkout absent directories without build Options: ... ``` The `ya` script downloads required platform-specific artifacts when started, and caches them locally. Periodically, the script is updated with the links to the new versions of the artifacts. If you're using IDE for development, there's a command `ya ide` which helps you create a project with configured tools. The following IDEs are supported: goland, idea, pycharm, venv, vscode (multilanguage, clangd, go, py). Go to the directory in the source code which you need to be a root of your project. Run the `ya ide` command specifying the IDE name, and the target directory to write the IDE project configuration in a `-P` parameter. For instance, to work on the YQL library changes in vscode you can run the following command: ``` cd ~/ydbwork/ydb/library/yql ya ide vscode -P=~/ydbwork/vscode/yqllib ``` Now you can open the `~/ydbwork/vscode/yqllib/ide.code-workspace` from vscode. There are 3 basic types of targets in `Ya Make`: Program, Test, and Library. To build a target run `ya make` with the directory name. For instance, to build a YDB CLI run: ``` cd ~/ydbwork/ydb ya make ydb/apps/ydb ``` You can also run `ya make` from inside a target directory without parameters: ``` cd ~/ydbwork/ydb/ydb/apps/ydb ya make ``` Running a `ya test` command in some directory will build all test binaries located inside its subdirectories, and start tests. For instance, to run YDB Core small tests run: ``` cd ~/ydbwork/ydb ya test ydb/core ``` To run medium and large tests, add options `-tt` and `-ttt` to the `ya test` call, respectively.
Project: ClickHouse (App Definition and Development / Database)
File: v21.3.14.1-lts.md

sidebar_position: 1 sidebar_label: 2022 Backported in : `CAST` from `Date` to `DateTime` (or `DateTime64`) was not using the timezone of the `DateTime` type. It can also affect the comparison between `Date` and `DateTime`. Inference of the common type for `Date` and `DateTime` also was not using the corresponding timezone. It affected the results of function `if` and array construction. Closes . (). Backported in : Fixed bug in deserialization of random generator state with might cause some data types such as `AggregateFunction(groupArraySample(N), T))` to behave in a non-deterministic way. (). Backported in : Fix wrong totals for query `WITH TOTALS` and `WITH FILL`. Fixes . (). Backported in : Fix null pointer dereference in `EXPLAIN AST` without query. (). Backported in : `REPLACE PARTITION` might be ignored in rare cases if the source partition was empty. It's fixed. Fixes . (). Backported in : Fixed `No such file or directory` error on moving `Distributed` table between databases. Fixes . (). Backport unrelated changes, which fixes aliases bug ().
Project: StarRocks (App Definition and Development / Database)
File: dayofweek.md

displayed_sidebar: "English" Returns the weekday index for a given date. For example, the index for Sunday is 1, for Monday is 2, for Saturday is 7. The `date` parameter must be of the DATE or DATETIME type, or a valid expression that can be cast into a DATE or DATETIME value. ```Haskell INT dayofweek(DATETIME date) ``` ```Plain Text MySQL > select dayofweek('2019-06-25'); +-+ | dayofweek('2019-06-25 00:00:00') | +-+ | 3 | +-+ MySQL > select dayofweek(cast(20190625 as date)); +--+ | dayofweek(CAST(20190625 AS DATE)) | +--+ | 3 | +--+ ``` DAYOFWEEK
Project: Couler (Provisioning / Automation & Configuration)
File: bug_report.md

name: Reproducible bug report about: Create a reproducible bug report. Not for support requests. labels: 'bug' What happened/what you expected to happen? What is the version of Couler you are using? What is the version of the workflow engine you are using? Any logs or other information that could help debugging? <!-- Issue Author: Don't delete the following message to encourage other users to support your issue! --> Message from the maintainers: Impacted by this bug? Give it a . We prioritize the issues with the most .