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

Refer to to install volcano. Deploy extender into kubernetes cluster. Extender needs to expose domain name or IP address and verbs that can be provided. ```shell script kubectl edit cm -n volcano-system volcano-scheduler-configmap ``` Users can view the meaning of the parameters through the ```yaml kind: ConfigMap apiVersion: v1 metadata: name: volcano-scheduler-configmap namespace: volcano-system data: volcano-scheduler.conf: | actions: "reclaim, allocate, backfill, preempt" tiers: plugins: name: priority name: gang name: conformance plugins: name: drf name: predicates name: extender arguments: extender.urlPrefix: http://127.0.0.1:8713 extender.httpTimeout: 100ms extender.onSessionOpenVerb: onSessionOpen extender.onSessionCloseVerb: onSessionClose extender.predicateVerb: predicate extender.prioritizeVerb: prioritize extender.preemptableVerb: preemptable extender.reclaimableVerb: reclaimable extender.queueOverusedVerb: queueOverused extender.jobEnqueueableVerb: jobEnqueueable extender.ignorable: true ``` The user can see in the log something like : 'Initialize extender plugin with configuration : {your configuration}'
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: sso.md

description: Configure single sign-on (SSO) for your Prefect Cloud users. tags: UI dashboard Prefect Cloud enterprise teams workspaces organizations single sign-on SSO authentication search: boost: 2 Prefect Cloud's offer single sign-on (SSO) integration with your teams identity provider. SSO integration can be set up with any identity provider that supports: OIDC SAML 2.0 When using SSO, Prefect Cloud won't store passwords for any accounts managed by your identity provider. Members of your Prefect Cloud account will instead log in and authenticate using your identity provider. Once your SSO integration has been set up, non-admins will be required to authenticate through the SSO provider when accessing account resources. See the to learn more about options for supporting more users and workspaces, service accounts, and SSO. Within your account, select the SSO page to enable SSO for users. If you haven't enabled SSO for a domain yet, enter the email domains for which you want to configure SSO in Prefect Cloud and save it. Under Enabled Domains, select the domains from the Domains list, then select Generate Link. This step creates a link you can use to configure SSO with your identity provider. Using the provided link navigate to the Identity Provider Configuration dashboard and select your identity provider to continue configuration. If your provider isn't listed, you can continue with the `SAML` or `Open ID Connect` choices instead. Once you complete SSO configuration your users will be required to authenticate via your identity provider when accessing account resources, giving you full control over application access. Directory sync automatically provisions and de-provisions users for your account. Provisioned users are given basic Member roles and will have access to any resources that role entails. When a user is unassigned from the Prefect Cloud application in your identity provider, they will automatically lose access to Prefect Cloud resources, allowing your IT team to control access to Prefect Cloud without ever signing into the Prefect UI. Custom accounts have access to SCIM for user provisioning. The SSO tab provides access to enable SCIM provisioning.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.2.0.md

+++ title = "CoreDNS-1.2.0 Release" description = "CoreDNS-1.2.0 Release Notes." tags = ["Release", "1.2.0", "Notes"] release = "1.2.0" date = "2018-07-11T11:13:29+01:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.2.0! In this release we have a new plugin, bump etcd to version 3 and bugfixes. Enable watch functionality when CoreDNS is used as a gRPC server (documented in the code - for now). A new plugin called was added. It adds metadata to a query, via the context. The plugin now supports etcd version 3 (only!). It was impossible to support v2 and* v3 at the same time (even as separate plugins); so we decided to drop v2 support. Fix a race/crash in the plugin when `prefetch` is enabled. The plugin has a `prefer_udp` option, that even when the incoming query is over TCP, the outgoing one will be tried over UDP first. plugin has a bug fix for zone expiration: don't expire zones if we can reach the primary, but see no zone changes. The plugin now works better with Kubernetes Configmaps. The following people helped with getting this release done: Chris O'Haver, Eren Gven, Eugen Kleiner, Francois Tur, Isolus, Joey Espinosa, John Belamaric, Jun Li, Marcus Andr, Miek Gieben, Nitish Tiwari, Ruslan Drozhdzh, Tobias Schmidt, Yong Tang. For documentation see our (in progress!) . For help and other resources, see our .
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: status_ordering.md

Ordering Status and Reads in the gRPC API -- Rules for implementors: Reads and Writes Must not succeed after Status has been delivered. Status is only delivered after all buffered messages are read. Reads May continue to succeed after a failing write. However, once a write fails, all subsequent writes Must fail, and similarly, once a read fails, all subsequent reads Must fail. A non-OK status received from the server is not considered an error status. When an error status is known to the library, if the user asks for status, the library Should discard messages received in the library but not delivered to the user and then deliver the status. If the user does not ask for status but continues reading, the library Should deliver buffered messages before delivering status. The library MAY choose to implement the stricter version where errors cause all buffered messages to be dropped, but this is not a requirement.
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: 202111-unified-access-entry.md

Use ingress to create a unified access entry for Function. Step 1: Create an external service for each Function that points to the ingress controller's service. ```yaml apiVersion: v1 kind: Service metadata: name: function-sample namespace: default spec: externalName: ingress-nginx-controller.ingress-nginx.svc.cluster.local internalTrafficPolicy: Cluster ports: name: http2 port: 80 protocol: TCP targetPort: 80 sessionAffinity: None type: ExternalName status: loadBalancer: {} ``` Step 2: All functions in the same namespace will use the same ingress. The function controller will add a corresponding `path` to the ingress whenever the function is created, and update the `path` whenever the function is updated. The ingress looks like this. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-vhost: $service_name.$namespace name: function-sample namespace: default spec: ingressClassName: nginx rules: host: function-sample.default http: paths: backend: service: name: function-sample-serving-d55zz-ksvc-gd64w port: number: 80 path: / pathType: Prefix status: loadBalancer: {} ``` Step 3: Use ``` http://<Function name>.<Function namespace>/ ``` to access the Function. Step 1: Create a service named `openfunction` in the same namespace as the ingress controller, for example `ingress-nginx`. The endpoints of the service are the ingress controller pod. Step 2: All functions in the same namespace will use the same ingress. The function controller will add a corresponding `path` to the ingress whenever the function is created, and update the `path` whenever the function is updated. The ingress looks like this. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/upstream-vhost: $service_name.$namespace nginx.ingress.kubernetes.io/rewrite-target: /$2 name: function-sample namespace: default spec: ingressClassName: nginx rules: http: paths: backend: service: name: serving-d55zz-ksvc-gd64w port: number: 80 path: /default/function-sample(/|$)(.*) pathType: Prefix status: loadBalancer: {} ``` Step 3: Use ```shell http://<Service name>.<Ingress controller namespace>/<Function namespace>/<Function name>/ ``` to access the Function.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: upgrade.md

To upgrade Kusk Gateway in your cluster, you will need to install the new version of Kusk CLI first and then upgrade Kusk Gateway with it. Check the in case you are using Helm. ```sh brew upgrade kubeshop/kusk/kusk ``` or if you don't use `brew` you can upgrade directly with: ```sh curl -sSLf https://raw.githubusercontent.com/kubeshop/kusk-gateway/main/cmd/kusk/scripts/install.sh | bash ``` Install script ```sh curl -sSLf https://raw.githubusercontent.com/kubeshop/kusk-gateway/main/cmd/kusk/scripts/install.sh | bash ``` APT (Debian/Ubuntu) Update your local repository index: ```sh sudo apt-get update ``` Upgrade Kusk: ```sh sudo apt-get upgrade -y kusk ``` Chocolatey Please run the command from an elevated command shell. ```sh choco upgrade kusk -y ``` For other ways of installation, you can download the or use the following command ( needed): ```sh go install -x github.com/kubeshop/kusk-gateway/cmd/kusk@latest ``` ```sh kusk cluster upgrade ``` This command will update Kusk Gateway and its components so you can use the latest features and have all the security measures up to date.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
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, 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 oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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 .
Project: BFE (Orchestration & Management / Service Proxy)
File: forward_model.md

Step 1-2DNS resolution The hostname to resolve is demo.example.com The translated IP address from DNS server is 6.6.6.6example Step 3The client creates a TCP connection to 6.6.6.6 on port 80 and send a HTTP request. The IP diagrams are routed to PoP of IDC1and processed by the Layer 4 Load Balancer. Step 4The Layer 4 Load Balancer forwards diagrams to BFE. Step 5BFE receives an HTTP request and find a product for it: BFE uses the HTTP Host header to find the suitable product. In this scenario, assume demo.example.com belongs to product "demo". Step 6Based on routing rules of product "demo", BFE finds a suitable cluster to process the request. In this scenario, assume the selected cluster is "demo-static". See Step 7-8Based on balancing policies of product "demo", BFE selects a sub cluster and an instance within cluster "demo-static" In this scenario, assume the selected sub cluster is "demo-static.idc1" and the selected instance is "demo-static-01.idc1" . See Step 9The request is forwarded to "demo-static-01.idc1". Step 10BFE receives a response from "demo-static-01.idc1". Step 11-12BFE forwards the response to the client via the Layer 4 Load Balancer.
Project: Envoy (Orchestration & Management / Service Proxy)
File: postmortem-template.md

Slimmed down template from: Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. [Site Reliability Engineering.](https://landing.google.com/sre/book/chapters/postmortem.html), modified from https://raw.githubusercontent.com/dastergon/postmortem-templates/master/templates/postmortem-template-srebook.md. Follow the SRE link for examples of how to populate. A PR should be opened with postmortem placed in security/postmortems/cve-year-abcdef.md. If there are multiple CVEs in the postmortem, populate each alias with the string "See cve-year-abcdef.md". YYYY-MM-DD (as a date range if over a period of time) @foo, @bar, ... Draft | Final A few sentence summary. https://github.com/envoyproxy/envoy/issues/${CVEISSUEDID} What defect in Envoy led to the CVEs? How did this defect arise? How was the security release process followed? How were the fix patches structured and authored? How was this discovered? Reported by XYZ, found by fuzzing? Private or public disclosure? Create action item issues and include in their body "Action item for CVE-YEAR-ABCDEF". Modify the search string below to include in the PR: https://github.com/envoyproxy/envoy/issues?utf8=%E2%9C%93&q=is%3Aissue+%22Action+item+for+CVE-YEAR-ABCDEF%22 All times US/Pacific YYYY-MM-DD HH:MM Cake was made available HH:MM People ate the cake YYYY-MM-DD HH:MM More cake was available HH:MM People ate more cake
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: resourcequota-plugin.md

As mentioned, When Kubernetes ResourceQuota is insufficient, podgroup should not be able to enqueue. In order to solve this problem, we provide `minQuotas` field which defines the minimal resource quota of tasks to run the pod group, and introduce resourcequota plugin to determine whether the podgroup be able to enqueue according to Kubernetes ResourceQuota. add `RQStatus` map in namespace collection to cache all resourcequotas of namespace; ``` golang RQStatus map[string]v1.ResourceQuotaStatus ``` calc minQuotas in job controller, and backfill to podGroup; add resouceQuota plugin, and register `AddJobEnqueueableFn` function. This plugin will look at pending podgroups and will enqueue them only if there is enough capacity in the namespace according to Kubernetes ResourceQuota. And the plugin also consider podgroups that have already been permitted in the scheduling round to prevent it from enqueueing too many podgroups and exceeding the namespace resource quota.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.5.1-released.md

title: "Avro 1.5.1" linkTitle: "Avro 1.5.1" date: 2011-05-06 <!-- 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 https://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. --> Apache Avro 1.5.1 has been released!
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.22.2.md

We are delighted to present version v1.22.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Bumps Envoy to security patch version 1.23.3. See Envoy release notes . (#4897, @sunjayBhatia) Various updates to dependencies for security updates, upgrade to Go 1.19.3, and bump go module version to go 1.17. (#4882, #4884, @sunjayBhatia) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.22.2 is tested against Kubernetes 1.22 through 1.24. 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-identityproviders.md

By creating identity provider, you are providing capabilities to users to login into the portal / management-ui using external user accounts from GitHub, Google, OpenID Connect server or Gravitee.io AM. You can add as many identity providers as you need and configure each of them individually to manage groups and / or roles for users coming from a given identity provider.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_completion_fish.md

Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: kusk completion fish | source To load completions for every new session, execute once: kusk completion fish > ~/.config/fish/completions/kusk.fish You will need to start a new shell for this setup to take effect. ``` kusk completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` - Generate the autocompletion script for the specified shell
Project: Consul (Orchestration & Management / Service Mesh)
File: config-resolution.md

Merging data from defaults in config entries is roughly a two-step process: Flatten central configuration for proxies at a Consul server. Resolving config is done on behalf of a specific service, and this merge considers multiple config entries, such as proxy-defaults and service-defaults. Merge flattened central defaults into sidecar proxy registrations. This occurs at a client agent in the agentful case, or on a server in the agentless case. Any time the centralized defaults are updated, internal watches will fire and their data will be merged into the registration for the given sidecar proxy. You can ensure that a config entry has applied by querying the service: Agentful: `/v1/agent/service/:service_id` Agentless: `/v1/health/connect/:service_name?merge-central-config` The agentless flow relies on to merge default configuration. This helper is called both when bootstrapping a new dataplane proxy and when an Envoy proxy first dials the `xds` server on a Consul server. This merge does not directly update the proxy registration in the catalog. The merged proxy registration is passed to the consuming `proxycfg` package. The is responsible for ensuring that central configuration is merged down into proxy registrations on client agents. Any time a proxy is registered or updated, the service manager will set up a watch through the agent cache to fetch the central configuration. When the central configuration is fetched, the configuration is merged and persisted to the agent state in . Once centralized defaults have been merged into service registrations, the data becomes available to consume by the `proxycfg` package. This package assembles the necessary Consul data to generate Envoy configuration for a given proxy. The `proxycfg` package does not need explicit watches for the service or proxy-defaults that apply to a sidecar proxy because of how these defaults are merged into proxy registrations. When defaults change, a fresh `proxycfg` snapshot is built based on the latest registration.
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature Request about: Suggest a new feature or enhancement to Nomad labels: "type/enhancement" <!-- Hi there, Thank you for opening an issue. Please note that we try to keep the Nomad issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://developer.hashicorp.com/nomad/community --> <!-- If you have an idea for a way to address the problem via a change to Nomads features, please describe it below. --> <!-- In order to properly evaluate the feature request, it is necessary to understand the use-cases for it. Please describe below the end goal you are trying to achieve that has led you to request this feature. --> <!-- If you have already tried to solve the problem within Nomads existing features and found a limitation that prevented you from succeeding, please describe it below. -->
Project: Traefik (Orchestration & Management / API Gateway)
File: ipwhitelist.md

title: "Traefik TCP Middlewares IPWhiteList" description: "Learn how to use IPWhiteList in TCP middleware for limiting clients to specific IPs in Traefik Proxy. Read the technical documentation." Limiting Clients to Specific IPs {: .subtitle } IPWhiteList accepts / refuses connections based on the client IP. !!! warning This middleware is deprecated, please use the middleware instead. ```yaml tab="Docker" labels: "traefik.tcp.middlewares.test-ipwhitelist.ipwhitelist.sourcerange=127.0.0.1/32, 192.168.1.7" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: test-ipwhitelist spec: ipWhiteList: sourceRange: 127.0.0.1/32 192.168.1.7 ``` ```yaml tab="Consul Catalog" "traefik.tcp.middlewares.test-ipwhitelist.ipwhitelist.sourcerange=127.0.0.1/32, 192.168.1.7" ``` ```toml tab="File (TOML)" [tcp.middlewares] [tcp.middlewares.test-ipwhitelist.ipWhiteList] sourceRange = ["127.0.0.1/32", "192.168.1.7"] ``` ```yaml tab="File (YAML)" tcp: middlewares: test-ipwhitelist: ipWhiteList: sourceRange: "127.0.0.1/32" "192.168.1.7" ``` The `sourceRange` option sets the allowed IPs (or ranges of allowed IPs by using CIDR notation).