cwielenb/CNCF-Dataset huggingface dataset:
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: federatedresourcequota_test.md

| Test Case | E2E Describe Text | Comments | |-|--|-| | Test if the ResourceQuota propagated to member clusters | federatedResourceQuota should be propagated to member clusters | | | Test if the ResourceQuota removed from member clusters | federatedResourceQuota should be removed from member clusters | | | Test if the ResourceQuota propagated to new joined clusters | federatedResourceQuota should be propagated to new joined clusters | | | Test if the federatedResourceQuota collect CPu and Memory status correctly | federatedResourceQuota status should be collect correctly | |
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: clusteraffinities_test.md

| Test Case | E2E Describe Text | Comments | |||--| | | | [PropagationPolicy] Test when schedule change from clusterAffinity to clusterAffinities | propagate deployment and then update the cluster label | | | [PropagationPolicy] Test when schedule change from clusterAffinities to clusterAffinity | propagate deployment and then update the cluster label | | | [ClusterPropagationPolicy] Test ClusterAffinities when schedule with multi clusterAffinity | propagate clusterRole and then update the cluster label | | | [ClusterPropagationPolicy] Test when schedule change from clusterAffinity to clusterAffinities | propagate clusterRole and then update the cluster label | | | [ClusterPropagationPolicy] Test when schedule change from clusterAffinities to clusterAffinity | propagate clusterRole and then update the cluster label | | | Test ClusterAffinities reschedule when member cluster become unReachable | deployment failover testing | |
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.21.3.md

We are delighted to present version v1.21.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Updates Go to 1.18.9, see . (#4926, @skriss) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.21.3 is tested against Kubernetes 1.21 through 1.23. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-005.md

+++ date = "2017-02-09T18:50:31Z" description = "CoreDNS-005 Release Notes." tags = ["Release", "005", "Notes"] release = "005" title = "CoreDNS-005 Release" author = "coredns" +++ CoreDNS-005 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. A way to configure (external) plugin was added. Edit `plugin.cfg` and do a `go generate && go build` and your plugin has been added. This allows for out-of-tree plugin to be easily added. Documentation can be found in . erratic*: a new plugin that can drop queries, limited in the current functionality, but useful for testing. trace*: a new plugin that implements OpenTracing-based tracing using Zipkin. proxy*: fix a bug when a connection hangs and never gets release (#467) proxy: Fold httpproxy* into it, which is now a normal proxy with a special `protocol`. For Monitoring an extra label was added: `proxyproto` that shows the protocol used (`dns` or `httpsgoogle`). See the for details. httpproxy: removed because functionality is moved to proxy*. kubernetes*: Now implements the full , including regular and headless services, endpoint hostnames, A, SRV, and PTR records. kubernetes*: Implements the `pod` type for requests in both a Kube-DNS compatible mode (`insecure`) and a mode which validates that the IP in question belongs to a pod in the specified namespace (`verified`) kubernetes*: Simplified the configuration of reverse zones. Instead of listing the zones in the zone list, you can just add a list of CIDRs using the `cidrs` option. rewrite*: allow rewriting more bits of the incoming packet. This required some backward incompatible changes, e.g. a new FIELD keyword is now required. See the for details. The following people helped with getting this release done: Bob Wasniak, Chris O'Haver, devnev, Dmytro Kislov, John Belamaric, Miek Gieben, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: release_process.md

Open Service Mesh will target a release every quarter. These releases will be targeted in the first half of February, May, August, and November. These target release months are subject to change if a release is pushed. In other words, if a release misses February and is pushed out in March then the next release will target June instead of May. If you would like to see a new feature added to Open Service Mesh, please . This issue will be discussed and, if approved, prioritized in the backlog. When there is a new release being planned and developed, a will be created. This new milestone will have issues added to it that will be prioritized from the . Once the release milestone is complete, a new release of Open Service Mesh will be created and this milestone will be closed. At that moment, the next release milestone will be created and items from vFuture will be added. For larger projects where development will likely span multiple releases we should have a separate feature milestone created. This feature milestone should have a projected end date. Once a release milestone is opened up that has an end date that includes the feature milestone end date, this feature should be considered to be included in the next release. The progression of approved work items will go through this lifecycle: Added to the when approved Added to the when set for the next release Added to the column when prioritized for "next work" Moved to the In progress column when being actively worked on Moved to the Done column when completed At the end of this lifecycle it will be included in the next release of OSM. Release candidates (RCs) should be created before each significant release so final testing can be performed. RCs are tagged as `vX.Y.Z-rc.W`. After the following steps have been performed to publish the RC, perform any final testing with the published release artifacts for about one week. If issues are found, submit patches to the RC's release branch and create a new RC with the tag `vX.Y.Z-rc.W+1`. Apply those same patches to the `main` branch. Repeat until the release is suitably stable.
Project: 3Scale (Orchestration & Management / API Gateway)
File: integration-tests.md

Test framework used for integration testing in APIcast: : Data-driven test scaffold for Nginx C module and OpenResty Lua library development. Documentation on this framework: . APIcast specific extension/fork of this framework: : APIcast testing framework using `Test::Nginx`. Using Docker you just need to run: ```shell make development ``` That will create a Docker container and run bash inside it. The project's source code will be available in the container and sync'ed with your local `apicast` directory, so you can edit files in your preferred environment and still be able to run whatever you need inside the Docker container. To install the dependencies inside the container run: ```shell make dependencies ``` To run the integration tests inside the container: ```shell make prove ``` To enable debug logs when running the integration tests set `DEBUG=1` before executing the tests. This will print all the logs in `stderr` which is configured in: `$Test::Nginx::Util::ErrLogFile`. To run a single file of tests ```shell make prove PROVE_FILES=path/to/file.t ``` To run a single test within a test file declare the ` ONLY` flag at the top of the test, for example: ``` === TEST 1: some test ONLY configuration ``` By default, the integration test run is randomized. You can disable this behavior setting the env var to `0`. Some integration tests are run `n` times where `n` is defined at the top of the test file in the function . It can be very useful to switch this to 1 when debugging failed tests. Where env vars such as are used in the test, its necessary to declare `env` at the top of that section in the test as well as in any subsequent sections where that same env var then needs to be reused. For example: ``` === TEST 1: some test configuration random_port env ``` AND then later in ``` upstream env ``` For any env vars that include a random port such as `TESTNGINXRANDOM_PORT` an additional declaration is required; `random_port` only once in the first section of the test where that env var is declared. After that `env` is sufficient in any subsequent sections in the test to propagate the variable. Mocking of components, configuration & environment in a reusable way is stored in the directory. In is the specific Lua code for the http forward proxy (its really just an Nginx reverse proxy). The logs are forwarded to `stdout` just like the APIcast & test logs. The Nginx configuration and Perl code to start up the proxy server is . You can see that the is used for both `HTTPPROXY` & `HTTPSPROXY` settings.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_secure_link.md

modsecurelink is used to check authenticity of requested links, protect resources from unauthorized access, and limit link lifetime. the basic config in: conf/modsecurelink/modsecurelink.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Debug flag of module | ```ini [Basic] DataPath = ./modsecurelink/secure_link.data [Log] OpenDebug = true ``` conf/modsecurelink/securelinkrule.data | Config Item | Description | | -- | - | | Version | String<br>Version of config file | | Config | Object<br>Rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A list of rules | | Config{v} | | Config.ChecksumKey | String<br>The key which stored Checksum Value in Query | | Config.ExpiresKey | String<br>The key which stored Expired time in Query | | Config.ExpressionNodes | Array<br>Nodes which join calculate Checksum | | Config.ExpressionNodes[].Type | String<br>Node Type, see Node Type to get more information | | Config.ExpressionNodes[].Param | String<br>The param may be used to get Final Value | be supported node type and Calculate logic: | type | Calculate logic | | -- | - | | label | $Param | | query | req.URL.Query($Param) | | header | req.Header.Get($Param) | | host | req.Host | | uri | req.RequestURI | | remote_addr | req.RemoteAddr | ```json { "Version": "2019-12-10184356", "Config": { "p1": [{ "Cond": "default_t()", "ChecksumKey": "sign", "ExpiresKey": "time", "ExpressionNodes": [{ "Type": "query", "Param": "time" }, { "Type": "uri" }, { "Type": "remote_addr" }, { "Type": "label", "Param": " secret" } ] }] } } ``` With above config, the pseudo code to generate link is ``` func WrapSecureLinkParam (req *http.Request) { now := time.Now().Unix() expires := now + int64(time.Hour*24/time.Second) // step1: get origin data origin := fmt.Sprintf("%d%s%s%s", expires, req.RequestURI, req.RemoteAddr, " secret") // step2: generator sign sign := func(origin string) string { tmpB := md5.Sum([]byte(origin)) tmp := base64.StdEncoding.EncodeToString(tmpB[:]) tmp = strings.ReplaceAll(tmp, "+", "-") tmp = strings.ReplaceAll(tmp, "/", "_") tmp = strings.ReplaceAll(tmp, "=", "") return tmp } // step3: generate link req.URL.Query().Set("sign", sign(origin)) req.URL.Query().Set("time", fmt.Sprintf("%d", expires)) } ``` step2: the sign logic in shell is: ``` echo -n $origin | openssl md5 -binary | openssl base64 | tr +/ -_ | tr -d = // one example: echo -n '2147483647/s/link127.0.0.1 secret' | openssl md5 -binary | openssl base64 | tr +/ -_ | tr -d = _e4Nc3iduzkWRm01TBBNYw ```
Project: Gloo (Orchestration & Management / API Gateway)
File: selectors.proto.sk.md

title: "selectors.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "namespaces": []string "labels": map<string, string> "expressions": []selectors.core.gloo.solo.io.Selector.Expression ``` | Field | Type | Description | | -- | - | -- | | `namespaces` | `[]string` | | | `labels` | `map<string, string>` | | | `expressions` | | Expressions allow for more flexible Route Tables label matching, such as equality-based requirements, set-based requirements, or a combination of both. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#equality-based-requirement. | ```yaml "key": string "operator": .selectors.core.gloo.solo.io.Selector.Expression.Operator "values": []string ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | Kubernetes label key, must conform to Kubernetes syntax requirements https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set. | | `operator` | | The operator can only be in, notin, =, ==, !=, exists, ! (DoesNotExist), gt (GreaterThan), lt (LessThan). | | `values` | `[]string` | | Selector expression operator, while the set-based syntax differs from Kubernetes (kubernetes: `key: !mylabel`, gloo: `key: mylabel, operator: "!"` | kubernetes: `key: mylabel`, gloo: `key: mylabel, operator: exists`), the functionality remains the same. | Name | Description | | -- | -- | | `Equals` | = | | `DoubleEquals` | == | | `NotEquals` | != | | `In` | in | | `NotIn` | notin | | `Exists` | exists | | `DoesNotExist` | ! | | `GreaterThan` | gt | | `LessThan` | lt | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: StackStorm (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

If you believe you found a security issue or a vulnerability, please send a description of it to our private mailing list at info [at] stackstorm [dot] com. Once you've submitted an issue, you should receive an acknowledgment from one our of team members in 48 hours or less. If further action is necessary, you may receive additional follow-up emails. For more information, please refer to https://docs.stackstorm.com/latest/security.html
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: python.md

Use `Python Task` to create a python-type task and execute python scripts. When the worker executes `Python Task`, it will generate a temporary python script, and executes the script by the Linux user with the same name as the tenant. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag <img src="../../../../img/tasks/icons/python.png" width="15"/> from the toolbar to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | |-|--| | Script | Python program developed by the user. | | Custom parameters | It is the user-defined parameters of Python, which will replace the content with \${variable} in the script. | This example simulates a common task that runs by a simple command. The example is to print one line in the log file, as shown in the following figure: "This is a demo of python task". ```python print("This is a demo of python task") ``` This example simulates a custom parameter task. We use parameters for reusing existing tasks as template or coping with the dynamic task. In this case, we declare a custom parameter named "paramkey", with the value "paramval". Then we use echo to print the parameter "${param_key}" we just declared. After running this example, we would see "param_val" print in the log. ```python print("${param_key}") ```
Project: WSO2 API Microgateway (Orchestration & Management / API Gateway)
File: restAPIGenGuide.md

This guide provides information about introducing changes to the REST API Interface between the API Controller and Adapter. If the any API Level changes are required to be done, it should be added to the `adapter/resources/adapterAPI.yaml`. Then we autogenerate the code from go-swagger tool. First, You should install the go-swagger in your developer environment. https://goswagger.io/install.html Navigate to the `adapter` directory. Execute the following command. ``` swagger generate server -f resources/adapterAPI.yaml -A restapi -P models.Principal -s restserver -m models -t internal/api -r resources/license.txt --exclude-main ``` Once it is executed, `adapter/internal/api/models` and `adapter/internal/api/restserver` packages will be populated. Within the `restserver` directory, there is a file called `configure_restapi.go`. All the code level changes introduced should be included in here. (Authentication logic, additional validations, TLS level configurations etc.) If you need to have the Main file (for referenece purposes), you should execute the above command without the `--exclude-main` flag.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: branch_management.md

New development occurs on the . The main branch should always have a green build! Backwards-compatible bug fixes should target the main branch and subsequently be ported to stable branches. Once the main branch is ready for release, it will be tagged and become the new stable branch. The etcd team has adopted a rolling release model and supports two stable versions of etcd. The `main` branch is our development branch. All new features land here first. To try new and experimental features, pull `main` and play with it. Note that `main` may not be stable because new features may introduce bugs. Before the release of the next stable version, feature PRs will be frozen. A will be assigned to the major/minor version and will lead the etcd community in testing, bug-fix, and documentation of the release for one to two weeks. All branches with the prefix `release-` are considered stable branches. After every minor release (), we will have a new stable branch for that release, managed by a . We will keep fixing the backward-compatible bugs for the latest two stable releases. A patch release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.
Project: 3Scale (Orchestration & Management / API Gateway)
File: build.md

APIcast is an application based on . APIcast consists of two parts: NGINX configuration and Lua files. APIcast is released as . APIcast uses LuaRocks, the package manager for Lua modules, to install dependencies. With a correct configuration, LuaRocks installs dependencies into the correct path where OpenResty can see them. For Docker images, LuaRocks is installed into the application folder. Then, `luarocks path` adds the application folder to the load path. Lua Dependencies are defined in file. `lua-resty-http` cosocket based http client to be used instead of the `ngx.location.capture` `inspect` library to pretty print data structures `router` used to implement internal APIs APIcast is using to build the APIcast runtime image. You must have docker installed and available on your system. The development image used is based on . It builds on heavy OpenShift base images. In future releases, we will leverage multistage docker files and use a minimal runtime image. runtime image The runtime image build is defined in the `Makefile`. The `make runtime-image` is for the upstream release build. development image The development image build is defined in the `Makefile`. The `make dev-build` is meant for development. The `master` branch is automatically built and pushed on every successful build by CircleCI to .
Project: KrakenD (Orchestration & Management / API Gateway)
File: report-vulnerability.md

name: Report vulnerability about: Report a vulnerability title: '' labels: '' assignees: '' For private vulnerabilities write to support@devops.faith instead Vulnerabilty description Explain the vulnerability in detail and how to reproduce when possible Reference E.g: https://nvd.nist.gov/vuln/detail/CVE-2019-6486 Additional information Impact, Known Affected Software Configurations, etc.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: BUILD.md

The following packages must be installed before Avro can be built: Java: JDK 8, 11, 17 and 21 with the appropriate toolchain config, Maven 3.9.6 or better, protobuf-compile PHP: php7, phpunit, php7-gmp Python 3: 3.7 or greater, tox (tox will install other dependencies as needed) C: gcc, cmake, asciidoc, source-highlight, Jansson, pkg-config C++: cmake 3.7.2 or greater, g++, flex, bison, libboost-dev C#: .NET Core 2.2 SDK JavaScript: Node 12.x+, nodejs, npm Ruby: Ruby 2.7 or greater, ruby-dev, gem, bundler, snappy Perl: Perl 5.24.1 or greater, gmake, Module::Install, Module::Install::ReadmeFromPod, Module::Install::Repository, Math::BigInt, JSON::XS, Try::Tiny, Regexp::Common, Encode, IO::String, Object::Tiny, Compress::ZLib, Error::Simple, Test::More, Test::Exception, Test::Pod Rust: rustc and Cargo 1.65.0 or greater Apache Ant 1.7 md5sum, sha1sum, used by top-level dist target It can be simpler to use a Docker image with all of the requirements already installed. If you have Docker installed on your host machine, you can build inside a container by running: ```bash ./build.sh docker docker@539f6535c9db:~/avro$ cd lang/java/ docker@539f6535c9db:~/avro/lang/java$ ./build.sh test [INFO] Scanning for projects... ``` When this completes you will be in a shell running in the container. Building the image the first time may take a while (20 minutes or more) since dependencies must be downloaded and installed. However subsequent invocations are much faster as the cached image is used. The working directory in the container is mounted from your host. This allows you to access the files in your Avro development tree from the Docker container. There are some additional `DOCKER_` environment variables described in that can be used to interact with the image using the build script. Some examples: ```bash DOCKERBUILDXTRA_ARGS=--no-cache ./build.sh docker DOCKERIMAGENAME=avro-build:1.10.1-rc1 ./build.sh docker DOCKERRUNENTRYPOINT="mvn --version" ./build.sh docker ``` Requirement: - Docker Windows: (Docker Desktop)[https://www.docker.com/products/docker-desktop] macOS: (Docker Desktop)[https://www.docker.com/products/docker-desktop] Linux: (Docker CE/EE)[https://docs.docker.com/install/#supported-platforms] and (Docker Compose)[https://docs.docker.com/compose/install] Useful links: (Developing inside a Container)[https://code.visualstudio.com/docs/remote/containers] (Going further with Dev Containers)[https://microsoft.github.io/code-with-engineering-playbook/developer-experience/going-further/] Once the requirements are installed (or from the Docker container), build.sh can be used as follows: ``` ./build.sh test # runs tests for all languages ./build.sh dist # creates all release distribution files in dist/ ./build.sh clean # removes all generated artifacts ``` Testing is done with the same Docker container as mentioned in the building step. The difference is that it will do clean run of the full test suite: ```bash ./build.sh docker-test ```