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

You may encounter various problems during installation or development in Fluid. Usually, logs are useful for debugging. But the Runtime containers where Fluid's underlying Distributed Cache Engine is running, are distributed on different hosts under distributed environment, so it's quite annoying to collect these logs one by one. To make this troublesome work easier, we provided a shell script to help users collect logs more quickly. This document describes how to use that script. Alluxio: ```wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-alluxio.sh``` JuiceFS: ```wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-juicefs.sh``` GooseFS: ```wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-goosefs.sh``` JindoFS: ```wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-jindo.sh``` Fluid provides different diagnostic scripts for different Runtimes, but the usage is the same. You can download the runtime diagnostic scripts you use: ```shell wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-alluxio.sh wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-juicefs.sh wget https://raw.githubusercontent.com/fluid-cloudnative/fluid/master/tools/diagnose-fluid-goosefs.sh ``` Make sure that script is executable, take `diagnose-fluid-alluxio.sh` as an example: ```shell $ chmod a+x diagnose-fluid-alluxio.sh ``` Get help message ```shell $ ./diagnose-fluid-alluxio.sh Usage: ./diagnose-fluid-alluxio.sh COMMAND [OPTIONS] COMMAND: help Display this help message. collect Collect pods logs of controller and runtime. OPTIONS: -r, --name name Set the name of runtime. -n, --namespace name Set the namespace of runtime. ``` Collect logs You can collect all the Runtime container logs for given name and namespace with: ```shell $ ./diagnose-fluid-alluxio.sh collect --name cifar10 --namespace default ``` > NOTES: > > As you can see from above command and help message, option `--name` and `--namespace` specified the name and namespace of Alluxio Runtime respectively. All the logs will be packed in a package under execution path.
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: 2020-05-21-meshmark-explained.md

slug: MeshMark explained subtitle: MeshMark explained image: /assets/img/smi-conformance.svg alt: MeshMark explained date: 2020-05-21 12:15:05 +0000 category: spec author: Lee Calcote layout: post caption: title: MeshMark explained subtitle: Through the eyes of a consumer thumbnail: /assets/img/container-crane.svg An introduction to MeshMark might be best explained through a simple story that we can all relate to. As a consumer, when you make a purchase, there are generically two methods by which we determine our happiness about making any given purchase. We ask ourselves: Do I feel that this widget is worth its cost to me (the sales price)? The intrinsic weight that we assign to this feeling of value; to how valuable to consider a given item is based on many factors: As a detractant of the value: cost (dollars, interest on a loan, mental stress of a loan) As an additive of value: feature/function (usefulness to me and relative to how great my need is for such a widget), goodwill (to the brand), and psychology (peace of mind, social status, immediate satisfaction of purchase), Its in this context that we compare how this widget functionally compares to other widgets and how much it costs compared to other widgets (using the factors described in #1). When you consider this and relate it to infrastructure (when you relate it to service meshes), ask yourself, do I feel that this network function is worth its cost to me?. Then, the computation that you do in our heads today is again based on a set of factors: Criticality How important is this function? How much would it cost me to get it elsewhere? Risk Positive: how much am I leaving exposed without this service mesh feature? Negative: how concerned am I that this service mesh feature will fail? MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are paying for in it. The scoring system ranges from 0 to 100. <img class="image-right" src="/assets/img/distributed-performance_green.svg"> Another aspect here is the need for distributed, multi-mesh and workload performance management. Distributed load testing offers insight into system behaviors that arguably more accurately represent real world behaviors of services under load as that load comes from any number of sources. This aim of enhancing the current load generation and analysis techniques to include distributed load testing is hoped to be achieved by the project, by analyzing and working hand ii n hand with Nighthawk, a versatile HTTP load testing tool. {% include related-discussion.html tag="SMP"%}
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.11.0.md

We are delighted to present version 1.11.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. There's been a bunch of great contributions from our community for this release, thanks to everyone! The new Contour Operator provides a method for packaging, deploying, and managing Contour. The operator extends the functionality of the Kubernetes API to create, configure, and manage instances of Contour on behalf of users. It builds upon the basic Kubernetes resource and controller concepts, but includes domain-specific knowledge to automate the entire lifecycle of Contour. Visit the on how to quickly get up and running with the operator. For more information, see the repo. The default global minimum TLS version is moved to 1.2 from 1.1. This forces all HTTPProxies and Ingresses to use at least 1.2. https://github.com/projectcontour/contour/pull/3112 Contour supports Envoy v1.16.2 which resolves various CVEs found in Envoy, please upgrade your clusters! As mentioned in the `v2` XDS resource version has been removed from Contour ahead of its removal from Envoy. Please see the for upgrading your instances of Envoy/Contour. Note: This change applies also to any External Auth servers that may be integrated. If client certificates, represented in Kubernetes secrets, were changes, Contour did not notice that change and blocked a valid cert rotation path for users. Contour v1.11 adds secret references from the configuration file to the list of secrets that will trigger DAG rebuild. Previously only secrets referred by HTTPProxy and Ingress resources were considered. The result was that secrets were not picked up correctly if they were created after the creation of HTTPProxy or Ingress themselves triggered a rebuild. https://github.com/projectcontour/contour/pull/3191 Thanks to @tsaarni for the fix and @Zsolt-LazarZsolt for reporting! Contour annotations starting with `contour.heptio.com` have been removed from documentation for some time. Contour 1.8 marks the official deprecation of these annotations and have been removed in Contour v1.11.0. Please consult the upgrade . Were immensely grateful for all the community contributions that help make Contour even better! For version 1.11, special thanks go out to the following contributors: 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: Gravitee.io (Orchestration & Management / API Gateway)
File: organization-configuration-identityprovider.md

Identity provider is mainly based on OAuth2 / OIDC protocols. This part is providing a way to configure access to the authorization server. Depending on the type of identity provider, some advanced configuration may be mandatory. When a user is logged into Gravitee.io from an external identity provider / social provider, we must retrieve the information of the authenticated user and store them (partially) in the Gravitee.io database. The user profile mapping enabled you to configure the user's properties from Gravitee and the associated value (attribute / claim) from the user_info profile Groups mapping allows you to automatically associate a user to a group according to a given condition (supports EL). Example: ``` {#jsonPath(#profile, '$.identityproviderid') == 'idp5' && #jsonPath(#profile, '$.jobid') != 'API_BREAKER'} ``` Roles mapping allows you to automatically associate role to the user according to a given condition (supports EL). Example: ``` {#jsonPath(#profile, '$.identityproviderid') == 'idp5' && #jsonPath(#profile, '$.jobid') != 'API_BREAKER'} ```
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.7.md

+++ title = "CoreDNS-1.6.7 Release" description = "CoreDNS-1.6.7 Release Notes." tags = ["Release", "1.6.7", "Notes"] release = "1.6.7" date = 2020-01-28T10:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . This is a fairly small release that resolves some nits and it adds mips64le to the set of architectures that we create binaries for. See "Noteworthy Changes" for more detail. Antonio Ojea, Brad P. Crochet, Dominic Yin, DrmagicE, Erfan Besharat, Jonathan Nagy, Kohei Yoshida, Miek Gieben, Yong Tang, Zheng Xie, Zou Nengren. Add mips64le to released architectures (https://github.com/coredns/coredns/pull/3589) Fix HostPortOrFile to support IPv6 addresses with zone (https://github.com/coredns/coredns/pull/3527) plugin/acl: Document metrics in README (https://github.com/coredns/coredns/pull/3605) plugin/cache: Registry cache_miss logic (https://github.com/coredns/coredns/pull/3578) plugin/cache: Update comment to conform to the implementation (https://github.com/coredns/coredns/pull/3573) plugin/{forward, grpc}: Dedup policy implement between grpc and proxy plugin (https://github.com/coredns/coredns/pull/3537) plugin/kubernetes: Bump kubernetes plugin schema version (https://github.com/coredns/coredns/pull/3554) plugin/{kubernetes, etc}: Resolve TXT records via CNAME (https://github.com/coredns/coredns/pull/3557) plugin/logs: Docs: update README and log plugin (https://github.com/coredns/coredns/pull/3602) plugin/sign: Add expiration jitter (https://github.com/coredns/coredns/pull/3588)
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: releasing.md

title: Releasing Go to `createreleasepull_request` workflow under actions. Select run workflow, and use the workflow from your branch. Input release version with the semantic version identifying the release. Click run workflow and review the PR created by github-actions. Once the PR is merged to `main`, tag that commit with release version and push tags to remote repository. ``` git checkout <BRANCH NAME> git pull origin <BRANCH NAME> git tag -a <NEW VERSION> -m '<NEW VERSION>' git push origin <NEW VERSION> ``` Pushing the release tag will trigger GitHub Actions to trigger `release` job. This will build the `ghcr.io/eraser-dev/remover`, `ghcr.io/eraser-dev/eraser-manager`, `ghcr.io/eraser-dev/collector`, and `ghcr.io/eraser-dev/eraser-trivy-scanner` images automatically, then publish the new release tag. GitHub Action will create a new release, review and edit it at https://github.com/eraser-dev/eraser/releases Send an email to the announcing the release, with links to GitHub. Post a message on the with the same information.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: metrics.md

Currently users can leverage controller logs and job events to monitor scheduler. While useful for debugging, none of this options is particularly practical for monitoring kube-batch behaviour over time. There's also requirement like to monitor kube-batch in one view to resolve critical performance issue in time . This document describes metrics we want to add into kube-batch to better monitor performance. In order to support metrics, kube-batch needs to expose a metrics endpoint which can provide golang process metrics like number of goroutines, gc duration, cpu and memory usage, etc as well as kube-batch custom metrics related to time taken by plugins or actions. All the metrics are prefixed with `kubebatch`. This metrics track execution of plugins and actions of kube-batch loop. | Metric name | Metric type | Labels | Description | | -- | -- | | -- | | e2eschedulinglatency | histogram | | E2e scheduling latency in seconds | | pluginlatency | histogram | `plugin`=&lt;pluginname&gt; | Schedule latency for plugin | | actionlatency | histogram | `action`=&lt;actionname&gt; | Schedule latency for action | | tasklatency | histogram | `job`=&lt;jobid&gt; `task`=&lt;task_id&gt; | Schedule latency for each task | This metrics describe internal state of kube-batch. | Metric name | Metric type | Labels | Description | | -- | -- | | -- | | podscheduleerrors | Counter | | The number of kube-batch failed due to an error | | podschedulesuccesses | Counter | | The number of kube-batch success in scheduling a job | | podpreemptionvictims | Counter | | Number of selected preemption victims | | totalpreemptionattempts | Counter | | Total preemption attempts in the cluster till now | | unscheduletaskcount | Counter | `job`=&lt;job_id&gt; | The number of tasks failed to schedule | | unschedulejobcounts | Counter | | The number of job failed to schedule in each iteration | | jobretrycounts | Counter | `job`=&lt;job_id&gt; | The number of retry times of one job | Healthcheck last time of kube-batch activity and timeout
Project: Gloo (Orchestration & Management / API Gateway)
File: service_spec.proto.sk.md

title: "service_spec.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Describes APIs and application-level information for services Gloo routes to. ServiceSpec is contained within the UpstreamSpec for certain types of upstreams, including Kubernetes, Consul, and Static. ServiceSpec configuration is opaque to Gloo and handled by Service Options. ```yaml "rest": .rest.options.gloo.solo.io.ServiceSpec "grpc": .grpc.options.gloo.solo.io.ServiceSpec "grpcJsonTranscoder": .grpc_json.options.gloo.solo.io.GrpcJsonTranscoder "graphql": .graphql.options.gloo.solo.io.ServiceSpec ``` | Field | Type | Description | | -- | - | -- | | `rest` | | Only one of `rest`, `grpc`, `grpcJsonTranscoder`, or `graphql` can be set. | | `grpc` | | Only one of `grpc`, `rest`, `grpcJsonTranscoder`, or `graphql` can be set. | | `grpcJsonTranscoder` | | Only one of `grpcJsonTranscoder`, `rest`, `grpc`, or `graphql` can be set. | | `graphql` | | Only one of `graphql`, `rest`, `grpc`, or `grpcJsonTranscoder` can be set. | <!-- 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: Docker Swarm (Orchestration & Management / Scheduling & Orchestration)
File: CHANGES.md

Documentation updates. Small linter cleanups. Added example in test. Document the usage of Cleanup when re-reading a file (thanks to @lesovsky) for issue #18. Add example directories with example and tests for issues. Fix of checksum problem because of forced tag. No changes to the code. Incorporated PR 162 by by Mohammed902: "Simplify non-Windows build tag". Incorporated PR 9 by mschneider82: "Added seekinfo to Tail". Incorporated PR 7: "Fix deadlock when stopping on non-empty file/buffer", fixes upstream issue 93. Incorporated changes of unmerged upstream PR 149 by mezzi: "added line num to Line struct". Incorporated changes of unmerged upstream PR 128 by jadekler: "Compile-able code in readme". Incorporated changes of unmerged upstream PR 130 by fgeller: "small change to comment wording". Incorporated changes of unmerged upstream PR 133 by sm3142: "removed spurious newlines from log messages". Incorporated changes of unmerged upstream PR 126 by Code-Hex: "Solved the problem for never return the last line if it's not followed by a newline". Incorporated changes of unmerged upstream PR 131 by StoicPerlman: "Remove deprecated os.SEEK consts". The changes bumped the minimal supported Go release to 1.9. migration to go modules. release of master branch of the dormant upstream, because it contains fixes and improvement no present in the tagged release.
Project: WSO2 API Microgateway (Orchestration & Management / API Gateway)
File: feature_pr_template.md

<!-- Short description of the feature you are going to add with this PR. --> <!-- Link github issues that are going to be solved with this PR. Format should be: Fixes #123 --> Fixes # <!-- Brief description of the new feature or bug fix as it will appear in the release notes --> <!-- Link(s) to product documentation that addresses the changes of this PR. If no doc impact, enter N/A plus brief explanation of why theres no doc impact --> No documentation impact. Current documentation covers the changes. Followed ? Yes/No Verified `FindSecurityBugs` report? Yes/No Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? Yes/No <!-- Provide a sample or a link(s) with guide to test this feature. --> <!-- Describe migration steps and platforms on which migration has been tested --> No migration required <!-- Specify the environments you used to test this PR. OS, DB, JDK version, etc... --> Not Tested [ ] Assigned 'Type' label [ ] Assigned the project [ ] Validated respective github issues [ ] Assigned milestone to the github issue(s)
Project: Traefik (Orchestration & Management / API Gateway)
File: etcd.md

title: "Traefik Etcd Documentation" description: "Use Etcd as a provider for configuration discovery in Traefik Proxy. Automate and store your configurations with Etcd. Read the technical documentation." A Story of KV store & Containers {: .subtitle } Store your configuration in etcd and let Traefik do the rest! See the dedicated section in . Required, Default="127.0.0.1:2379" Defines how to access etcd. ```yaml tab="File (YAML)" providers: etcd: endpoints: "127.0.0.1:2379" ``` ```toml tab="File (TOML)" [providers.etcd] endpoints = ["127.0.0.1:2379"] ``` ```bash tab="CLI" --providers.etcd.endpoints=127.0.0.1:2379 ``` Required, Default="traefik" Defines the root key of the configuration. ```yaml tab="File (YAML)" providers: etcd: rootKey: "traefik" ``` ```toml tab="File (TOML)" [providers.etcd] rootKey = "traefik" ``` ```bash tab="CLI" --providers.etcd.rootkey=traefik ``` Optional, Default="" Defines a username with which to connect to etcd. ```yaml tab="File (YAML)" providers: etcd: username: "foo" ``` ```toml tab="File (TOML)" [providers.etcd] username = "foo" ``` ```bash tab="CLI" --providers.etcd.username=foo ``` Optional, Default="" Defines a password with which to connect to etcd. ```yaml tab="File (YAML)" providers: etcd: password: "bar" ``` ```toml tab="File (TOML)" [providers.etcd] password = "bar" ``` ```bash tab="CLI" --providers.etcd.password=foo ``` Optional Defines the TLS configuration used for the secure connection to etcd. Optional `ca` is the path to the certificate authority used for the secure connection to etcd, it defaults to the system bundle. ```yaml tab="File (YAML)" providers: etcd: tls: ca: path/to/ca.crt ``` ```toml tab="File (TOML)" [providers.etcd.tls] ca = "path/to/ca.crt" ``` ```bash tab="CLI" --providers.etcd.tls.ca=path/to/ca.crt ``` Optional `cert` is the path to the public certificate used for the secure connection to etcd. When using this option, setting the `key` option is required. ```yaml tab="File (YAML)" providers: etcd: tls: cert: path/to/foo.cert key: path/to/foo.key ``` ```toml tab="File (TOML)" [providers.etcd.tls] cert = "path/to/foo.cert" key = "path/to/foo.key" ``` ```bash tab="CLI" --providers.etcd.tls.cert=path/to/foo.cert --providers.etcd.tls.key=path/to/foo.key ``` Optional `key` is the path to the private key used for the secure connection to etcd. When using this option, setting the `cert` option is required. ```yaml tab="File (YAML)" providers: etcd: tls: cert: path/to/foo.cert key: path/to/foo.key ``` ```toml tab="File (TOML)" [providers.etcd.tls] cert = "path/to/foo.cert" key = "path/to/foo.key" ``` ```bash tab="CLI" --providers.etcd.tls.cert=path/to/foo.cert --providers.etcd.tls.key=path/to/foo.key ``` Optional, Default=false If `insecureSkipVerify` is `true`, the TLS connection to etcd accepts any certificate presented by the server regardless of the hostnames it covers. ```yaml tab="File (YAML)" providers: etcd: tls: insecureSkipVerify: true ``` ```toml tab="File (TOML)" [providers.etcd.tls] insecureSkipVerify = true ``` ```bash tab="CLI" --providers.etcd.tls.insecureSkipVerify=true ```
Project: Katalyst (Orchestration & Management / Scheduling & Orchestration)
File: roadmap.md

This roadmap defines the core functionalities and features that katalyst plans to deliver in the future, but the detailed timeline-breakdown will be published in the next quarter. <br> <table> <tbody> <tr> <th>Core Functionalities</th> <th align="center">Core Features</th> <th align="right">Milestone breakdown</th> </tr> <tr> <td>Colocation for Pods with all QoS</td> <td> <ul> <li>Improve the isolation mechanism</li> <ul> <li>Intel RDT, iocost, tc, cgroup v2 ...</li> </ul> <li>Improve eviction strategy for more resource dimensions</li> <ul> <li>PSI based eviction, IO bandwidth based eviction ...</li> </ul> <li>Improve resource advertising</li> <ul> <li>numa-aware reclaimed resource ...</li> </ul> <li>Support all QoS classes</li> <li>QoS enhancement</li> <ul> <li>numa binding, numa exclusive policy ...</li> </ul> </ul> </td> <td> <ul> <li>2023/07/31: v1 release</li> </ul> </td> </tr> <tr> <td>Dynamic Resource Management</td> <td> <ul> <li>Implement resource estimation algorithm to enhance accuracy</li> <ul> <li>indicator-based resource estimation ...</li> <li>ml-based resource estimation ...</li> </ul> <li>Design algorithm interface to support more estimation algorithms as plugins</li> </ul> </td> <td> <ul> <li>2023/07/31: v1 release</li> </ul> </td> </tr> <tr> <td>Rescheduling Based on Workload Profiling</td> <td> <ul> <li>Provide real-time metrics via custom-metrics-apiserver</li> <li>Collect and extract workload profile</li> <li>Implement rescheduling to balance the resource usage across the cluster</li> </ul> </td> <td>/</td> </tr> <tr> <td>Topology Aware Resource Scheduling and Allocation</td> <td> <ul> <li>Support all kinds of heterogeneous devices</li> <li>Support more topology aware devices(e.g. nic, disk etc)</li> <li>Improve device utilization with virtualization mechanism</li> </ul> </td> <td>/</td> </tr> <tr> <td>Elastic Resource Management</td> <td> <ul> <li>Optimize HPA and VPA to support elastic resource management</li> </ul> </td> <td>/</td> </tr> </tbody> </table>
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_userid.md

mod_userid generates user id for client identification. conf/moduserid/moduserid.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Debug flag of module | ```ini [Basic] DataPath = moduserid/useridrule.data [Log] OpenDebug = true ``` conf/moduserid/useridrule.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}[] | Object<br>A rule | | Config{v} | | Config{v}[].Params.Name | String<br>The cookie name | | Config{v}[].Params.Domain | String<br>The cookie domain | | Config{v}[].Params.Path | String<br>The cookie path | | Config{v}[].Params.MaxAge | Integer<br>The cookie max age | ```json { "Version": "2019-12-10184356", "Config": { "example_product": [ { "Cond": "reqpathprefix_in(\"/abc\", true)", "Params": { "Name": "bfeuseridabc", "Domain": "", "Path": "/abc", "MaxAge": 3153600 }, "Generator": "default" }, { "Cond": "default_t()", "Params": { "Name": "bfe_userid", "Domain": "", "Path": "/", "MaxAge": 3153600 } } ] } } ```