cwielenb/CNCF-Dataset huggingface dataset:
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: cli-shell.md

description: Discover how to use the Prefect CLI for executing shell commands as flows. tags: CLI Shell Commands Prefect Flows Automation Scheduling search: boost: 2 The Prefect CLI allows you to execute and schedule shell commands as Prefect flows. This guide explains how to use the `watch` and `serve` commands with the CLI for automation tasks, and covers how to: run a shell command as a Prefect flow on-demand with `watch` schedule a shell command as a recurring Prefect flow using `serve` understand the benefits of embedding these commands into your automation workflows Before you begin, ensure you have: A basic understanding of Prefect flows. Start with the guide if necessary. A recent version of Prefect installed in your command line environment. Follow these if you have any issues. The `watch` command wraps any shell command in a Prefect flow for instant execution. This is ideal for quick tasks or integrating shell scripts into your workflows. To fetch the current weather in Chicago using the `curl` command, use the following Prefect CLI command: ```bash prefect shell watch "curl http://wttr.in/Chicago?format=3" ``` This command makes a request to `wttr.in`, a console-oriented weather service, and prints the weather conditions for Chicago. Immediate feedback: Execute shell commands within the Prefect framework for immediate results. Easy integration: Blend external scripts or data fetching into your data workflows. Visibility and logging: Use Prefect's logging to track the execution and output of your shell tasks. To run shell commands on a schedule, the `serve` command creates a Prefect for regular execution. This is a quick way to create a deployment served by Prefect. To set up a daily weather report for Chicago at 9 AM, use the `serve` command as follows: ```bash prefect shell serve "curl http://wttr.in/Chicago?format=3" --flow-name "Daily Chicago Weather Report" --cron-schedule "0 9 *" --deployment-name "Chicago Weather" ``` This command schedules a Prefect flow to fetch Chicago's weather conditions daily, providing consistent updates without manual intervention. To manually fetch the Chicago weather, create a run of your new deployment from the UI or CLI. To shut down your server and pause your scheduled runs, hit `ctrl` + `c` in the CLI. Automated scheduling: Schedule shell commands to run automatically, ensuring critical updates are generated and available on time. Centralized workflow management: Manage and monitor your scheduled shell commands inside Prefect for a unified workflow overview. Configurable execution: Customize execution frequency, , and other parameters to suit your project's needs and resources.
Project: kube-rs (Orchestration & Management / Scheduling & Orchestration)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below. Bug fixes and new features should include tests. Contributors guide: https://github.com/kube-rs/kube-rs/blob/master/CONTRIBUTING.md --> <!-- Explain the context and why you're making that change. What is the problem you're trying to solve? If a new feature is being added, describe the intended use case that feature fulfills. --> <!-- Summarize the solution and provide any necessary context needed to understand the code change. -->
Project: Gloo (Orchestration & Management / API Gateway)
File: migrating_tests.md

This new provides a standard way to validate behavior end-to-end using the Gloo Gateway product. It differs from a previous standard that was implemented in our package. This document outlines the ways that developers can migrate tests from that old paradigm into the new framework. As per the , we group our test cases by feature. If the test you are migrating is part of already tested feature, just add the test to that feature package directly. If the test you are migrating is part of a new feature, add a new feature package. Features in the product are expected to work under a variety of conditions. Therefore, it may be that you need to invoke the feature test suite from different `TestInstallation`. As per the , we group these TestInstallation by file, so that each file runs the set of tests for a single installation. We our tests across multiple clusters. Since you have added new tests, it may be worthwhile to re-balance the tests. Most importantly, if you added a new file for a `TestInstallation`, assign it a test cluster. It is important that all of our end-to-end tests can be run locally, following our . If there are updates required to that guide, please make them.
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Gloo (Orchestration & Management / API Gateway)
File: domain.proto.sk.md

title: "domain.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Matches a fully qualified server name against a set of domain names with optional wildcards. ```yaml "domainMatchers": []xds.type.matcher.v3.ServerNameMatcher.DomainMatcher ``` | Field | Type | Description | | -- | - | -- | | `domainMatchers` | | Match a server name by multiple domain matchers. Each domain, exact or wildcard, must appear at most once across all the domain matchers. The server name will be matched against all wildcard domains starting from the longest suffix, i.e. ``www.example.com`` input will be first matched against ``www.example.com``, then ``.example.com``, then ``.com``, then ````, until the associated matcher action accepts the input. Note that wildcards must be on a dot border, and values like ``w.example.com`` are invalid. | Specifies a set of exact and wildcard domains and a match action. The wildcard symbol ``*`` must appear at most once as the left-most part of the domain on a dot border. The wildcard matches one or more non-empty domain parts. ```yaml "domains": []string "onMatch": .xds.type.matcher.v3.Matcher.OnMatch ``` | Field | Type | Description | | -- | - | -- | | `domains` | `[]string` | A non-empty set of domain names with optional wildcards, e.g. ``www.example.com``, ``.com``, or ````. | | `onMatch` | | Match action to apply when the server name matches any of the domain names in the matcher. | <!-- 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: BFE (Orchestration & Management / Service Proxy)
File: source_code_layout.md

`bfe_net`: common utility for net `bfe_http`: implementation of HTTP protocol `bfe_tls`: implementation of TLS protocol `bfe_http2`: implementation of HTTP2 protocol `bfe_spdy`: implementation of SPDY protocol `bfe_stream`: implementation of TLS/TCP proxy `bfe_websocket`: implementation WebSocket protocol `bfe_proxy`: implementation of Proxy protocol `bfe_route`: implementation of routing `bfe_balance`: implementation of load balancing `bfe_module`: module framework `bfe_modules`: implementation of various modules `bfe_server`: implementation of core server `bfe_basic`: defines basic data type `bfe_config`: implementation of config `bfe_debug`: defines debug flags for important components `bfe_util`: common utility functions
Project: MetalLB (Orchestration & Management / Service Proxy)
File: metallb-operator.md

MetalLB currently includes [instructions and resources for deploying MetalLB](https://metallb.universe.tf/installation/) using a few methods: directly with manifests, customized manifests with kustomize, or via helm. Another approach for managing the deployment of software on Kubernetes is via an . This document proposes creating an operator for MetalLB in a new git repository under the metallb github organization and publishing it on . For any Kubernetes environment that primarily uses operators to manage add-ons to the cluster, it would be beneficial to have the option of using an operator to manage MetalLB, as well. In , we have discussed creating a CRD based configuration interface for MetalLB. It seems that settling on the ideal data model may require some more time and experimentation. We can make use of this separate operator repo as a place to try out a CRD interface for MetalLB which writes out a ConfigMap and doesn't have to disrupt the core MetalLB project. Create an operator in a new git repository that makes it easy to deploy MetalLB on clusters where operators are the preferred method for managing cluster add-ons. Publish the operator on operatorhub.io to make it discoverable. Use the separate operator repository as a place to experiment with a CRD interface for configuring MetalLB. No changes are proposed for the core MetalLB project. This is not intended to replace the end goal of an eventual full CRD based interface in the core MetalLB project, but instead provide a place to iterate on an interface without any disruption to the project in the short term. Create github.com/metallb/metallb-operator. Grant russellb and any other current MetalLB maintainer commit rights to this repository. Further metallb-operator specific committers may be added in the future based on contributions to the operator and at the approval of the current MetalLB maintainers. Once the operator is functional, publish to operatorhub.io. Document the use of the operator on the MetalLB web site. Releases of metallb-operator would be independent from MetalLB. If this proposal were to be rejected, the operator would live outside of the metallb github organization. Otherwise, I expect most of the rest to remain the same.
Project: Clusternet (Orchestration & Management / Scheduling & Orchestration)
File: ROADMAP.md

This document outlines a high-level roadmap for Clusternet. are used to track the progress of this project. This roadmap is updated frequently to reflect the community's overall thinking on the future of the project. [ ] Cross-cluster HPA (Ongoing) [x] Introduces new component `clusternet-controller-manager` [ ] Introduces de-scheduler for Clusternet [ ] Enhancements on cluster resource predictor framework, such as supporting gRPC, rescheduling pending pods, etc. to address cross-cluster issues, such as service discovery, dns querying, etc. [ ] Generic resource status aggregation [ ] Integration with Istio (Ongoing) [ ] E2E tests [x] Multi-cluster scheduling framework (`in-tree` plugins, `out-of-tree` plugins) [x] Various multi-cluster scheduling policies [x] Dividing scheduling - [x] Cluster resource predictor framework for `in-tree` and `out-of-tree` implementations [x] Various deployment topologies for cluster resource predictors [x] Resource interpretation with `in-tree` or `out-of-tree` controller [x] Subgroup cluster scheduling to provide service discovery across multiple clusters [x] Multi-cluster workloads status aggregation [x] Benchmarks on cluster management and application coordination [x] Cluster registrations across different heterogeneous environments (e.g. public cloud, private cloud, hybrid, and edge cloud) [x] Coordination of various application types, `Deployment`, `CRD`, `HelmChart`, etc. to multiple clusters [x] Full RBAC supports on child clusters [x] Two-stage priority based override strategies [x] JSON patch and Merge patch [x] Easy to rollback overrides [x] Support for more Kubernetes versions [x] User and developer experience improvement [x] client-go integration [x] kubectl plugin [x] hack scripts for building, testing, etc. [x] Clusternet CIs Enhancements
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: SECURITY.md

This document outlines security procedures and general policies for the Open Service Mesh open source project as found on https://github.com/openservicemesh/osm. * IMPORTANT: Please do not open public issues on GitHub for security vulnerabilities The OSM team and community take all security vulnerabilities seriously. Thank you for improving the security of our open source software. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. Report security vulnerabilities by emailing the OSM security team at: cncf-osm@cncf.io Please provide the following: Individual's identity and organization Detailed description of the issue and the consequences of the vulnerability Estimation of the attack surface 3rd party software, if any, used with OSM Detailed steps to reproduce the issue A maintainer will acknowledge your email and send a detailed response within 3 business days indicating the next steps in handling your report. After the initial reply to your report, the team will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. Report potential security issues, or known security issues in a third party modules by opening a Github Issue. If you think you have found a vulnerability in a OSM project. Report potential security issues, or known security issues in a third party modules by opening a Github Issue. For guidance on securing OSM please open a or reach out on the OSM Slack Channel within the For guidance on applying security updates When the team receives a security bug report, they will assign it to someone to be a primary handler. This person will coordinate the fix and release process, involving the following steps: Confirm the problem and determine the affected versions. Audit code to find any potential similar problems. Prepare fixes for all releases still under maintenance. These fixes will be released as fast as possible. Inspired by the
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: teams.md

description: Manage teams of users in Prefect Cloud. tags: UI Permissions Access Prefect Cloud enterprise teams workspaces organizations audit logs compliance search: boost: 2 Prefect Cloud's offers team management to simplify access control governance. Account Admins can configure teams and team membership from the account settings menu by clicking Teams. Teams are composed of users and service accounts. Teams can be added to workspaces or object access control lists just like users and service accounts. If SCIM is enabled on your account, the set of teams and the users within them is governed by your IDP. Prefect Cloud service accounts, which are not governed by your IDP, can be still be added to your existing set of teams. See the to learn more about options for supporting teams.
Project: Gloo (Orchestration & Management / API Gateway)
File: secure_api.md

title: "Optional: Secure the GraphQL API" weight: 50 description: Protect the GraphQL API that you created in the previous sections by using an API key. Protect the GraphQL API that you created in the previous sections by using an API key. Note that you can also use any other authorization mechanism provided by Gloo Edge to secure your GraphQL endpoint. Create an API key secret that contains an existing API key. If you want `glooctl` to create an API key for you, you can specify the `--apikey-generate` flag instead of the `--apikey` flag. ```sh glooctl create secret apikey my-apikey \ --apikey $API_KEY \ --apikey-labels team=gloo ``` Verify that the secret was successfully created and contains an API key. If you had Gloo Edge generate the API key, set the value as an environment variable, `export API_KEY=<api-key-value>`. ```sh kubectl get secret my-apikey -n gloo-system -o yaml ``` Create an AuthConfig CR that uses the API key secret. ```sh kubectl apply -f - <<EOF apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: name: apikey-auth namespace: gloo-system spec: configs: apiKeyAuth: headerName: api-key labelSelector: team: gloo EOF ``` Update the `default` virtual service that you previously created to reference the `apikey-auth` AuthConfig. {{< highlight yaml "hl_lines=17-21" >}} cat << EOF | kubectl apply -f - apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: 'default' namespace: 'gloo-system' spec: virtualHost: domains: '*' routes: graphqlApiRef: name: bookinfo-graphql namespace: gloo-system matchers: prefix: /graphql options: extauth: configRef: name: apikey-auth namespace: gloo-system EOF {{< /highlight >}} Send a request to the GraphQL endpoint. Note that because you enforced API key authorization, the unauthorized request fails, and you get a `401 Unauthorized` response. ```sh curl "$(glooctl proxy url)/graphql" -H 'Content-Type: application/json' -d '{"query": "query {productsForHome {id, title, author, pages, year}}"}' -v ``` Add the API key to your request in the `-H 'api-key: $API_KEY'` header, and curl the endpoint again. ```sh curl "$(glooctl proxy url)/graphql" -H 'Content-Type: application/json' -H 'api-key: $API_KEY' -d '{"query": "query {productsForHome {id, title, author, pages, year}}"}' ``` Example successful response: ```json {"data":{"productsForHome":[{"id":"0","title":"The Comedy of Errors","author":"William Shakespeare","pages":200,"year":1595}]}} ``` Now that you've tried out GraphQL with Gloo Edge, check out the following pages to configure your own services for GraphQL integration.
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: bug-report.md

name: Bug Report about: Report a bug encountered while using kubectl labels: kind/bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via https://kubernetes.io/security/ --> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See https://kubernetes.io/docs/setup/release/version-skew-policy for which versions and are currently supported. --> Anything else we need to know?: Environment: Kubernetes client and server versions (use `kubectl version`): Cloud provider or hardware configuration: OS (e.g: `cat /etc/os-release`):
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: description.md

Metal provisions uses bare-metal instances to allocate resources. The Cloud providers feature the following characteristics: Hosts are provisioned as metal instances in the selected provider. Supported virtualization technologies: QEMU/KVM and LXC The provision includes a public network (Internet reachable IPs) It also includes a virtual network template to create private VLANs. You need to instantiate this network template. The onprem provider uses on premises infrastructure. This provision is useful for automate the datacenter configuration and operation. More information using this provision can be found in the
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: privacy.md

With the aim to improve the user experience, Kusk collects anonymous usage data. You may if you'd prefer not to share any information. The data collected is always anonymous, not traceable to the source, and only used in aggregate form. Telemetry collects and scrambles information about the host when the API server is bootstrapped for the first time. ```json { "anonymousId": "37c7dd3d2f0cd7eca8fdc5b606577278bf2a65e5da42fd4b809cfdf103583a98", "context": { "library": { "name": "analytics-go", "version": "3.0.0" } }, "event": "kusk-cli", "integrations": {}, "messageId": "c785d086-2d85-4d7a-9468-1da350822c95", "originalTimestamp": "2022-07-15T11:42:41.213006+08:00", "properties": { "event": "dashboard" }, "receivedAt": "2022-07-15T03:42:42.691Z", "sentAt": "2022-07-15T03:42:41.215Z", "timestamp": "2022-07-15T03:42:42.689Z", "type": "track", "userId": "37c7dd3d2f0cd7eca8fdc5b606577278bf2a65e5da42fd4b809cfdf103583a98", "writeKey": "1t8VoI1wfqa43n0pYU01VZU2ZVDJKcQh" } ``` The telemetry data we use in our metrics is limited to: The number of CLI installations. The number of unique CLI usages in a day. The number of installations to a cluster. The number of unique active cluster installations. The number of people who disable telemetry. The number of unique sessions in the UI. The number of API, StaticRoute and EnvoyFleet creations. To disable sending the anonymous analytics, provide the `analytics.enable: false` override during Helm chart installation or upgrade. See the <a href="https://github.com/kubeshop/helm-charts/blob/main/charts/kusk-gateway/values.yaml" target="_blank">Helm chart parameters</a> for more details about Helm chart configuration. ``` helm upgrade kusk-gateway kubeshop/kusk-gateway \ --install --namespace --create-namespace \ --set analytics.enabled=false \ ... ``` Set the following environment variable when running Kusk commands ``` export ANALYTICS_ENABLED=false ``` or ``` ANALYTICS_ENABLED=false kusk cluster install ```
Project: MetalLB (Orchestration & Management / Service Proxy)
File: initial.md

You need to create a file for this page. You can either create a file in the `content` folder and fill it with Markdown content inside a folder named by the page's title like `<TITLE>/_index.md` or `<TITLE>/index.md` named by the page's title like `<TITLE>.md` create a file in the `static` folder and fill it with HTML content inside a folder named by the page's title like `<TITLE>/index.html`
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.4.md

+++ title = "CoreDNS-1.6.4 Release" description = "CoreDNS-1.6.4 Release Notes." tags = ["Release", "1.6.4", "Notes"] release = "1.6.4" date = 2019-09-27T10:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . Various code cleanups and documentation improvements. We've added one new plugin: acl, that allows blocking requests. block request from IPs or IP ranges. received some bug fixes, see below for specific PRs. exports metrics on the number of entries and last reload time. An Xiao, Chris O'Haver, Cricket Liu, Guangming Wang, Kasisnu, li mengyang, Miek Gieben, orangelynx, xieyanker, yeya24, Yong Tang. plugin/hosts: add host metrics (https://github.com/coredns/coredns/pull/3277) plugin/kubernetes: Don't duplicate service record for every port (https://github.com/coredns/coredns/pull/3240) plugin/kubernetes: Handle multiple local IPs and bind (https://github.com/coredns/coredns/pull/3208) Add plugin ACL for source IP filtering (https://github.com/coredns/coredns/pull/3103)