cwielenb/CNCF-Dataset huggingface dataset:
Project: Envoy (Orchestration & Management / Service Proxy)
File: other.md

name: Other about: Questions, design proposals, tech debt, etc. title: '' labels: triage assignees: '' If you are reporting any crash or any potential security issue, do not open an issue in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Title: One line description Description: Describe the issue. [optional Relevant Links:] Any extra documentation required to understand the issue.
Project: Clusterpedia (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: Apache bRPC (Orchestration & Management / Remote Procedure Call)
File: avalanche.md

"Avalanche" refers to the phenomenon that the vast majority of requests are timed out when accessing a service cluster and can not be recovered when the traffic decreases. Next we explain the source of this phenomenon. When the number of request exceeds the maximum qps of service, the service will not work properly; when the traffic is back to normal(less than the service processing capacity), the backlog requests will be processed. Although most of them may be timed out due to not being processed timely, the service itself will generally return to normal. This is just like a pool has a water inlet and a water outlet, if the amount of water in is greater than that of water out, the pool will eventually be full and more water will overflow. However, if the amount of water in is less than that of water out, the pool will be eventually empty after a period of time.
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: yaml_docs.md

Generating yaml files from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } err := doc.GenYamlTree(cmd, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a Yaml document `/tmp/test.yaml` This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "io/ioutil" "log" "os" "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "github.com/spf13/cobra/doc" ) func main() { kubectl := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, ioutil.Discard, ioutil.Discard) err := doc.GenYamlTree(kubectl, "./") if err != nil { log.Fatal(err) } } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenYaml` instead of `GenYamlTree` ```go out := new(bytes.Buffer) doc.GenYaml(cmd, out) ``` This will write the yaml doc for ONLY "cmd" into the out, buffer. Both `GenYaml` and `GenYamlTree` have alternate versions with callbacks to get some control of the output: ```go func GenYamlTreeCustom(cmd *Command, dir string, filePrepender, linkHandler func(string) string) error { //... } ``` ```go func GenYamlCustom(cmd Command, out bytes.Buffer, linkHandler func(string) string) error { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered Yaml file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered internal links to the commands, given a filename: ```go linkHandler := func(name string) string { base := strings.TrimSuffix(name, path.Ext(name)) return "/commands/" + strings.ToLower(base) + "/" } ```
Project: CloudWeGo (Orchestration & Management / Remote Procedure Call)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Kitex version: Please provide the version of Kitex you are using. Environment: The output of `go env`. Additional context Add any other context about the problem here.
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: release.md

The Capsule release process is constrained to GitHub Releases, following the git tag semantic versioning. Capsule is taking advantage of the , although with some rules about the patch, the minor and the major bump versions. `patch` (e.g.: 0.1.0 to 0.1.1): a patch bumping occurs when some bugs are fixed, and no Kubernetes CRDs API changes are introduced. The patch can contain also new features not yet promoted to a specific Kubernetes CRDs API type. A patch may be used also to address CVE patches. `minor` (e.g.: 0.1.0 to 0.2.0): a minor bumping occurs when a new CRDs API object is introduced, or rather, when some CRDs schemes are updated. The minor bump is used to inform the Capsule adopters to manually update the Capsule CRDs, since Helm, the suggested tool for the release lifecycle management, is not able to automatically update the objects. Upon every minor release, on the GitHub Release page, a list of API updates is described, and a link to the is provided. `major` (e.g.: 0.1.0 to 1.0.0): a major bump occurs when a breaking change, such as backward incompatible changes is introduced. All the Capsule container images are publicly hosted on . The Capsule container image is built upon a git tag (issued thanks to the GitHub Release feature) starting with the prefix `v` (e.g.: `v1.0.1`). This will trigger a GitHub Action which builds a multi-arch container image, then pushes it to the container registry. The `latest` tag is not available to avoid moving git commit SHA reference. The suggested installation tool is , and the Capsule chart is hosted in the . For each Helm Chart release, a tit tag with the prefix `helm-v` will be issued to help developers to address the corresponding commit. The built Helm Charts are then automatically pushed upon tag release to the .
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: Components.md

+ + OpenFunction provides an event handling framework called OpenFunction events that complements the event-driven capabilities of OpenFunction as a FaaS framework. You can refer to for more information. The core capability of OpenFunction is to enable users to develop, run and manage applications as executable function code. OpenFunction implements the following : Function, defines a function. Builder, defines a function builder. Serving, defines a function workload. Domain, defines a unified entry point for sync functions. The goal of `Function` is to control the lifecycle management from user code to the final application that can respond to events through a single profile. `Function` manages and coordinates `Builder` and `Serving` resources to handle the details of the process. The goal of `Builder` is to compile the user's function source code into an application image. It will fetch the code from the code repository, build the application image locally and publish it to the container image repository. Currently, OpenFunction Builder uses to build container images. is an extensible framework for building container images on Kubernetes. Cloud Native Buildpacks is an OCI standard image building framework that transforms your application source code into container images without a Dockerfile. OpenFunction Builder controls the build process of application images by , including fetching code, building and publishing images via Cloud Native Buildpacks. The goal of `Serving` is to run functions in a highly elastic manner (dynamically scale 0 <-> N). Currently, OpenFunction supports two serving runtimes, and . At least one of these runtimes is required. Knative Serving builds on Kubernetes to support deploying and serving serverless applications and functions. Knative Serving is easy to get started with and scales to support advanced scenarios. OpenFuncAsync is an event-driven Serving runtime. It is implemented based on KEDA + Dapr. You can refer to and use `--with-openFuncAsync` to install OpenFuncAsync runtime. The OpenFuncAsync functions can be triggered by various event types, such as MQ, cronjob, DB events, etc. In a Kubernetes cluster, OpenFuncAsync functions run in the form of deployments or jobs. `Domain` defines a unified entry point for sync functions using ingress, user can use ``` http://<domain-name>.<domain-namespace>/<function-namespace>/<function-name> ``` to access a function. Only one `Domain` can be defined in a cluster. A `Domain` requires a `Ingress Controller`. By default, we use `nginx-ingress`. You can refer to and use `--with-ingress` to install it, or install it manually. If the `nginx-ingress` does not use the default namespace and name, please modify the `config/domain/default-domain.yaml`, and run ``` make manifests ``` to update the `config/bundle.yaml`, and use this file to deploy `openFunction`.
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: TODO.md

```sh npm run serve ``` Fire Edge server and client yarn (this command import the dependecies). yarn build (execute the javascript build "bundle") yarn start (start the server in port 2616) yarn dev (run server in mode development) Api REST Interface. Usually Returns OpenNebula resource info. Login returns a JSON Web Token (`JWT`). Login: POST: `http://localhost:2616/api/auth` with params: `user` and `pass`. Other: check file `src/config/command-params.js`. if requires it to be in a specific zone you must put it at the end but before the query ?zone=ZONEID (replace ZONEID for the zone id) zeroMQ Websocket connection call to: `ws://127.0.0.1:2616/zeromq/?token=JWT` [nodemon] Internal watch failed: watch ENOSPC for this error run `sudo sysctl fs.inotify.maxuserwatches=582222 && sudo sysctl -p` Starting inspector on 127.0.0.1:9229 failed: address already in use for this error run `killall -9 node` and start app again ...
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: cgroups-blkio.md

title: Apache Mesos - Cgroups 'blkio' Subsystem Support in Mesos Containerizer layout: documentation The `cgroups/blkio` isolator provides block I/O performance isolation for containers through . To enable the isolator, append `cgroups/blkio` to the `--isolation` flag before starting the agent. The blkio subsystem enables I/O statistics collection and allows operators to apply I/O control policies for block devices. The isolator places the processes of a Mesos container into a separate blkio cgroup hierarchy. At the moment, it only supports reporting containers' I/O statistics on block devices to the agent. A sample statistics would be something like: ``` [{ "executor_id": "executor", "executor_name": "name", "framework_id": "framework", "source": "source", "statistics": { "blkio": { "cfq": [ { "io_merged": [ { "op": "TOTAL", "value": 0 } ], "io_queued": [ { "op": "TOTAL", "value": 0 } ], "ioservicebytes": [ { "op": "TOTAL", "value": 0 } ], "ioservicetime": [ { "op": "TOTAL", "value": 0 } ], "io_serviced": [ { "op": "TOTAL", "value": 0 } ], "iowaittime": [ { "op": "TOTAL", "value": 0 } ] } ], "cfq_recursive": [ { "io_merged": [ { "op": "TOTAL", "value": 0 } ], "io_queued": [ { "op": "TOTAL", "value": 0 } ], "ioservicebytes": [ { "op": "TOTAL", "value": 0 } ], "ioservicetime": [ { "op": "TOTAL", "value": 0 } ], "io_serviced": [ { "op": "TOTAL", "value": 0 } ], "iowaittime": [ { "op": "TOTAL", "value": 0 } ] } ], "throttling": [ { "device": { "major": 8, "minor": 0 }, "ioservicebytes": [ { "op": "READ", "value": 0 }, { "op": "WRITE", "value": 4096 }, { "op": "SYNC", "value": 0 }, { "op": "ASYNC", "value": 4096 }, { "op": "TOTAL", "value": 4096 } ], "io_serviced": [ { "op": "READ", "value": 0 }, { "op": "WRITE", "value": 1 }, { "op": "SYNC", "value": 0 }, { "op": "ASYNC", "value": 1 }, { "op": "TOTAL", "value": 1 } ] }, { "ioservicebytes": [ { "op": "TOTAL", "value": 4096 } ], "io_serviced": [ { "op": "TOTAL", "value": 1 } ] } ] }, "cpus_limit": 1.1, "memlimitbytes": 167772160, "timestamp": 1500335339.30187 } }] ``` For more details about the blkio subsystem, please refer to the Linux kernel documentation.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_get_virtualservice_route.md

title: "glooctl get virtualservice route" weight: 5 get a list of routes for a given virtual service usage: glooctl get virtualservice route [virtual service name] ``` glooctl get virtualservice route [flags] ``` ``` -h, --help help for route ``` ``` -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 name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - read a virtualservice or list virtualservices in a namespace
Project: BFE (Orchestration & Management / Service Proxy)
File: spdy_state.md

The endpoint `/monitor/spdy_state` exposes metrics about SPDY. | Metric | Description | | | - | | SPDYERRBAD_REQUEST | Counter for bad request | | SPDYERRFLOW_CONTROL | Counter for flow control | | SPDYERRGOTRESET | Counter for gettting RSTSTREAM | | SPDYERRINVALIDDATASTREAM | Counter for invalid data stream | | SPDYERRINVALIDSYNSTREAM | Counter for invalid SYN stream | | SPDYERRMAXSTREAMPER_CONN | Counter for reaching advertised concurrent stream limit | | SPDYERRNEW_FRAMER | Counter for creating frame failed | | SPDYPANICCONN | Counter for connection panic | | SPDYPANICSTREAM | Counter for stream panic | | SPDYREQHEADERCOMPRESSSIZE | Size of request header before compress | | SPDYREQHEADERORIGINALSIZE | Size of request header after compress | | SPDYRESHEADERCOMPRESSSIZE | Size of response header before compress | | SPDYRESHEADERORIGINALSIZE | Size of response header after compress | | SPDYTIMEOUTCONN | Timeout of SPDY connection | | SPDYTIMEOUTREAD_STREAM | Timeout waiting for reading stream | | SPDYTIMEOUTWRITE_STREAM | Timeout waiting for writing stream | | SPDYUNKNOWNFRAME | Counter for unknown frame |
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: logging.md

This document provides an overview of the recommended way to develop and implement logging for components of Koordinator. The following conventions for the klog levels to use. is globally preferred to for better runtime control. klog.Errorf() - Always an error klog.Warningf() - Something unexpected, but probably not an error klog.Infof() has multiple levels: klog.V(0) - Generally useful for this to ALWAYS be visible to an operator Programmer errors Logging extra info about a panic CLI argument handling klog.V(1) - A reasonable default log level if you don't want verbosity. Information about config (listening on X, watching Y) Errors that repeat frequently that relate to conditions that can be corrected (pod detected as unhealthy) klog.V(2) - Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems. Logging HTTP requests and their exit code System state changing (killing pod) Controller state change events (starting pods) Scheduler log messages klog.V(3) - Extended information about changes More info about system state changes klog.V(4) - Debug level verbosity Logging in particularly thorny parts of code where you may want to come back later and check it klog.V(5) - Trace level verbosity Context to understand the steps leading up to errors and warnings More information for troubleshooting reported issues klog.InfoS() - structured logs to the INFO log As per the comments, the practical default level is V(2). Developers and QE environments may wish to run at V(3) or V(4) . If you wish to change the log level, you can pass in `-v=X` where X is the desired maximum level to log. An example logging message is ``` I0528 19:15:22.737538 47512 logtest.go:52] Pod kube-system/kube-dns status was updated to ready ``` Explanation of header: ``` Lmmdd hh:mm:ss.uuuuuu threadid file:line] msg... where the fields are defined as follows: L A single character, representing the log level (eg 'I' for INFO) mm The month (zero padded; ie May is '05') dd The day (zero padded) hh:mm:ss.uuuuuu Time in hours, minutes and fractional seconds threadid The space-padded thread ID as returned by GetTID() file The file name line The line number msg The user-supplied message ``` See more in
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: mesos-containerizer.md

title: Apache Mesos - Mesos Containerizer layout: documentation The Mesos Containerizer provides lightweight containerization and resource isolation of executors using Linux-specific functionality such as control cgroups and namespaces. It is composable so operators can selectively enable different . It also provides basic support for POSIX systems (e.g., OSX) but without any actual isolation, only resource usage reporting. Isolators are components that each define an aspect of how a tasks execution environment (or container) is constructed. Isolators can control how containers are isolated from each other, how task resource limits are enforced, how networking is configured, how security policies are applied. Since the isolator interface is , operators can write modules that implement custom isolators. Mesos supports the following built-in isolators. appc/runtime cgroups/cpuset cgroups/hugetlb cgroups/mem cgroups/net\_prio cgroups/perf\_event cgroups/pids filesystem/windows posix/cpu posix/mem volume/image To prevent systemd from manipulating cgroups managed by the agent, it's recommended to add 'Delegate' under 'Service' in the service unit file of Mesos agent, for example: ``` [Service] Delegate=true ```
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-0.10.md

The newly introduced Resource Interpreter Webhook framework allows users to implement their own CRD plugins that will be consulted at all parts of propagation process. With this feature, CRDs and CRs will be propagated just like Kubernetes native resources, which means all scheduling primitives also support custom resources. An example as well as some helpful utilities are provided to help users better understand how this framework works. Refer to for more details. Introduced `dynamicWeight` primitive to `PropagationPolicy` and `ClusterPropagationPolicy`. With this feature, replicas could be divided by a dynamic weight list, and the weight of each cluster will be calculated based on the available replicas during scheduling. This feature can balance the cluster's utilization significantly. Introduced `Job` schedule (divide) support. A `Job` that desires many replicas now could be divided into many clusters just like `Deployment`. This feature makes it possible to run huge Jobs across small clusters. After workloads (e.g. Deployments) are propagated to member clusters, users may also want to get the overall workload status across many clusters, especially the status of each `pod`. In this release, a `get` subcommand was introduced to the `kubectl-karmada`. With this command, user are now able to get all kinds of resources deployed in member clusters from the Karmada control plane. For example (get `deployment` and `pods` across clusters): ```shell $ kubectl karmada get deployment NAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTION nginx member2 1/1 1 1 19m Y nginx member1 1/1 1 1 19m Y $ kubectl karmada get pods NAME CLUSTER READY STATUS RESTARTS AGE nginx-6799fc88d8-vzdvt member1 1/1 Running 0 31m nginx-6799fc88d8-l55kk member2 1/1 Running 0 31m ``` karmada-scheduler-estimator: The number of pods becomes an important reference when calculating available replicas for the cluster. The labels (`resourcebinding.karmada.io/namespace`, `resourcebinding.karmada.io/name`, `clusterresourcebinding.karmada.io/name`) which were previously added on the Work object now have been moved to annotations. Bugfix: Fixed the impact of cluster unjoining on resource status aggregation. Instrumentation: Introduced events (`SyncFailed` and `SyncSucceed`) to the Work object. Instrumentation: Introduced condition (`Scheduled`) to the `ResourceBinding` and `ClusterResourceBinding`. Instrumentation: Introduced events (`CreateExecutionNamespaceFailed` and `RemoveExecutionNamespaceFailed`) to the Cluster object. Instrumentation: Introduced several metrics (`workqueueaddstotal`, `workqueuedepth`, `workqueuelongestrunningprocessor_seconds`, `workqueuequeuedurationsecondsbucket`) for `karmada-agent` and `karmada-controller-manager`. Instrumentation: Introduced condition (`FullyApplied`) to the `ResourceBinding` and `ClusterResourceBinding`. karmada-scheduler: Introduced feature gates. karmada-controller-manager: Deleted resources from member clusters that use "Background" as the default delete option.