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

In the serverless scenario, Workload such as Job, when the user container of the Pod completes the task and exits, the Fuse Sidecar can also actively exit. This enables the Job Controller to correctly determine the completion status of the Pod. However, the fuse container itself does not have an exit mechanism, and the Fluid Application Controller will detect the pods with the fluid label in the cluster. After the user container exits, the fuse container is exited normally to reach the state where the job is completed. You can download the latest Fluid installation package from . Refer to the to complete the installation. And check that the components of Fluid are running normally (here takes JuiceFSRuntime as an example): ```shell $ kubectl -n fluid-system get po NAME READY STATUS RESTARTS AGE dataset-controller-86768b56fb-4pdts 1/1 Running 0 36s fluid-webhook-f77465869-zh8rv 1/1 Running 0 62s fluidapp-controller-597dbd77dd-jgsbp 1/1 Running 0 81s juicefsruntime-controller-65d54bb48f-vnzpj 1/1 Running 0 99s ``` Typically, you will see a Pod named `dataset-controller`, a Pod named `juicefsruntime-controller`, a Pod named `fluid-webhook` and a Pod named `fluidapp-controller`. Create dataset and runtime Create corresponding Runtime resources and Datasets with the same name for different types of runtimes. Take JuiceFSRuntime as an example here. For details, please refer to , as follows: ```shell $ kubectl get juicefsruntime NAME WORKER PHASE FUSE PHASE AGE jfsdemo Ready Ready 2m58s $ kubectl get dataset NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE jfsdemo [Calculating] N/A N/A Bound 2m55s ``` Create Job To use Fluid in a serverless scenario, you need to add the `serverless.fluid.io/inject: "true"` label to the application pod. as follows: ```yaml $ cat<<EOF >sample.yaml apiVersion: batch/v1 kind: Job metadata: name: demo-app spec: template: metadata: labels: serverless.fluid.io/inject: "true" spec: containers: name: demo image: busybox args: -c echo $(date -u) >> /data/out.txt command: /bin/sh volumeMounts: mountPath: /data name: demo restartPolicy: Never volumes: name: demo persistentVolumeClaim: claimName: jfsdemo backoffLimit: 4 EOF $ kubectl create -f sample.yaml job.batch/demo-app created ``` Check if the Pod is completed ```shell $ kubectl get job NAME COMPLETIONS DURATION AGE demo-app 1/1 14s 46s $ kubectl get po NAME READY STATUS RESTARTS AGE demo-app-wdfr8 0/2 Completed 0 25s jfsdemo-worker-0 1/1 Running 0 14m ``` It can be seen that the job has been completed, and its pod has two containers, both of which have been completed.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: script.md

If you need to use `Shell script` for alerting, create an alert instance in the alert instance management and select the `Script` plugin. The following shows the `Script` configuration example: | Parameter | Description | ||-| | User Params | User defined parameters will pass to the script. | | Script Path | The file location path in the server, only support .sh file | | Type | Support `Shell` script. | Consider the script file access privileges with the executing tenant.
Project: Azure API Management (Orchestration & Management / API Gateway)
File: README.md

<img src="./media/apim-logo.png" alt="Azure API Management" width="96" style="margin-bottom: 40px;"> This repository is used for publishing . Developer portal release notes are published in . ](https://github.com/Azure/API-Management/releases) Explore other resources about Azure API Management: Explore other Azure API Management repositories:
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.8.3.md

+++ title = "CoreDNS-1.8.3 Release" description = "CoreDNS-1.8.3 Release Notes." tags = ["Release", "1.8.3", "Notes"] release = "1.8.3" date = 2021-02-24T07:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . This release includes a bunch of bugfixes and a few enhancements, see below. In case you're wondering, 1.8.2 didn't properly upload and tag the docker images, hence a quick followup release with that fixed. Bob, chantra, Chris O'Haver, Frank Riley, George Shammas, Johnny Bergstrm, Jun Chen, Lars Ekman, Manuel Rger, Maxime Ginters, Miek Gieben, slick-nic, TimYin. core: Also clear `do` and `size` (https://github.com/coredns/coredns/pull/4465) core: Flag blacklisting not needed anymore (https://github.com/coredns/coredns/pull/4420) core: Set http request in writer (https://github.com/coredns/coredns/pull/4445) Makefile.release: Replace manifest-tool with docker manifest (https://github.com/coredns/coredns/pull/4421) Makefile.release: Fix the Makefile (https://github.com/coredns/coredns/pull/4483) plugin/acl: add the ability to filter records (https://github.com/coredns/coredns/pull/4389) plugin/dnstap: Fix out of order messages and fix forward perspective. (https://github.com/coredns/coredns/pull/4395) plugin/forward Add rcode and rtype to requestdurationseconds metric (https://github.com/coredns/coredns/pull/4391) plugin/kubernetes: Corrected detection of K8s minor version (https://github.com/coredns/coredns/pull/4430) plugin/kubernetes: make kubeconfig argument 'context' optional (https://github.com/coredns/coredns/pull/4451) plugin/rewrite: copy msg before rewriting (https://github.com/coredns/coredns/pull/4443) plugin/rewrite: SRV targets and additional names in response (https://github.com/coredns/coredns/pull/4287) plugin/sign: track zone file's mtime (https://github.com/coredns/coredns/pull/4431) plugin/trace: Use compatible tag name for datadog (https://github.com/coredns/coredns/pull/4408) plugin/transfer: only allow outgoing axfr over tcp (https://github.com/coredns/coredns/pull/4452)
Project: Gloo (Orchestration & Management / API Gateway)
File: http_uri.proto.sk.md

title: "http_uri.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Envoy external URI descriptor ```yaml "uri": string "cluster": string "timeout": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `uri` | `string` | The HTTP server URI. It should be a full FQDN with protocol, host and path. Example: .. code-block:: yaml uri: https://www.googleapis.com/oauth2/v1/certs. | | `cluster` | `string` | A cluster is created in the Envoy "clustermanager" config section. This field specifies the cluster name. Example: .. code-block:: yaml cluster: jwkscluster. | | `timeout` | | Sets the maximum duration in milliseconds that a response can take to arrive upon request. | <!-- 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: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: filesystems.md

title: Apache Mesos - Filesystem Isolators in Mesos Containerizer layout: documentation The has several 'filesystem' isolators that are used to provide isolation for a container's filesystems. Usually, each platform has a corresponding filesystem isolator associated with it, because the level of isolation depends on the capabilities of that platform. Currently, the Mesos Containerizer supports the and isolators. isolator has a subset of the features provided by the isolator and is broken on hosts with systemd (), thus is not recommended and will be deprecated. If you are using the Mesos Containerizer, at least one of the filesystem isolators needs to be specified through the `--isolation` flag. If a user does not specify any filesystem isolator, Mesos Containerizer will default to using the isolator. Filesystem isolation is a pre-requisite for all the [container volume isolators](../container-volume.md) because it provides some basic functionality that the volume isolators depends on. For example, the isolator will create a new mount namespace for the container so that any volume mounts made by the volume isolators will be hidden from the host mount namespace. The filesystem isolator is also responsible for preparing for containers. The `filesystem/posix` isolator works on all POSIX systems. It isolates container sandboxes and persistent volumes using UNIX file permissions. All containers share the same host filesystem. As a result, if you want to specify a for the container, you cannot use this isolator. Use the isolator instead. The `filesystem/posix` isolator handles by creating symlinks in the container's sandbox that point to the actual persistent volumes on the host filesystem. The `filesystem/linux` isolator works only on Linux. It isolates the filesystems of containers using the following primitives: Each container gets its own mount namespace. The default in each container is set to 'slave'. Use UNIX file permissions to protect container sandboxes and persistent volumes. Each container is allowed to define its own . If a container image is specified, by default, the container won't be able to see files and directories on the host filesystem. The `filesystem/linux` isolator handles by bind mounting persistent volumes into the container's sandbox.
Project: Kuma (Orchestration & Management / Service Mesh)
File: PULL_REQUEST_TEMPLATE.md

<!-- Each of these sections need to be filled by the author when opening the PR. If something doesn't apply please check the box and add a justification after the `--` --> as well as docs and UI issues -- [ ] This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like `syscall.Mkfifo` have equivalent implementation on the other OS -- [ ] Tests (Unit test, E2E tests, manual test on universal and k8s) -- Don't forget `ci/` labels to run additional/fewer tests ? -- ? ( GH action will add "backport" label based on these , if you want to prevent it from adding the "backport" label use label) -- <!-- Changelog: skip --> <!-- Uncomment the above section to explicitly set a ? -->
Project: MetalLB (Orchestration & Management / Service Proxy)
File: README.md

A theme for designed for documentation. The Relearn theme is a fork of the great with the aim of fixing long outstanding bugs and adapting to latest Hugo features. As far as possible this theme tries to be a drop-in replacement for the Learn theme. Wide set of usage scenarios Responsive design for mobile usage Looks nice on paper (if it has to) Usable offline, no external dependencies - Support for the for on-premise CMS capabilities Support for Internet Explorer 11 Configurable theming and visuals - Predefined light, dark and color variants - Unique theme features - In page search - - - Hidden pages Multi language support - : Arabic, Simplified Chinese, Traditional Chinese, Czech, Dutch, English, Finnish, French, German, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Swahili, Turkish, Vietnamese Additional Markdown features - Shortcodes galore - - - - - - and For a detailed description of the theme's capabilities visit the . See the page for release highlights or the detailed for a complete list of changes. You are most welcome to contribute bugfixes or new features. Check the first before starting. The Relearn theme is licensed under the . This theme would not be possible without the work of .
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: embargo-policy.md

This policy forbids members of this project's security contacts any others defined below from sharing information outside of the security contacts and this listing without need-to-know and advance notice. The information members and others receive from the list defined below must: not be made public, not be shared, not be hinted at must be kept confidential and close held Except with the list's explicit approval. This holds true until the public disclosure date/time that was agreed upon by the list. If information is inadvertently shared beyond what is allowed by this policy, you are REQUIRED to inform the security contacts kubernetes-security@service.aliyun.com of exactly what information leaked and to whom. A retrospective will take place after the leak so we can assess how to not make this mistake in the future. Violation of this policy will result in the immediate removal and subsequent replacement of you from this list or the Security Contacts. This project sustains a disclosure timeline to ensure we provide a quality, tested release. On some occasions, we may need to extend this timeline due to complexity of the problem, lack of expertise available, or other reasons. Submitters will be notified if an extension occurs.
Project: APISIX (Orchestration & Management / API Gateway)
File: PULL_REQUEST_TEMPLATE.md

<!-- Please include a summary of the change and which issue is fixed. --> <!-- Please also include relevant motivation and context. --> Fixes # (issue) [ ] I have explained the need for this PR and the problem it solves [ ] I have explained the changes or the new features added to this PR [ ] I have added tests corresponding to this change [ ] I have updated the documentation to reflect this change first) <!-- Note Mark the PR as draft until it's ready to be reviewed. Always add/update tests for any changes unless you have a good reason. Always update the documentation to reflect the changes made in the PR. Make a new commit to resolve conversations instead of `push -f`. To resolve merge conflicts, merge master instead of rebasing. Use "request review" to notify the reviewer after making changes. Only a reviewer can mark a conversation as resolved. -->
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: subscribe.md

layout: post title: Newsletter background: grey description: "Service Mesh Performance (SMP): Measure your service mesh performance using SMP. SMP provides a universal performance index to gauge your meshs efficiency against deployments in other organizations environments." twitter: smp_spec lang: en image: path: /assets/img/logo/smp.png width: 1500 {% include subscribe.html %}
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0000-use-markdown-architectural-decision-records.md

We want to record architectural decisions made in this project. Which format and structure should these records follow? 2.1.2 The Markdown Architectural Decision Records The first incarnation of the term "ADR" The Y-Statements Other templates listed at <https://github.com/joelparkerhenderson/architecturedecisionrecord> Formless No conventions for file format and structure Chosen option: "MADR 2.1.2", because Implicit assumptions should be made explicit. Design documentation is important to enable people understanding the decisions later on. See also . The MADR format is lean and fits our development style. The MADR structure is comprehensible and facilitates usage & maintenance. The MADR project is vivid. Version 2.1.2 is the latest one available when starting to document ADRs.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: document.md

Good documentation is critical for any type of software. Any contribution that can improve the DolphinScheduler documentation is welcome. Documentation for the DolphinScheduler project is maintained in a separate . First you need to fork the document project into your own github repository, and then clone the document to your local computer. ``` git clone https://github.com/<your-github-user-name>/dolphinscheduler-website ``` The DolphinScheduler website is supported by Make sure that your node version is 10+, docsite does not yet support versions higher than 10.x. Run `npm install` in the root directory to install the dependencies. Run commands to collect resources 2.1.Run `export PROTOCOLMODE=ssh` tells Git clone resource via SSH protocol instead of HTTPS protocol. 2.2.Run `./scripts/preparedocs.sh` prepare all related resources, for more information you could see . Run `npm run start` in the root directory to start a local server, you will see the website in 'http://localhost:8080'. Run `npm run build` to build source code into dist directory. Verify your change locally: `python -m SimpleHTTPServer 8000`, when your python version is 3 use :`python3 -m http.server 8000` instead. If the latest version of node is installed locally, consider using `nvm` to allow different versions of `node` to run on your computer. Refer to the to install nvm. Run `nvm install v10.23.1` to install node v10. Run `nvm use v10.23.1` to switch the current working environment to node v10. Now you can run and build the website in your local environment. Spaces are Required between Chinese characters and English or numbers and Spaces are not required between Chinese punctuation marks and English or numbers, to enhance the aesthetics and readability of the Chinese-English mix. It is recommended that you use "you" in general. Of course, you can use the term when necessary, such as when there is a warning prompt. Do not use "git add." to commit all changes. Simply push the changed files, for example: `.md` `blog.js or docs.js or site.js` Submit the Pull Request to the master branch.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: athena.md

| Datasource | Description | |-|--| | Datasource | Select ATHENA. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | Username | Set the AWS access key. | | Password | Set the AWS secret access key. | | AwsRegion | Set the AWS region. | | Database name | Enter the database name of the ATHENA connection. | | Jdbc connection parameters | Parameter settings for ATHENA connection, in JSON format. | No, read section example in `DataSource Center` section to activate this datasource. JDBC driver configuration reference document Driver download link
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: "" assignees: "" <!-- Feel free to skip the sections if they are not applicable. --> 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 or screenshots about the feature request here. -->
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_delete.md

title: "glooctl delete" weight: 5 Delete a Gloo resource ``` glooctl delete [flags] ``` ``` -h, --help help for delete --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") ``` ``` -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 - delete a proxy - delete an upstream - delete an upstream group - delete a virtualservice
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: template.md

| Status | Deciders | Date | |--|-|| | status | deciders | date | [Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] [Give a concise statement of the problem this ADR solved, or the action that was taken.] [driver 1, e.g., a force, facing concern, ] [driver 2, e.g., a force, facing concern, ] <!-- numbers of drivers can vary --> [option 1] [option 2] [option 3] <!-- numbers of options can vary --> Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | | comes out best (see below)]. [e.g., improvement of quality attribute satisfaction, follow-up decisions required, ] [e.g., compromising quality attribute, follow-up decisions required, ] [example | description | pointer to more information | ] <!-- optional --> Good, because [argument a] Good, because [argument b] Bad, because [argument c] <!-- numbers of pros and cons can vary --> [example | description | pointer to more information | ] <!-- optional --> Good, because [argument a] Good, because [argument b] Bad, because [argument c] <!-- numbers of pros and cons can vary --> [example | description | pointer to more information | ] <!-- optional --> Good, because [argument a] Good, because [argument b] Bad, because [argument c] <!-- numbers of pros and cons can vary --> --> <!-- numbers of links can vary -->
Project: BFE (Orchestration & Management / Service Proxy)
File: install_using_snap.md

Execute the following command to install bfe: ```bash $ sudo snap install --edge bfe ``` !!! tip Configuration files location: /var/snap/bfe/common/conf/ <br> Log files location: /var/snap/bfe/common/log/ Execute the following command to run bfe: ```bash $ sudo /snap/bin/bfe ``` Get familiar with Get started with
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.11.2.md

+++ title = "CoreDNS-1.11.2 Release" description = "CoreDNS-1.11.2 Release Notes." tags = ["Release", "1.11.2", "Notes"] release = "1.11.2" date = "2024-01-26T00:00:00+00:00" author = "coredns" +++ This release contains some new features, bug fixes, and package updates. New features include: When the forward plugin receives a malformed upstream response that overflows, it will now send an empty response to the client with the truncated (TC) bit set to prompt the client to retry over TCP. The rewrite plugin can now rewrite response codes. The dnstap plugin now supports adding metadata to the dnstap `extra` field. Amila Senadheera, Ben Kochie, Benjamin, Chris O'Haver, Grant Spence, John Belamaric, Keita Kitamura, Marius Kimmina, Michael Grosser, Ondej Benkovsk, P. Radha Krishna, Rahil Bhimjiani, Sri Harsha, Tom Thorogood, Willow (GHOST), Yong Tang, Yuheng, Zhizhen He, guangwu, journey-c, pschou plugin/tls: respect the path specified by root plugin (https://github.com/coredns/coredns/pull/6138) plugin/auto: warn when auto is unable to read elements of the directory tree (https://github.com/coredns/coredns/pull/6333) plugin/etcd: the etcd client adds the DialKeepAliveTime parameter (https://github.com/coredns/coredns/pull/6351) plugin/cache: key cache on Checking Disabled (CD) bit (https://github.com/coredns/coredns/pull/6354) plugin/forward: Use the correct root domain name in the forward plugin's health checks (https://github.com/coredns/coredns/pull/6395) plugin/forward: Handle UDP responses that overflow with TC bit (https://github.com/coredns/coredns/pull/6277) plugin/rewrite: fix multi request concurrency issue in cname rewrite (https://github.com/coredns/coredns/pull/6407) plugin/rewrite: add rcode as a rewrite option (https://github.com/coredns/coredns/pull/6204) plugin/dnstap: add support for "extra" field in payload (https://github.com/coredns/coredns/pull/6226) plugin/cache: fix keepttl parsing (https://github.com/coredns/coredns/pull/6250)