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

Make the following configuration (take zookeeper as an example) Registry plug-in configuration, take Zookeeper as an example (registry.properties) dolphinscheduler-service/src/main/resources/registry.properties ```registry.properties registry.plugin.name=zookeeper registry.servers=127.0.0.1:2181 ``` For specific configuration information, please refer to the parameter information provided by the specific plug-in, for example zk: `org/apache/dolphinscheduler/plugin/registry/zookeeper/ZookeeperConfiguration.java` All configuration information prefixes need to be +registry, such as base.sleep.time.ms, which should be configured in the registry as follows: registry.base.sleep.time.ms=100 `dolphinscheduler-registry-api` defines the standard for implementing plugins. When you need to extend plugins, you only need to implement `org.apache.dolphinscheduler.registry.api.RegistryFactory`. Under the `dolphinscheduler-registry-plugin` module is the registry plugin we currently provide. 1: registry connect timeout You can increase the relevant timeout parameters.
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: README.md

``` cd src/goca go build ``` For unit tests you need dummy monitoring driver, dummy VM driver and user ``oneadmin`` with password ``opennebula``. You can setup it by running: ``` echo "oneadmin:opennebula" > $HOME/.one/one_auth echo 'IMMAD = [ NAME="dummy", SUNSTONENAME="Dummy", EXECUTABLE="oneimsh", ARGUMENTS="-r 3 -t 15 -w 90 dummy"]' >> /etc/one/monitord.conf echo 'VMMAD = [ NAME="dummy", SUNSTONENAME="Testing", EXECUTABLE="onevmmdummy",TYPE="xml" ]' >> /etc/one/oned.conf one restart ``` Download go test moodule: ``` cd src/goca go get gopkg.in/check.v1 ``` Make sure opennebula is running. Exuecute tests: ``` cd src/goca go test ``` ``` cd src/goca go run ../../share/examples/example_name.go ```
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: thirdparties.md

Install ArgoCD on kind-kubeflex: ```shell kubectl --context kind-kubeflex create namespace argocd kubectl --context kind-kubeflex apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml ``` Install CLI: on MacOS: ```shell brew install argocd ``` on Linux: ```shell curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd rm argocd-linux-amd64 ``` Check the page for the obtaining the latest stable release for other architectures and operating systems. Configure Argo to work with the ingress installed in the hosting cluster: ```shell kubectl --context kind-kubeflex apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true" nginx.ingress.kubernetes.io/ssl-passthrough: "true" spec: ingressClassName: nginx rules: host: argocd.localtest.me http: paths: path: / pathType: Prefix backend: service: name: argocd-server port: name: https EOF ``` Open a browser to ArgoCD console: ```shell open https://argocd.localtest.me:9443 ``` Note: if you are working on a VM via SSH, just take the IP of the VM (VM_IP) and add the line `<VM_IP> argocd.localtest.me` to your '/etc/hosts' file, replacing <VM_IP> with the actual IP of your desktop. Get the password for Argo with: ```shell kubectl config use-context kind-kubeflex argocd admin initial-password -n argocd ``` Login into the ArgoCD console with `admin` and the password just retrieved. Type the following on a shell terminal in your desktop (or just enter the address <https://argocd.localtest.me:9443> on your browser): ```shell open https://argocd.localtest.me:9443 ``` Also, login with the argocd CLI with the same credentials. ```shell argocd login --insecure argocd.localtest.me:9443 ``` Add the `wds1` space as cluster to ArgoCD: ```shell CONTEXT=wds1 kubectl config view --minify --context=${CONTEXT} --flatten > /tmp/${CONTEXT}.kubeconfig kubectl config --kubeconfig=/tmp/${CONTEXT}.kubeconfig set-cluster ${CONTEXT}-cluster --server=https://${CONTEXT}.${CONTEXT}-system 2>/dev/null kubectl config use-context kind-kubeflex ARGOSERVERPOD=$(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o 'jsonpath={.items[0].metadata.name}') kubectl cp /tmp/${CONTEXT}.kubeconfig -n argocd ${ARGOSERVERPOD}:/tmp PASSWORD=$(argocd admin initial-password -n argocd | cut -d " " -f 1) kubectl exec -it -n argocd $ARGOSERVERPOD -- argocd login argocd-server.argocd --username admin --password $PASSWORD --insecure kubectl exec -it -n argocd $ARGOSERVERPOD -- argocd cluster add ${CONTEXT} --kubeconfig /tmp/${CONTEXT}.kubeconfig -y ``` Configure Argo to label resources with the "argocd.argoproj.io/instance" label: ```shell kubectl --context kind-kubeflex patch cm -n argocd argocd-cm -p '{"data": {"application.instanceLabelKey": "argocd.argoproj.io/instance"}}' ```
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.9.1.md

+++ title = "CoreDNS-1.9.1 Release" description = "CoreDNS-1.9.1 Release Notes." tags = ["Release", "1.9.1", "Notes"] release = "1.9.1" date = "2022-03-09T00:00:00+00:00" author = "coredns" +++ This is a release with security and bug fixes and some new features added. 1.9.1 is also built with golang 1.17.8 that addressed several golang 1.17.6 vulnerabilities (CVE-2022-23772, CVE-2022-23773, CVE-2022-23806). Note golang 1.17.6 was used to built coredns 1.9.0. Chris O'Haver, Elijah Andrews, Rudolf Schnecker, Yong Tang, nathannaveen, xuweiwei plugin/autopath: Don't panic on empty token (https://github.com/coredns/coredns/pull/5169) plugin/cache: Add zones label to cache metrics (https://github.com/coredns/coredns/pull/5124) plugin/file: Add TXT test case (https://github.com/coredns/coredns/pull/5079) plugin/forward: Don't panic when from-zone cannot be normalized (https://github.com/coredns/coredns/pull/5170) plugin/grpc: Fix healthy proxy error case (https://github.com/coredns/coredns/pull/5168) plugin/grpc: Don't panic when from-zone cannot be normalized (https://github.com/coredns/coredns/pull/5171) plugin/k8s_external: Implement zone transfers (https://github.com/coredns/coredns/pull/4977) plugin/k8s_external: Fix external nsAddrs when CoreDNS Service has no External IPs (https://github.com/coredns/coredns/pull/4891) plugin/kubernetes: Log api connection failures and server start delay (https://github.com/coredns/coredns/pull/5044) plugin/log: Expand `{combined}` and `{common}` in log format (https://github.com/coredns/coredns/pull/5230) plugin/metrics: Add metric counting DNS-over-HTTPS responses (https://github.com/coredns/coredns/pull/5130) plugin/reload: Change hash from md5 to sha512 (https://github.com/coredns/coredns/pull/5226) plugin/secondary: Fix startup transfer failure wrong zone logged (https://github.com/coredns/coredns/pull/5085)
Project: Istio (Orchestration & Management / Service Mesh)
File: README.md

These files contain fully rendered manifests to install various Istio versions, and rendered CNI manifests to install various CNI versions. They are `tar`ed to avoid developer confusion and accidental edits. Generate a revisioned IstioOperator for the version with equivalent settings: ```yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: hub: gcr.io/istio-release revision: 1-x-y components: base: enabled: false pilot: enabled: true ingressGateways: name: istio-ingressgateway enabled: false values: global: proxy: resources: requests: cpu: 10m memory: 40m ``` Run `tar cf 1.x.y-install.yaml.tar 1.x.y-install.yaml` Generate a new CNI Daemonset manifest with the following settings: ```yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: hub: gcr.io/istio-release profile: empty components: cni: enabled: true namespace: kube-system ``` Run `tar cf 1.x.y-cni-install.yaml.tar 1.x.y-cni-install.yaml`
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.2.md

+++ title = "CoreDNS-1.6.2 Release" description = "CoreDNS-1.6.2 Release Notes." tags = ["Release", "1.6.2", "Notes"] release = "1.6.2" date = 2019-08-13T14:35:47+01:00 author = "coredns" +++ The CoreDNS team has released . This is a bug fix release, but it also features a new plugin called . It's compiled with Go 1.12.8 that incorporates fixes for HTTP/2 that may impact you if you use . Add to facilitate serving records from Microsoft Azure. Make the refresh frequency adjustable in the plugin. Fix the handling of truncated responses in . Andrey Meshkov, Chris O'Haver, Darshan Chaudhary, ethan, Matt Kulka and Miek Gieben. plugin/azure: Add plugin for Azure DNS (https://github.com/coredns/coredns/pull/2945) plugin/forward: Fix handling truncated responses in forward (https://github.com/coredns/coredns/pull/3110) plugin/kubernetes: Don't do a zone transfer for NS requests (https://github.com/coredns/coredns/pull/3098) plugin/kubernetes: fix NXDOMAIN/NODATA fallthough case (https://github.com/coredns/coredns/pull/3118) plugin/route53: make refresh frequency adjustable (https://github.com/coredns/coredns/pull/3083) plugin/route53: Various updates (https://github.com/coredns/coredns/pull/3108)
Project: Traefik Mesh (Orchestration & Management / Service Mesh)
File: traefik-mesh-v1.md

title: "Traefik Mesh Migrations Documentation" description: "Traefik Mesh v1.4 introduced a few key changes. Learn what those changes are and what actionable steps must be taken in the technical documentation." Traefik Mesh v1 {: .subtitle } Maesh has been renamed to Traefik Mesh in an effort to rename all of our products and make them look closer. Through this renaming process, a couple of things changed which might be worth mentioning for a migration process. All areas that changed are mentioned below with the appropriate actions needed to do. Everything called Maesh references to `v1.3`, while Traefik Mesh refers to `v1.4`. Prior to Traefik Mesh, environment variables were prefixed with `MAESH_`. Now they're prefixed with `TRAEFIKMESH` and the `MAESH_` prefix is deprecated. You need to decide on either using `MAESH` or `TRAEFIKMESH_` as mixing both will result in an error. The default configuration file name is changed from `maesh` to `traefik-mesh` as well. The well known internal DNS name, to opt in into the usage of Maesh was `.maesh`. Now, with the rebranding process this has been changed to `traefik.mesh` and thus, you now need to use the DNS name of `servicename.servicenamespace.traefik.maesh` to opt-in into the usage of Traefik Mesh. The old name `.maesh`, is deprecated and will be removed eventually. As part of the process, the docker-image has been moved from `containous/maesh` to `traefik/mesh`. The old image will not be updated anymore and `traefik/mesh` starts with `v1.4.0`. The new binary name is `traefik-mesh`, rather than `maesh` before. However, as Traefik Mesh is running inside k8s this change should not be critical as it's hidden by the docker-image name. As part of the rebranding process, the annotation prefix has changed. The annotation prefix `maesh.containo.us/` has been deprecated in favour of `mesh.traefik.io`. The `--debug` CLI flag is deprecated and will be removed in a future major release. Instead, you should use the new `--logLevel` flag with `debug` as value. The `--smi` CLI flag is deprecated and will be removed in a future major release. Instead, you should use the new and backward compatible `--acl` flag.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.10.0.md

+++ title = "CoreDNS-1.10.0 Release" description = "CoreDNS-1.10.0 Release Notes." tags = ["Release", "1.10.0", "Notes"] release = "1.10.0" date = "2022-09-16T00:00:00+00:00" author = "coredns" +++ This release adds the new view plugin, enabling advanced server-block routing configurations such as split-DNS. Ben Kochie Chris O'Haver Erik Johansson John Belamaric Marius Kimmina Ondej Benkovsk plugin/view: Advanced routing interface and new 'view' plugin (https://github.com/coredns/coredns/pull/5538) plugin/template: Add parseInt template function (https://github.com/coredns/coredns/pull/5609)
Project: Easegress (Orchestration & Management / API Gateway)
File: 7.05.Stream.md

Most Easegress traffic is message-based, but Easegress v2 pipeline is protocol independent, that's it supports stream-based traffic like TCP, and there's stream traffic even in HTTP. Another new feature in Easegress v2 is multiple requests/responses support, this requires the payload of a request/response can be read more than once, for message-based traffic, this is simple and easy to do, as Easegress can read the full message payload into memory. But for stream-based traffic, this is impossible, as the payload may require too much memory, and/or take too much time to read it into memory. To resolve the above issue, Easegress allow user or developer to configure whether a request/response is a stream, for example: We can set `clientMaxBodySize` of an HTTP server to a negative value to tell Easegress the request is a stream, and not a stream otherwise. Please refer for more information. We can set `serverMaxBodySize` of a `Proxy` filter to a negative value to tell Easegress the response is a stream, and not a stream otherwise. Please refer for more information. As we have mentioned above, the payload of a stream-based request/response can only be read once, so some features are not possible for these requests/responses, including: In the `template` of `RequestBuilder` or `ResponseBuilder`, you cannot access the payload(in HTTP, the body) of an existing stream-based request/response, while it is fine to access other information of the request/response. Stream-based request/response cannot be cached by `Proxy`. The `HeaderToJSON` filter does not support stream-based requests/responses. You cannot access the payload of stream-based request/response in a `WasmHost` filter.
Project: Apache bRPC (Orchestration & Management / Remote Procedure Call)
File: http_derivatives.md

Basics for accessing and serving http/h2 in brpc are listed in and . Following section names are protocol names that can be directly set to ChannelOptions.protocol. The content after colon is parameters for the protocol to select derivative behaviors dynamically, but the base protocol is still http/1.x or http/2. As a result, these protocols are displayed at server-side as http or h2/h2c only. Non-empty pb request is serialized to json and set to the body of the http/h2 request. The Controller.request_attachment() must be empty otherwise the RPC fails. Non-empty pb response is converted from a json which is parsed from the body of the http/h2 response. http/1.x behaves in this way by default, so "http" and "http:json" are just same. Non-empty pb request is serialized (in pb's wire format) and set to the body of the http/h2 request. The Controller.request_attachment() must be empty otherwise the RPC fails. Non-empty pb response is parsed from the body of the http/h2 response(in pb's wire format). http/2 behaves in this way by default, so "h2" and "h2:proto" are just same. Default protocol of . The detailed format is described in . Clients using brpc should be able to talk with gRPC after changing ChannelOptions.protocol to "h2:grpc". Servers using brpc should be accessible by gRPC clients automatically without changing the code. gRPC serializes message into pb wire format by default, so "h2:grpc" and "h2:grpc+proto" are just same. TODO: Other configurations for gRPC Comparing to h2:grpc, this protocol serializes messages into json instead of pb, which may not be supported by gRPC directly. For example, grpc-go users may reference to register the corresponding codec and turn on the support.
Project: APISIX (Orchestration & Management / API Gateway)
File: node-status.md

title: node-status keywords: Apache APISIX API Gateway Plugin Node status description: This document contains information about the Apache APISIX node-status Plugin. <!-- --> The `node-status` Plugin can be used get the status of requests to APISIX by exposing an API endpoint. None. This Plugin will add the endpoint `/apisix/status` to expose the status of APISIX. You may need to use the Plugin to expose the endpoint. To configure the `node-status` Plugin, you have to first enable it in your configuration file (`conf/config.yaml`): ```yaml title="conf/config.yaml" plugins: example-plugin limit-req jwt-auth zipkin node-status ...... ``` You have to the setup the Route for the status API and expose it using the Plugin. :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/ns -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/apisix/status", "plugins": { "public-api": {} } }' ``` Once you have configured the Plugin, you can make a request to the `apisix/status` endpoint to get the status: ```shell curl http://127.0.0.1:9080/apisix/status -i ``` ```shell HTTP/1.1 200 OK Date: Tue, 03 Nov 2020 11:12:55 GMT Content-Type: text/plain; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Server: APISIX web server {"status":{"total":"23","waiting":"0","accepted":"22","writing":"1","handled":"22","active":"1","reading":"0"},"id":"6790a064-8f61-44ba-a6d3-5df42f2b1bb3"} ``` The parameters in the response are described below: | Parameter | Description | |--|| | status | Status of APISIX. | | total | Total number of client requests. | | waiting | Number of idle client connections waiting for a request. | | accepted | Number of accepted client connections. | | writing | Number of connections to which APISIX is writing back a response. | | handled | Number of handled connections. Generally, this value is the same as `accepted` unless any a resource limit is reached. | | active | Number of active client connections including `waiting` connections. | | reading | Number of connections where APISIX is reading the request header. | | id | UID of APISIX instance saved in `apisix/conf/apisix.uid`. | To remove the Plugin, you can remove it from your configuration file (`conf/config.yaml`): ```yaml title="conf/config.yaml" plugins: example-plugin limit-req jwt-auth zipkin ...... ``` You can also remove the Route on `/apisix/status`: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/ns -H "X-API-KEY: $admin_key" -X DELETE ```
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting Kevin Bader (the current project maintainer). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: BFE (Orchestration & Management / Service Proxy)
File: context.md

Description: Judge if value of context key matches configured patterns Parameters | Parameter | Description | | | - | | key | String<br> context key | | value_list | String<br>a list of query values which are concatenated using &#124; | | case_insensitive | Boolean<br>case insensitive | Example ```go reqcontextvalue_in("cmd", "add|del|list", true) ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: binary-packages.md

title: Apache Mesos - Getting started using Binaries. layout: documentation Download and install . The RPM installation creates the directory `/var/lib/mesos` that can be used as a work directory. Start the Mesos master with the following command: $ mesos-master --work_dir=/var/lib/mesos On a different terminal, start the Mesos agent, and associate it with the Mesos master started above: $ mesos-agent --work_dir=/var/lib/mesos --master=127.0.0.1:5050 This is the simplest way to try out Mesos after downloading the RPM. For more complex and production setup instructions refer to the section of the docs.
Project: TARS (Orchestration & Management / Remote Procedure Call)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: "[FEATURE]" labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.