cwielenb/CNCF-Dataset huggingface dataset:
Project: Gloo (Orchestration & Management / API Gateway)
File: hashicorp.md

title: HashiCorp Setup weight: 20 description: How to prepare a HashiCorp stack for Gloo Edge installation. Installing Gloo Edge will require an environment for installation. In this document we will review how to prepare an environment that uses the HashiCorp family of products for the installation of Gloo Edge. HashiCorp has the following products that can be utilized by Gloo Edge for different functions: Nomad* - A simple and flexible workload orchestrator that can deploy the Gloo Edge containers on managed hosts. Consul* - A service networking solution that can provide both service discovery and key/value storage for Gloo Edge. Vault* - A secrets lifecycle management tool that can provide secure storage of secrets within Gloo Edge. HashiCorp provides excellent and on how to deploy Nomad in a development or production environment. The Nomad agent is installed on nodes that will host workloads deployed by a Nomad job. In the case of Gloo Edge, the hosts must support the deployment of containers. You should have the most recent version of Nomad downloaded and the Nomad agent deployed on any worker nodes on which you want to install Gloo Edge. You can also run Nomad locally in development mode. HashiCorp provides and on how to deploy Consul in a development or production environment. Consul can be deployed on bare-metal, virtual machines, or containers. It is possible to deploy Consul on Kubernetes, and then use Consul for service discovery and configuration data storage instead of using Custom Resources and Kubernetes service discovery. You should have the most recent version of Consul downloaded and deployed in a location that is addressable by your target Gloo Edge environment. Consul and Gloo Edge do not have to run on the same Nomad nodes or Kubernetes cluster. You can also run Consul locally in development mode. HashiCorp provides and on how to deploy Vault in a development or production environment. Vault can be deployed on bare-metal, virtual machines, or containers. It is possible to deploy Vault on Kubernetes, and then use Vault for secrets management instead of using Secrets in Kubernetes. You should have the most recent version of Vault downloaded and deployed in a location that is addressable by your target Gloo Edge environment. Vault and Gloo Edge do not have to run on the same Nomad nodes or Kubernetes cluster. You can also run Vault locally in development mode. Once you have prepared a suitable environment for the deployment of Gloo Edge on HashiCorp's products, you can for getting Gloo Edge deployed.
Project: kube-rs (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

We provide security updates for the two most recent minor versions released on `crates.io`. For example, if `0.70.1` is the most recent stable version, we will address security updates for `0.69` and later. Once `0.71.1` is released, we will no longer provide updates for `0.69` releases. To report a security problem in Kube-rs, please contact at least two These people will help diagnose the severity of the issue and determine how to address the issue. Issues deemed to be non-critical will be filed as GitHub issues. Critical issues will receive immediate attention and be fixed as quickly as possible. When serious security problems in Kube-rs are discovered and corrected, we issue a security advisory, describing the problem and containing a pointer to the fix. These are announced the , to our github issues under the label `critical`, as well as discord and other primary communication channels. Security issues are fixed as soon as possible, and the fixes are propagated to the stable branches as fast as possible. However, when a vulnerability is found during a code audit, or when several other issues are likely to be spotted and fixed in the near future, the security team may delay the release of a Security Advisory, so that one unique, comprehensive Security Advisory covering several vulnerabilities can be issued. Communication with vendors and other distributions shipping the same code may also cause these delays.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: file-manage.md

When the third-party jar needs to be used in the scheduling process or the user needs to customize the script, the related operations can be completed on this page. The file types that can be created include: `txt`, `log`, `sh`, `conf`, `py`, `java` etc. And you can edit, rename, download and delete files. _Note:_ When you manage files as `admin`, remember to set up `tenant` for `admin` first. The file format supports the following types: txt, log, sh, conf, cfg, py, java, sql, xml, hql, properties. Click the "Upload File" button to upload, drag the file to the upload area, the file name will be automatically completed with the uploaded file name. For viewable file types, click the file name to view the file details. Click the "Download" button in the file list to download the file or click the "Download" button in the upper right corner of the file details to download the file. File list -> Click the "Delete" button to delete the specified file. Note: File name or source name of your local file can not contain specific characters like `.` or `/` when you trying to upload, create or rename file in resource center. This sample mainly uses a simple shell script to demonstrate how to use Content Center files in a workflow definition. The same is true for tasks such as MR and Spark that require jar packages. Create a shell file, print `hello world`. In the workflow definition module of project Manage, create a new workflow using a shell task. Script: 'sh resource/hello.sh' Resource: Select 'resource/hello.sh' Notice: When using a resource file in the script, the file name needs to be the same as the full path of the selected resource: For example: if the resource path is `resource/hello.sh`, you need to use the full path of `resource/hello.sh` to use it in the script. You can view the log results of the node running in the workflow instance. As shown below:
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Thanks for taking the time to contribute! The following is a set of guidelines for contributing to RIG and its packages, which are hosted in the on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. Use issues for everything. For a small change, just send a PR. For bigger changes open an issue for discussion before sending a PR. PR should have: Test case Documentation (e.g., moduledoc, developer's guide, operator's guide) Changelog entry You can also contribute by: Reporting issues Suggesting new features or enhancements Improve/fix documentation This project and everyone participating in it is governed by our . By participating, you are expected to uphold this code. Please report unacceptable behavior to Kevin Bader, who is the current project maintainer. We have a where the community chimes in with helpful advice if you have questions. Since this is a standard mix project, typical mix commands work as expected: Generate documentation with `mix docs`. Run unit tests with `mix test` and see the test coverage with `MIX_ENV=test mix coveralls.html --umbrella`, which creates a report at `doc/excoveralls.html`. For static analysis, we use : Run the linter with `mix credo --strict`. There is a smoke-test test-suite that can be started with a mix task as well: Run smoke tests with `mix smoke_test`. Alternatively, you can run the tests directly with `docker-compose -f smoke_tests.docker-compose.yml up -d --build`. To see smoke tests logs run `docker logs -f rig`. To re-run smoke tests without re-creating entire environment run `docker-compose -f smoke_tests.docker-compose.yml up --no-deps --build rig`. We follow the . Before submitting a PR: Please write tests. Make sure you run all tests and check the linter (credo) for warnings. Think about whether it makes sense to document the change in some way. For smaller, internal changes, inline documentation might be sufficient (moduledoc), while more visible ones might warrant a change to the , the or the . Update `CHANGELOG.md` file with your current change in form of ``, and choose a suitable section (i.e., changed, added, fixed, removed, deprecated). When we make a significant decision in how to write code, or how to maintain the project and what we can or cannot support, we will document it using . Take a look at the directory for existings ADRs. If you have a question around how we do things, check to see if it is documented there. If it is not documented there, please ask us - chances are you're not the only one wondering. Of course, also feel free to challenge the decisions by starting a discussion on the mailing list.
Project: GoFr (Orchestration & Management / Remote Procedure Call)
File: SECURITY.md

Following versions are being supported for security updates. | Version | Supported | | - | | | 1.0.x | :whitecheckmark: | To report a vulnerability, please file an issue on this repo and add "security" label. Security related issues will be prioritised over others. We strive to triage the issue within a single working day.
Project: APISIX (Orchestration & Management / API Gateway)
File: ocsp-stapling.md

title: ocsp-stapling keywords: Apache APISIX Plugin ocsp-stapling description: This document contains information about the Apache APISIX ocsp-stapling Plugin. <!-- --> The `ocsp-stapling` Plugin dynamically sets the behavior of in Nginx. This Plugin is disabled by default. Modify the config file to enable the plugin: ```yaml title="./conf/config.yaml" plugins: ... ocsp-stapling ``` After modifying the config file, reload APISIX or send an hot-loaded HTTP request through the Admin API to take effect: :::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/plugins/reload -H "X-API-KEY: $admin_key" -X PUT ``` The attributes of this plugin are stored in specific field `ocsp_stapling` within SSL Resource. | Name | Type | Required | Default | Valid values | Description | |-|-|-||--|--| | enabled | boolean | False | false | | Like the `ssl_stapling` directive, enables or disables OCSP stapling feature. | | skipverify | boolean | False | false | | Like the `sslstapling_verify` directive, enables or disables verification of OCSP responses. | | cache_ttl | integer | False | 3600 | >= 60 | Specifies the expired time of OCSP response cache. | You should create an SSL Resource first, and the certificate of the server certificate issuer should be known. Normally the fullchain certificate works fine. Create an SSL Resource as such: ```shell curl http://127.0.0.1:9180/apisix/admin/ssls/1 \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "cert" : "'"$(cat server.crt)"'", "key": "'"$(cat server.key)"'", "snis": ["test.com"], "ocsp_stapling": { "enabled": true } }' ``` Next, establish a secure connection to the server, request the SSL/TLS session status, and display the output from the server: ```shell echo -n "Q" | openssl s_client -status -connect localhost:9443 -servername test.com 2>&1 | cat ``` ``` ... CONNECTED(00000003) OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) ... ``` To disable OCSP stapling feature, you can make a request as shown below: ```shell curl http://127.0.0.1:9180/apisix/admin/ssls/1 \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "cert" : "'"$(cat server.crt)"'", "key": "'"$(cat server.key)"'", "snis": ["test.com"], "ocsp_stapling": { "enabled": false } }' ``` Make sure all your SSL Resource doesn't contains `ocsp_stapling` field anymore. To remove this field, you can make a request as shown below: ```shell curl http://127.0.0.1:9180/apisix/admin/ssls/1 \ -H "X-API-KEY: $admin_key" -X PATCH -d ' { "ocsp_stapling": null }' ``` Modify the config file `./conf/config.yaml` to disable the plugin: ```yaml title="./conf/config.yaml" plugins: ... ``` After modifying the config file, reload APISIX or send an hot-loaded HTTP request through the Admin API to take effect: ```shell curl http://127.0.0.1:9180/apisix/admin/plugins/reload -H "X-API-KEY: $admin_key" -X PUT ```
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.8.6.md

+++ title = "CoreDNS-1.8.6 Release" description = "CoreDNS-1.8.6 Release Notes." tags = ["Release", "1.8.6", "Notes"] release = "1.8.6" date = "2021-10-07T00:00:00+00:00" author = "coredns" +++ This is a small bug fix release. Chris O'Haver, Miek Gieben. plugin/kubernetes: fix reload panic (https://github.com/coredns/coredns/pull/4881) plugin/kubernetes: Don't use pod names longer than 63 characters as dns labels (https://github.com/coredns/coredns/pull/4908)
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_proxy_dump.md

title: "glooctl proxy dump" weight: 5 dump Envoy config from one of the proxy instances ``` glooctl proxy dump [flags] ``` ``` -h, --help help for dump ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string the name of the proxy service/deployment to use (default "gateway-proxy") -n, --namespace string namespace for reading or writing resources (default "gloo-system") --port string the name of the service port to connect to (default "http") --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - interact with proxy instances managed by Gloo
Project: Traefik (Orchestration & Management / API Gateway)
File: dashboard.md

title: "Traefik Dashboard Documentation" description: "The dashboard shows you the current active routes handled by Traefik Proxy in one central place. Read the technical documentation to learn its operations." See What's Going On {: .subtitle } The dashboard is the central place that shows you the current active routes handled by Traefik. <figure> <img src="../../assets/img/webui-dashboard.png" alt="Dashboard - Providers" /> <figcaption>The dashboard in action</figcaption> </figure> The dashboard is available at the same location as the but on the path `/dashboard/` by default. !!! warning "The trailing slash `/` in `/dashboard/` is mandatory" There are 2 ways to configure and access the dashboard: !!! note "" There is also a redirect of the path `/` to the path `/dashboard/`, but one should not rely on that property as it is bound to change, and it might make for confusing routing rules anyway. This is the recommended method. Start by enabling the dashboard by using the following option from on the : ```yaml tab="File (YAML)" api: dashboard: true ``` ```toml tab="File (TOML)" [api] dashboard = true ``` ```bash tab="CLI" --api.dashboard=true ``` Then define a routing configuration on Traefik itself, with a router attached to the service `api@internal` in the , to allow defining: One or more security features through like authentication (, , ) or . A for accessing the dashboard, through Traefik itself (sometimes referred to as "Traefik-ception"). As underlined in the , the defined for Traefik must match the path prefixes `/api` and `/dashboard`. We recommend using a "Host Based rule" as ```Host(`traefik.example.com`)``` to match everything on the host domain, or to make sure that the defined rule captures both prefixes: ```bash tab="Host Rule" rule = "Host(`traefik.example.com`)" ``` ```bash tab="Path Prefix Rule" rule = "PathPrefix(`/api`) || PathPrefix(`/dashboard`)" ``` ```bash tab="Combination of Rules" rule = "Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))" ``` ??? example "Dashboard Dynamic Configuration Examples" --8<-- "content/operations/include-dashboard-examples.md" This mode is not recommended because it does not allow the use of security features. To enable the "insecure mode", use the following options from : ```yaml tab="File (YAML)" api: dashboard: true insecure: true ``` ```toml tab="File (TOML)" [api] dashboard = true insecure = true ``` ```bash tab="CLI" --api.dashboard=true --api.insecure=true ``` You can now access the dashboard on the port `8080` of the Traefik instance, at the following URL: `http://<Traefik IP>:8080/dashboard/` (trailing slash is mandatory). {!traefik-for-business-applications.md!}
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Tell us about a problem you are experiencing /kind bug What steps did you take and what happened: [A clear and concise description of what the bug is.] What did you expect to happen: Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Environment: Kubeflow version: (version number can be found at the bottom left corner of the Kubeflow dashboard): kfctl version: (use `kfctl version`): Kubernetes platform: (e.g. `minikube`) Kubernetes version: (use `kubectl version`): OS (e.g. from `/etc/os-release`):
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: pull_request_review_guide.md

This document outlines how to review a pull request and best practices and tips for reviewing pull requests in the OSM repository. Reviews are welcomed from everyone although each pull request (PR) needs at least two approvals from core maintainers from the repository before it can be merged into the main branch. Github outlines how to review a pull request and OSM does not deviate from this standard process. Leave comments if the PR author can make adjustments to write better Go according to the . Ask questions if the code does not make sense to you. Make sure each PR includes the appropriate unit tests and e2e tests and read the tests to make sure you understand what the author is changing and what is the expected behavior of the code. Although squashing commits , remind the author to squash commits into a single commit when it makes sense. Each commit merged into the main branch should be able to pass all CI tests. If the PR author is not a core maintainer and you are a core maintainer, merge the pull request when it has the required number of approvals. Add to this list of best practices and tips
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-01-20-mesos-0-21-1-released.md

layout: post title: Apache Mesos 0.21.1 Released permalink: /blog/mesos-0-21-1-released/ published: true post_author: display_name: Tim Chen twitter: tnachen tags: Release The latest Mesos release, 0.21.1 is now available for . This release includes bug fixes that fixes a few performance issues and isolator cleanup, and also includes a few improvements around building mesos on OSX and the docker containerizer. - Isolator cleanup failures shouldn't cause TASK_LOST. - Libprocess generates invalid HTTP - Large number of connections slows statistics.json responses. - Performance issue in libprocess SocketManager. - Docker kill does not allow containers to exit gracefully - Improve configure to find apr and svn libraries/headers in OSX Full release notes are available in the release . Upgrading to 0.21.1 can be done seamlessly on a 0.21.0 cluster. If upgrading from an earlier version, please refer to the documentation. Thanks to all the contributors for 0.21.1: Timothy Chen, Benjamin Mahler, Kapil Arya, Ryan Thomas, Jie Yu, Dario Rexin and Michael Park.
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: checklist-command.md

Subcommands should always be preferred over adding more top-level commands. Code flow for commands is generally: ``` CLI (command/) -> API Client (api/) -> HTTP API (command/agent) -> RPC (nomad/) ``` [ ] Consider similar commands in Consul, Vault, and other tools. Is there prior art we should match? Arguments, flags, env vars, etc? [ ] New file in `command/` or in an existing file if a subcommand [ ] For nested commands make sure all intermediary subcommands exist (for example, `nomad acl`, `nomad acl policy`, and `nomad acl policy apply` must all be valid commands) [ ] Test new command in `command/` package [ ] Implement autocomplete [ ] Implement `-json` (returns raw API response) [ ] Implement `-t` (format API response using gotemplate) [ ] Implement `-verbose` (expands truncated UUIDs, adds other detail) [ ] Update help text [ ] Register new command in `command/commands.go` [ ] If the command has a `status` subcommand consider adding a search context in `nomad/search_endpoint.go` and update `command/status.go` [ ] Implement and test new HTTP endpoint in `command/agent/<command>_endpoint.go` [ ] Register new URL paths in `command/agent/http.go` [ ] Implement and test new RPC endpoint in `nomad/<command>_endpoint.go` [ ] Implement and test new Client RPC endpoint in `client/<command>_endpoint.go` (For client endpoints like Filesystem only) [ ] Implement and test new `api/` package Request and Response structs [ ] Implement and test new `api/` package helper methods [ ] Implement and test new `nomad/structs/` package Request and Response structs [ ] Changelog [ ] API docs https://developer.hashicorp.com/nomad/api [ ] CLI docs https://developer.hashicorp.com/nomad/docs/commands [ ] Consider if it needs a guide https://developer.hashicorp.com/nomad/guides/index.html
Project: APIOAK (Orchestration & Management / API Gateway)
File: install-dependencies.md

CentOS 7 ======== Install OpenResty and other required dependencies. ```shell sudo yum -y install yum-utils sudo yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo sudo yum -y install gcc \ gcc-c++ \ git \ curl \ wget \ openresty \ openresty-resty \ automake \ autoconf \ luarocks \ lua-devel \ libtool \ pcre-devel ``` Install Consul ```shell sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo sudo yum -y install consul https://developer.hashicorp.com/consul/downloads sudo consul agent -dev ``` Ubuntu 18 ========== Install OpenResty and other required dependencies. ```shell wget -qO - https://openresty.org/package/pubkey.gpg | sudo apt-key add - sudo apt-get update sudo apt-get -y install software-properties-common sudo add-apt-repository -y "deb http://openresty.org/package/ubuntu $(lsb_release -sc) main" sudo apt-get update sudo apt-get -y install build-essential \ gcc \ g++ \ git \ curl \ wget \ openresty \ openresty-resty \ automake \ autoconf \ luarocks \ libtool \ libpcre3-dev sudo openresty -s stop ``` Install Consul ```shell wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list sudo apt update && sudo apt install consul sudo consul agent -dev ```