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

The integration between Rancher and Capsule, aims to provide a multi-tenant Kubernetes service to users, enabling: a self-service approach access to cluster-wide resources to end-users. Tenant users will have the ability to access Kubernetes resources through: Rancher UI Rancher Shell Kubernetes CLI On the other side, administrators need to manage the Kubernetes clusters through Rancher. Rancher provides a feature called Projects to segregate resources inside a common domain. At the same time Projects doesn't provide way to segregate Kubernetes cluster-scope resources. Capsule as a project born for creating a framework for multi-tenant platforms, integrates with Rancher Projects enhancing the experience with Tenants. Capsule allows tenants isolation and resources control in a declarative way, while enabling a self-service experience to tenants. With Capsule Proxy users can also access cluster-wide resources, as configured by administrators at `Tenant` custom resource-level. You can read in detail how the integration works and how to configure it, in the following guides. .
Project: Kuma (Orchestration & Management / Service Mesh)
File: 017-policy-array-merging.md

Status: accepted support merging of multiple configuration. While merging regular fields is pretty straightforward, it is quite difficult to pick a strategy for merging list. Our current strategy is to replace list from the most specific policy. For example ``` type: Policy targetRef: kind: Mesh defaults: elements: a ``` and ``` type: Policy targetRef: kind: MeshService name: backend defaults: elements: b ``` would result in ``` defaults: elements: b ``` But for some cases we would like to append list and end up with ``` defaults: elements: a b ``` Example use cases are: Composing ProxyTemplate modifications. Composing policies in Kong Mesh's OPA Policy Potentially composing backends in stuff like MeshTrafficLog Name convention Field annotation Merge keyword We could have a name convention that indicates that given array is appendable not replaceable when we merge. ``` defaults: appendElements: a ``` So every time there is the field with value array that starts with `append` we append. Other potential prefixes: composed merged combined joined To implement this, we would need to replace with our reflection-based solution. We could also express both strategies ```yaml default: elements: [] appendElements: [] ``` Explicit for users Replacing jsonpatch will be more efficient, because we don't need to marshal to json just for the sake of merging Expressing both strategies Longer field names Reserving the prefix as a field name (although it's very unlikely to see this as a prefix of any field) We need to roll out custom implementation of merging and maintain it. When building the policy model in Go, we could annotate the array ``` type Policy { Elements []string `json:"elements", kumapolicy:"appendable"` } ``` or use `omitempty` for that. If it's present, the array is appendable. ``` type Policy { Elements []string `json:"elements,omitempty"` } ``` The rest is the same with previous solution, we need to utilize this annotation when we travel the fields with reflection. Cleaner API names. Replacing jsonpatch will be more efficient. Users need to read the policy spec and remember it to understand that the elements are appended, not replaced. This might be surprising for them. We need to roll out custom implementation of merging. We could introduce additional keyword, so instead of `default` we use `merge` which switches the merging algo to append lists ``` merge: elements: a ``` Explicit and easy to understand We cannot control merging on a single list. It's all append or all replace for the whole policy. Additional keyword, which may confuse service owners. Which one they should use by default? `defaults` or `merge`? Chosen option: "Name convention", because it follows the Principle Of The Least Surprise. Explicit prefix has a higher chance of avoiding bug when trying to compose policies.
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: README.md

The end to end testing includes: deployments are downsync propegated to the WECs Update of the workload object on WDS should update the object on the WECs. Increase the number of replicas from 1 to 2, verify they are updated on the WECs. Changing the bindingpolicy objectSelector to no longer match should delete the object from the WECs Changing the bindingpolicy objectSelector to match should create the object on the WECs Delete of an overlapping bindingpolicy object should not delete objects on the WECs Delete of the workload object on WDS deletes the relevant objects on the WECs Delete of a bindingpolicy deletes the relevant objects on the WECs Downsync objects that fully match on object and cluster selector Handles OR of cluster and object selectors Downsync based on object labels and object name Singleton status update Object cleaning for services Resiliency testing - killing kubestellar manager on the WDS Resiliency testing - killing kubeflex Resiliency testing - killing both kubestellar and kubeflex To install Ginkgo, follow the instructions in . To execute these tests, issue the following command. This will make a local image and run the end to end tests. Omit the `--no-color` if you want pretty terminal output; omit the `KFLEXDISABLECHATTY=true` to get progress logging from kubeflex. ```shell KFLEXDISABLECHATTY=true ginkgo --vv --trace --no-color ``` To test the latest release image, pass `--released` to the test. For example: ```shell KFLEXDISABLECHATTY=true ginkgo --vv --trace --no-color -- -released ``` To test a specific test use ginkgo's `--focus` parameter. For example: ```shell KFLEXDISABLECHATTY=true ginkgo --vv --trace --no-color --focus "survives ITS vcluster coming down" ``` To skip the cleanup and setup phase, pass `-skip-setup` to the test. For example: ```shell KFLEXDISABLECHATTY=true ginkgo --vv --trace --no-color -- -skip-setup ```
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: issue_guidance.md

This document details how Service Fabric handles issues reported through GitHub. Note, for support, guidance on opening issues, and general questions related to using Service Fabric, take a look at the documentation in the . Issues are triaged using GitHub labels, the following labels are used to indicate the status of the issue. Most labels are used according the GitHub standards, these labels indicate the type of issue. | Label | Description | | - | | | investigating | The issue isn't clear, further investigation is needed to determine if this a bug or something else | | bug | The issue is related to a code or configuration defect in Service Fabric | | enhancement | The issue is a request to improve a certain feature of Service Fabric | | question | The issue is related to a clarification on how Service Fabric works | Area labels and triage labels are used to identify the related involved components of Service Fabric. | Label | Description | | | - | | needs triage | The involved component isn't clear, further investigation is needed | | area/* | Area labels indicate the specific component that is involved in the issue | Issues are handled according to the set of labels applied to them. As issues progress from being identified, and investigated, to being actively worked on, the set of labels will changes. Once confirmed, issues will have an area label and a `bug` or `enhancement` label. Issues should not be assigned until an active developer is working on coding changes, or an owner has been identified that will work to resolve the issue in reasonable time. The assigned owner should also change as the area changes, to make sure issues end up routed correctly. Note, If you are experiencing a Service Fabric issue and require immediate support, please reach out to Azure Customer Support through the web portal. GitHub issues are not meant to replace Azure Customer Support. The Service Fabric team tries to respond quickly to GitHub issues. We also expect individuals who report issues to respond when additional information is required. For minor questions and issues, it's best to reach a Service Fabric community member through or For issues that are reported through GitHub, we try to adhere to the following time bounds: Initial acknowledgement of issue in less than 48hrs Stale or out of date issues closed after 1 week
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_cluster.md

title: "glooctl cluster" weight: 5 Cluster commands Commands related to managing multiple clusters ``` glooctl cluster [flags] ``` ``` -h, --help help for cluster ``` ``` -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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - CLI for Gloo - Deregister a cluster to the Gloo Federation control plane - List clusters registered to the Gloo Federation control plane - Register a cluster to the Gloo Federation control plane
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: udf-manage.md

The resource management and file management functions are similar. The difference is that the resource management is the UDF upload function, and the file management uploads the user programs, scripts and configuration files. It mainly includes the following operations: rename, download, delete, etc. Upload UDF resources: Same as uploading files. Click `Create UDF Function`, enter the UDF function parameters, select the UDF resource, and click `Submit` to create the UDF function. Currently only temporary UDF functions for HIVE are supported. UDF function name: Enter the name of the UDF function. Package name Class name: Enter the full path of the UDF function. UDF resource: Set the resource file corresponding to the created UDF function. Users can customize the desired UDF function according to actual production requirements. Here's a function that appends "HelloWorld" to the end of any string. As shown below: Before configuring UDF functions, you need to upload the required function jar package through resource management. Then enter the function management and configure the relevant information. As shown below: In the process of using UDF functions, users only need to pay attention to the specific function writing, and upload the configuration through the resource center. The system will automatically configure the create function statement, refer to the following: Enter the workflow to define an SQL node, the data source type is HIVE, and the data source instance type is HIVE/IMPALA. SQL statement: `select HwUdf("abc");` This function is used in the same way as the built-in functions, and can be accessed directly using the function name. UDF function: Select the one configured for the resource center.
Project: Traefik (Orchestration & Management / API Gateway)
File: README.md

Access to Traefik Web UI, ex: http://localhost:8080 Traefik Web UI provide 2 types of information: Providers with their backends and frontends information. Health of the web server. Use the make file : ```shell make build-image # Generate Docker image. make clean-webui generate-webui # Generate static contents in `webui/static/` folder. ``` prerequisite: Go to the `webui/` directory To install dependencies, execute the following commands: `yarn install` Build static Web UI, execute the following command: `yarn build` Static contents are built in the `webui/static/` directory Do not manually change the files in the `webui/static/` directory The build allows to: optimize all JavaScript optimize all CSS add vendor prefixes to CSS (cross-browser support) add a hash in the file names to prevent browser cache problems optimize all images at build time bundle JavaScript in one file Do not manually change the files in the `webui/static/` directory Go to the `webui/` directory Edit files in `webui/src/` Run in development mode : `yarn dev`
Project: Contour (Orchestration & Management / Service Proxy)
File: deprecation-policy.md

title: Contour Deprecation Policy layout: page Contour publishes a few APIs, the most notable being the `projectcontour.io` api group of Kubernetes objects and their associated helper code, the command line for `contour`, and the Contour configuration file. Each of these have deprecation policies, with all of them being based on the . Our Kubernetes CRDs use the Kubernetes API deprecation conventions, including a similar deprecation timeline. There are three levels of stability, Alpha, Beta and GA (in increasing order). We may skip the Beta level when we are reasonably confident the schema is good. We use similar rules as Kubernetes: For Beta and GA versions, API elements may only be removed by incrementing the version of the API group. For Alpha versions, rules on behavior changes and API field removal are more lenient, a version bump will not always be required. An API version in a given track may not be deprecated until a new API version at least as stable is released. | Sample Version Tag | State | Deprecation timeframe | Notes | | | -- | | - | | v1alpha1 | Alpha | Any time | Behavior can change any time, Fields can be removed at any time | | v1beta1 | Beta | 1 release | Behavior can change any time, fields won't be removed without a version bump (ie `v1beta1` to `v1beta2`) | | v1 | GA | 1 year | No fields will be removed, no behavior will substantially change. Fields can be added. | The `projectcontour.io` CRDs contain some helper code, for accessing various parts of the Go structs inside. The API guarantees apply here as well, in the following way: | Sample Version Tag | State | Change/Deprecation timeframe | Notes | | | -- | | - | | v1alpha1 | Alpha | Any time | Function and method signatures can change any time. Implementation may change any time. | | v1beta1 | Beta | 1 release | Function and method signatures won't change without a version bump. Implementation may change any time. | | v1 | GA | 1 year | Function and method signatures won't change without a version bump. Implementation may change any time, but behavior changes must be restricted to minor ones (that is, you can change how a return value is made, but not what it means)| Because removing command line arguments is a breaking operation (that is, the program won't start without them), Contour is committed to a gradual transition for changes here. We try to use the following cycle for arguments: Argument is announced deprecated, with a timeline for removal. This timeframe must never be shorter than 3 releases, but may be longer if required. At the same time, Argument has a warning added, saying that it's deprecated. We wait the timeline period The argument is removed. We use the following cycle for config file settings: Setting is announced deprecated, with a plan for how the functionality will be moved or removed, and a timeline. Warning log added for deprecated setting. We wait the timeline period The setting is moved or removed.
Project: Gloo (Orchestration & Management / API Gateway)
File: snap.proto.sk.md

title: "snap.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> <!-- 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: Kusk Gateway (Orchestration & Management / API Gateway)
File: feature_request.md

name: Feature request about: Suggest an idea or new feature for Kusk Gateway title: '' labels: kind/feature assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context about the feature request here.
Project: Gloo (Orchestration & Management / API Gateway)
File: resource_name.proto.sk.md

title: "resource_name.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> xDS resource name. This has a canonical xdstp:// URI representation: xdstp://{authority}/{typeurl}/{id}?{contextparams} where context_params take the form of URI query parameters. A xDS resource name fully identifies a network resource for transport purposes. xDS resource names in this form appear only in discovery request/response messages used with the xDS transport. ```yaml "id": string "authority": string "resourceType": string "context": .xds.core.v3.ContextParams ``` | Field | Type | Description | | -- | - | -- | | `id` | `string` | Opaque identifier for the resource. Any '/' will not be escaped during URI encoding and will form part of the URI path. | | `authority` | `string` | Logical authority for resource (not necessarily transport network address). Authorities are opaque in the xDS API, data-plane load balancers will map them to concrete network transports such as an xDS management server. | | `resourceType` | `string` | Fully qualified resource type (as in type URL without types.googleapis.com/ prefix). | | `context` | | Additional parameters that can be used to select resource variants. | <!-- 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: Dubbo (Orchestration & Management / Remote Procedure Call)
File: PULL_REQUEST_TEMPLATE.md

<!-- Follow this checklist to help us incorporate your contribution quickly and easily: --> field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue. [ ] Each commit in the pull request should have a meaningful subject line and body. [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. [ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7 project. project if you are requesting to add a feature. [ ] GitHub Actions works fine on your own branch. .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.14.1.md

We are delighted to present version 1.14.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Upgrades the default Envoy version to 1.17.2 for security and bug fixes. See the for more details. CVE-2021-28682 (CVSS score 7.5, High): Envoy through 1.17.1, 1.16.2, 1.15.3, and 1.14.6 contains a remotely exploitable integer overflow via a very large grpc-timeout value causes undefined behavior. CVE-2021-28683 (CVSS score 7.5, High): Envoy through 1.17.1 and 1.16.2 contains a remotely exploitable crash in TLS when an unknown TLS alert code is received. CVE-2021-29258 (CVSS score 7.5, High): Envoy through 1.17.1, 1.16.2, 1.15.3, and 1.14.6 contains a remotely exploitable crash in Envoy's HTTP2 Metadata, when an empty METADATA map is sent.
Project: Gloo (Orchestration & Management / API Gateway)
File: static.proto.sk.md

title: "static.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Static upstreams are used to route request to services listening at fixed IP/Host & Port pairs. Static upstreams can be used to proxy any kind of service, and therefore contain a ServiceSpec for additional service-specific configuration. Unlike upstreams created by service discovery, Static Upstreams must be created manually by users ```yaml "hosts": []static.options.gloo.solo.io.Host "useTls": .google.protobuf.BoolValue "serviceSpec": .options.gloo.solo.io.ServiceSpec "autoSniRewrite": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `hosts` | | A list of addresses and ports at least one must be specified. | | `useTls` | | Attempt to use outbound TLS If not explicitly set, Gloo will automatically set this to true for port 443. | | `serviceSpec` | | An optional Service Spec describing the service listening at this address. | | `autoSniRewrite` | | When set, automatically set the sni address to use to the addr field. If both this and host.sniaddr are set, host.sniaddr has priority. defaults to "true". | Represents a single instance of an upstream ```yaml "addr": string "port": int "sniAddr": string "loadBalancingWeight": .google.protobuf.UInt32Value "healthCheckConfig": .static.options.gloo.solo.io.Host.HealthCheckConfig ``` | Field | Type | Description | | -- | - | -- | | `addr` | `string` | Address (hostname or IP). | | `port` | `int` | Port the instance is listening on. | | `sniAddr` | `string` | Address to use for SNI if using ssl. | | `loadBalancingWeight` | | The optional load balancing weight of the upstream host; at least 1. Envoy uses the load balancing weight in some of the built in load balancers. The load balancing weight for an endpoint is divided by the sum of the weights of all endpoints in the endpoint's locality to produce a percentage of traffic for the endpoint. This percentage is then further weighted by the endpoint's locality's load balancing weight from LocalityLbEndpoints. If unspecified, each host is presumed to have equal weight in a locality. | | `healthCheckConfig` | | (Enterprise Only): Host specific health checking configuration. | ```yaml "path": string "method": string ``` | Field | Type | Description | | -- | - | -- | | `path` | `string` | (Enterprise Only): Path to use when health checking this specific host. | | `method` | `string` | (Enterprise Only): Method to use when health checking this specific host. | <!-- 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 -->