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

Before everything we are going to do, please refer to to install Fluid on your Kubernetes Cluster, and make sure all the components used by Fluid are ready like this: ```shell $ kubectl get pod -n fluid-system NAME READY STATUS RESTARTS AGE alluxioruntime-controller-5b64fdbbb-84pc6 1/1 Running 0 8h csi-nodeplugin-fluid-fwgjh 2/2 Running 0 8h csi-nodeplugin-fluid-ll8bq 2/2 Running 0 8h dataset-controller-5b7848dbbb-n44dj 1/1 Running 0 8h ``` Normally, you shall see a Pod named "dataset-controller", a Pod named "alluxioruntime-controller" and several Pods named "csi-nodeplugin". The num of "csi-nodeplugin" Pods depends on how many nodes your Kubernetes cluster have(e.g. 2 in this demo), so please make sure all "csi-nodeplugin" Pods are working properly. The access mode of the dataset is set to ReadOnlyMany when user doesn`t specif the access mode. If there is a need to modify the default access mode, you need to specify it in spec.accessModes[] before creating it. The currently supported access modes are `ReadOnlyMany` : the volume can be mounted as read-only by many nodes `ReadWriteMany` : the volume can be mounted as read-write by many nodes This demo sets the access method of the dataset to ReadWriteMany. ``` apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: demo spec: mounts: mountPoint: https://mirrors.bit.edu.cn/apache/hbase/2.4.14/ name: hbase path: "/" accessModes: ReadWriteMany ```
Project: Contour (Orchestration & Management / Service Proxy)
File: envoy-container-draining.md

It's possible for the Envoy containers to become stuck in an unready/draining state. This is an unintended side effect of the shutdown-manager sidecar container being restarted by the kubelet. For more details on exactly how this happens, see . If you observe Envoy containers in this state, you should `kubectl delete` them to allow new Pods to be created to replace them. To make this issue less likely to occur, you should: ensure you have on all your containers ensure you do not have a liveness probe on the shutdown-manager sidecar container in the envoy daemonset (this was removed from the example YAML in Contour 1.24.0). If the above are not sufficient for preventing the issue, you may also add a liveness probe to the envoy container itself, like the following: ```yaml livenessProbe: httpGet: path: /ready port: 8002 initialDelaySeconds: 15 periodSeconds: 5 failureThreshold: 6 ``` This will cause the kubelet to restart the envoy container if it does get stuck in this state, resulting in a return to normal operations load balancing traffic. Note that in this case, it's possible that a graceful drain of connections may or may not occur, depending on the exact sequence of operations that preceded the envoy container failing the liveness probe.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-policy-studio-config.md

As an API editor, you can define flows. Each flow will apply to a path in the order defined. You can define a name and a description but if empty the name of the flow will be generated with the operator ("Starts with" or "Equals"), the path and the HTTP methods. You can also define an Expression Language (EL) type condition. This expression language is a powerful language that supports querying and manipulating an object graph and is based on the SpEL (Spring Expression Language). This means that you can do everything described in the link. Get the value of the property my-property defined in properties: `{#properties['my-property']}` Get the value of the Content-Type header for an incoming HTTP request: `{#request.headers['content-type']}` Get the second part of the request path: `{#request.paths[1]}` Get the value of the user-id attribute for an incoming HTTP request `{#context.attributes['user-id']}` Get the value of the plan attribute for an incoming HTTP request `{#context.attributes['plan']}`
Project: Nacos (Orchestration & Management / Coordination & Service Discovery)
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, education, socio-economic status, 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 the project team at users-nacos@googlegroups.com. 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: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: rainbond.md

This section describes the one-click deployment of high availability DolphinScheduler clusters through the cloud native application management platform. This method is suitable for users who don't know much about complex technologies such as `Kubernetes`, lowering the threshold for deploying DolphinScheduler in `Kubernetes` mode. Available Rainbond cloud native application management platform is a prerequisiteplease refer to the official `Rainbond` documentation Go to Rainbond Platform Management -> App Marketplace -> Open Source App Store and search for dolphinScheduler to find the DolphinScheduler application. Click install on the right side of DolphinScheduler to go to the installation page. Fill in the corresponding information and click `OK` to start the installation. You will get automatically redirected to the application view. | Select item | Description | |--|-| | Team name | user workspaceIsolate by namespace | | Cluster name | select kubernetes cluster | | Select app | select application | | app version | select DolphinScheduler version | Wait a few minutes, the installation completes and `DolphinScheduler` will be running. Click the `access` button in the application to access the DolphinScheduler-API components through the domain name provided by Rainbond by default. Default user password is admin/dolphinscheduler123. DolphinScheduler APIMasterWorker all support scaling multiple instances, ensuring the high availability of the entire service. Take `worker` as an example: enter the `component -> Telescopic` page, and set the number of instances. To verify `worker` node, enter `DolphinScheduler UI -> Monitoring -> Worker` page to view detailed node information. API and Worker Services share the configuration file `/opt/dolphinscheduler/conf/common.properties`. To modify the configurations, you only need to modify that of the API service. Worker service is installed with default `Python3`you can add environment variables `PYTHON_LAUNCHER=/usr/bin/python3` Take `DataX` as an example: Install the pluginRainbond Team View -> Plugin -> Install plugin from the App Store -> search `initialization plugin` Install. Open plugin.enter Worker component -> plugin -> open `initialization plugin` and modify the configuration. FILE_URLhttp://datax-opensource.oss-cn-hangzhou.aliyuncs.com/datax.tar.gz FILE_PATH/opt/soft LOCK_PATH/opt/soft Update component, the plug-in `Datax` will be downloaded automatically and decompress to `/opt/soft`
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: migration_guide.md

<! Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> All changes are backward-compatible so far. All changes are backward compatible. All changes are backward compatible. A custom `Error` enum has been introduced to replace all existing errors and the `failure` crate has been replaced by `thiserror`. This means that all public functions returning `Result<T, failure::Error>` will now return `Result<T, avro::Error>` and that you can pattern match on `Error` variants if you want to gather more information about the error. For example, code that used to be like this: ```rust match decoded { Ok(msg) => Ok(msg.to_string()), // assuming you were reading a Duration Err(ref e) => match e.downcast_ref::<SchemaResolutionError>() { Some() => Ok("default".tostring()), None => Err(format!("Unexpected error: {}", e)), }, } ``` now becomes: ```rust match decoded { Ok(msg) => Ok(msg.to_string()), Err(Error::ReadDuration()) => Ok("default".tostring()), Err(e) => Err(format!("Unexpected error: {}", e)), } ``` Please note that all instances of: `DecodeError` `ValidationError` `DeError` `SerError` `ParseSchemaError` `SchemaResolutionError` must be replaced by `Error`. The `ToAvro` trait has been deprecated in favor of `From<T>` for `Value` implementations. Code like the following: ```rust use crate::types::{Record, ToAvro, Value}; let expected: Value = record.avro(); ``` should be updated to: ```rust use crate::types::{Record, Value}; let expected: Value = record.into(); ``` Using the `ToAvro` trait will result in a deprecation warning. The trait will be removed in future versions. The `digest` crate has been updated to version `0.9`. If you were using the `digest::Digest` trait from version `0.8`, you must update to the one defined in `0.9`. `Writer::into_inner()` now calls `flush()` and returns a `Result`. This means that code like ```rust writer.append_ser(test)?; writer.flush()?; let input = writer.into_inner(); ``` can be simplified into ```rust writer.append_ser(test)?; let input = writer.into_inner()?; ``` There is no harm in leaving old calls to `flush()` around.
Project: OpenResty (Orchestration & Management / Service Proxy)
File: README.md

File | Purpose | Format | Info -|-|-|- | Replacement dictionary (creating this file will override the default dictionary) | one word per line | | Add words to the dictionary | one word per line (only letters and `'`s allowed) | | Remove words from the dictionary (after allow) | grep pattern matching whole dictionary words | | Files to ignore entirely | perl regular expression | | Only check matching files (applied after excludes) | perl regular expression | | Patterns to ignore from checked lines | perl regular expression (order matters, first match wins) | | Patterns to flag in checked lines | perl regular expression (order matters, first match wins) | | Expected words that aren't in the dictionary | one word per line (sorted, alphabetically) | | Supplement for GitHub comment when unrecognized words are found | GitHub Markdown | Note: you can replace any of these files with a directory by the same name (minus the suffix) and then include multiple files inside that directory (with that suffix) to merge multiple files together.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: boost.md

README for the Mesos third party Boost distribution. We use the Boost `bcp` utility to bundle only the minimum subset of Boost headers used by Mesos. See: http://www.boost.org/doc/libs/1810/tools/bcp/doc/html/index.html ``` $ tar -zxvf boost181_0.tar.gz $ cd boost181_0 $ ./bootstrap.sh $ ./b2 tools/bcp $ find </path/to/mesos> -name ".cpp" -o -name ".hpp" > files.txt $ mkdir ../boost-1.81.0 $ cat files.txt | xargs -I {} ./dist/bin/bcp --scan --boost=./ {} ../boost-1.81.0 $ cd ../boost-1.81.0 $ rm -r libs $ cd .. $ GZIP=--best tar -zcf boost-1.81.0.tar.gz boost-1.81.0 $ cp boost-1.81.0.tar.gz </path/to/mesos>/3rdparty/ $ openssl sha256 3rdparty/boost-1.81.0.tar.gz ```
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: bug_report.md

name: Bug/issue report about: Report an issue to help us improve title: '' labels: 'kind/bug' assignees: '' <!-- A brief description of the issue. --> <!-- A brief description of what you expected to happen. --> <!-- Add screenshots, if applicable, to help explain your problem. --> OS: [e.g. Ubuntu] Browser: [e.g. Chrome, Safari] Version: [e.g. 22] Device: [e.g. laptop, iPhone 8] Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Add any other context about the problem here. The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the . See the section of the readme.md and other , too. See Meshery site designs in this . Fill-in the and join the for access. Wireframes and in Figma
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: INSTALL.md

If you want to use the latest version of this library, use go1.16+ and run: ```sh go get k8s.io/client-go@latest ``` This will record a dependency on `k8s.io/client-go` in your go module. You can now import and use the `k8s.io/client-go` APIs in your project. The next time you `go build`, `go test`, or `go run` your project, `k8s.io/client-go` and its dependencies will be downloaded (if needed), and detailed dependency version info will be added to your `go.mod` file (or you can also run `go mod tidy` to do this directly). If you want to use a particular version of the `k8s.io/client-go` library, you can indicate which version of `client-go` your project requires: If you are using Kubernetes versions >= `v1.17.0`, use a corresponding `v0.x.y` tag. For example, `k8s.io/client-go@v0.20.4` corresponds to Kubernetes `v1.20.4`: ```sh go get k8s.io/client-go@v0.20.4 ``` If you are using Kubernetes versions < `v1.17.0`, use a corresponding `kubernetes-1.x.y` tag. For example, `k8s.io/client-go@kubernetes-1.16.3` corresponds to Kubernetes `v1.16.3`: ```sh go get k8s.io/client-go@kubernetes-1.16.3 ``` You can now import and use the `k8s.io/client-go` APIs in your project. The next time you `go build`, `go test`, or `go run` your project, `k8s.io/client-go` and its dependencies will be downloaded (if needed), and detailed dependency version info will be added to your `go.mod` file (or you can also run `go mod tidy` to do this directly). If you get a message like `module k8s.io/client-go@latest found (v1.5.2), but does not contain package k8s.io/client-go/...`, you are likely using a go version prior to 1.16 and must explicitly specify the k8s.io/client-go version you want. For example: ```sh go get k8s.io/client-go@v0.20.4 ``` If you get a message like `module k8s.io/api@latest found, but does not contain package k8s.io/api/auditregistration/v1alpha1`, something in your build is likely requiring an old version of `k8s.io/client-go` like `v11.0.0+incompatible`. First, try to fetch a more recent version. For example: ```sh go get k8s.io/client-go@v0.20.4 ``` If that doesn't resolve the problem, see what is requiring an `...+incompatible` version of client-go, and update to use a newer version of that library, if possible: ```sh go mod graph | grep " k8s.io/client-go@" ``` As a last resort, you can force the build to use a specific version of client-go, even if some of your dependencies still want `...+incompatible` versions. For example: ```sh go mod edit -replace=k8s.io/client-go=k8s.io/client-go@v0.20.4 go get k8s.io/client-go@v0.20.4 ``` If you get a message like `cannot use path@version syntax in GOPATH mode`, you likely do not have go modules enabled. This should be on by default in all supported versions of Go. ```sh export GO111MODULE=on ``` Ensure your project has a `go.mod` file defined at the root of your project. If you do not already have one, `go mod init` will create one for you: ```sh go mod init ```
Project: Docker Swarm (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Easegress (Orchestration & Management / API Gateway)
File: 4.3.EaseMesh.md

`EaseMesh` is a service mesh that is compatible with the Spring Cloud ecosystem. It is based on `Easegress` for the sidecar of service management and `EaseAgent` for the monitor of service observing. Non-intrusive Design: Zero code modification for Java Spring Cloud application migration, only small configuration update needed. Java Register/Discovery: Compatible with popular Java Spring Cloud ecosystem's Service registry/discovery. Multiple tenants(namespace) Supporting multiple tenants' service registration, isolate services from different tenants. Share (global) tenant Support share tenants, all services have visibility to the service registered in the global tenant. Compatible Be compatible with the Eureka registry. Be compatible with the Consul registry. Be compatible with the Nacos registry. Extensibility Support registering services with metadata. Resource Management: Rely on Kubernetes platform for CPU/Memory resources management. Traffic Orchestration Rich Routing Rules: Exact path, path prefix, regular expression of the path, method, headers. Traffic Splitting Coloring & Scheduling east-west and north-south traffic to configured services. LoadBalance Support Round Robin, Weight Round Robin, Random, Hash by Client IP Address, Hash by HTTP Headers. Resilience: Including Timeout/CircuitBreaker/Retryer/Limiter, completely follow sophisticated resilience design. Resilience&Fault Tolerance Circuit breaker: Temporarily blocks possible failures. Rate limiter: Limits the rate of incoming requests. Retryer: Repeats failed executions. Time limiter: Limits the duration of execution. Chaos engineering Fault injection Working in progress. Delay injection Working in progress. Observability: Logs Access Logs Generate HTTP access log for all requests per service. Application log Automatically inject the tracing context into log data. Tracing JDBC Tracing for invocation of the JDBC. HTTP Request Tracing for HTTP RPC. Kafka Tracing for messages delivered by Kafka. Redis Tracing for Redis cache accessing. RabbitMQ Tracing for messages delivered by the RabbitMQ. Sampling Support probabilistic sampling. Support QPS sampling. Metrics HTTP Request Reporting throughput latency per URL. JDBC Reporting throughput and latency per SQL. Kafka Reporting throughput and latency per consumer, producer, and topic. Redis Reporting throughput and latency per method. RabbitMQ Reporting throughput and latency per topic. Security mTLS Working in progress. mTLS Enforcement Working in progress. External CA certificate Working in progress. Service-to-Service Authorization Rules Working in progress. The throughput is represented by m1, m5, m15 The latency is represented by P99, P98, P95, P90, P80, P75, P50, etc... For more details, please check .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: tools.md

title: Apache Mesos - Tools layout: documentation These tools make it easy to set up and run a Mesos cluster. to collect Mesos cluster metrics. for collecting Mesos cluster metrics and statistics about running executors. for launching a Mesos cluster on a set of machines. Install Mesos and configure master and agent. This cookbook currently supports installation from the Mesosphere packages. Install Mesos and configure master and agent. This cookbook supports installation from source or the Mesosphere packages. Application cookbook for installing the Apache Mesos cluster manager. This cookbook installs Mesos via packages provided by Mesosphere. This is a Puppet module for managing Mesos nodes in a cluster. Spin up your Mesos Cluster with Vagrant! Quickly build Mesos sandbox environments using Vagrant. Mesos, Marathon, Docker, HAProxy and service discovery, using Ansible and Vagrant. Build a Mesos Cluster with Vagrant and Puppet (and optionally Consul.io)! If you want to hack on Mesos or write a new framework, these tools will help. to automatically apply some of the style rules dictated by the . Write a Mesos framework in Go! Comes with an example scheduler and executor. This is a giter8 template. The result of applying this template is a bare-bones Apache Mesos framework in Scala using SBT for builds and Vagrant for testing on a singleton cluster. A simple Mesos "Hello World": downloads and starts a web server on every node in the cluster. Hack on Mesos in Xcode. Can't find yours in the list? Please submit a patch, or email user@mesos.apache.org and we'll add you!
Project: Istio (Orchestration & Management / Service Mesh)
File: pull_request_template.md

Please provide a description of this PR: To help us figure out who should review this PR, please put an X in all the areas that this PR affects. [ ] Ambient [ ] Configuration Infrastructure [ ] Docs [ ] Dual Stack [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Policies and Telemetry [ ] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure Please check any characteristics that apply to this pull request. changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.