cwielenb/CNCF-Dataset huggingface dataset:
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-proxy.md

Configure your connection to the backend endpoint(s). Endpoints Declare new endpoint by clicking on the (+) button and configure existing endpoints by clicking on the settings button. Load Balancing Choose among 4 kinds of load balancing method to manage how to dispatch API calls. Fail over Configure redirect calls strategy in case of some endpoint failures. CORS CORS configuration to handle connection from front-end applications. Deployment Choose registered sharding tags to choose on which gateway the API must be deployed. Sharding tags are configured at Gateway level. User must belong to a group authorized to deploy on the tag. Multi-tenant Enable multi-tenant mode to route incoming calls to the corresponding tenant endpoint. Tenants are configured at Gateway level. Logging Enable logging at to ease debugging. Logs will be available under API Logs section.
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: gnu-make.md

A quick primer on GNU Make syntax ================================= This tries to cover the syntax that is hard to ctrl-f for in <https://www.gnu.org/software/make/manual/make.html> (err, hard to C-s for in `M-: (info "Make")`). At the core is a "rule": target: dependency1 dependency2 command to run If `target` something that isn't a real file (like 'build', 'lint', or 'test'), then it should be marked as "phony": target: dependency1 dependency2 command to run .PHONY: target You can write reusable "pattern" rules: %.o: %.c command to run Of course, if you don't have variables for the inputs and outputs, it's hard to write a "command to run" for a pattern rule. The variables that you should know are: $@ = the target $^ = the list of dependencies (space separated) $< = the first (left-most) dependency $* = the value of the % glob in a pattern rule Each of these have $(@D) and $(@F) variants that are the directory-part and file-part of each value, respectively. I think those are easy enough to remember mnemonically: $@ is where you should direct the output at. $^ points up at the dependency list $< points at the left-most member of the dependency list $ is the % glob; "" is well-known as the glob char in other languages Make will do its best to guess whether to apply a pattern rule for a given file. Or, you can explicitly tell it by using a 3-field (2-colon) version: foo.o bar.o: %.o: %.c command to run In a non-pattern rule, if there are multiple targets listed, then it is as if rule were duplicated for each target: target1 target2: deps command to run target1: deps command to run target2: deps command to run Because of this, if you have a command that generates multiple outputs, it must be a pattern rule: %.c %.h: %.y command to run Normally, Make crawls the entire tree of dependencies, updating a file if any of its dependencies have been updated. There's a really poorly named feature called "order-only" dependencies: target: normal-deps | order-only-deps Dependencies after the `|` are created if they don't exist, but if they already exist, then don't bother updating them. Tips: -- Use absolute filenames; it's silly, but can often reduce headaches. Use `$(OSS_HOME)` to spell the absolute filenames. Though, this isn't so helpful in Emissary anymore. The main case where this helps is when the same directory-specific Makefile might be `include`d from several different top-level directories; as the Helm chart Makefile used to be from the main Emissary Makefile, or the Emissary Makefile used to be from Edge Stack. But Emissary no longer does this. If you have a multiple-output command where the output files have dissimilar names, have `%` be just the directory (the above tip about using absolute filenames makes this easier--this is a real pain if you have such a target in the top-level directory and aren't using absolute filenames). It can be useful to use the 2-colon form of a pattern rule when writing a rule for just one file; it lets you use `%` and `$*` to avoid repeating yourself, which can be especially useful with long filenames.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: use_encryptoptions.md

When creating a Dataset in Fluid, sometimes we need to configure some sensitive information in the `mounts`. To ensure security, Fluid provides the ability to configure these sensitive information using Secret. The following takes access to the data set as an example to illustrate how to configure. ```shell $ cat << EOF >> dataset.yaml apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: mydata spec: mounts: mountPoint: oss://<OSSBUCKET>/<OSSDIRECTORY>/ name: mydata options: fs.oss.endpoint: <OSS_ENDPOINT> encryptOptions: name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeyId name: fs.oss.accessKeySecret valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeySecret apiVersion: data.fluid.io/v1alpha1 kind: AlluxioRuntime metadata: name: mydata spec: replicas: 1 tieredstore: levels: mediumtype: MEM path: /dev/shm quota: 2Gi high: "0.95" low: "0.7" EOF ``` As you can see, in the above configuration, unlike the direct configuration of `fs.oss.endpoint`, we changed the configuration of `fs.oss.accessKeyId` and `fs.oss.accessKeySecret` to read from Secret to ensure safety. It should be noted that if the same key is configured both in `options` and `encryptOptions`, then the value in `encryptOptions` will override the corresponding value in `options`. In the Secret to be created, you need to specify the sensitive information that needs to be configured in the above Dataset. ```shell $ cat<<EOF >mysecret.yaml apiVersion: v1 kind: Secret metadata: name: mysecret stringData: fs.oss.accessKeyId: <OSSACCESSKEY_ID> fs.oss.accessKeySecret: <OSSACCESSKEY_SECRET> EOF ``` As you can see, the specific contents of `fs.oss.accessKeySecret` and `fs.oss.accessKeyId` are written in Secret, and Dataset reads the corresponding value by looking for the Secret and key according to its configuration, instead of reading them in its configuration directly. So the security of some data is guaranteed.
Project: Contour (Orchestration & Management / Service Proxy)
File: major-sample.md

This change goes at the top of the changelog, and calls out major changes that require user action. Note that it's heading level 2. It must include a few paragraphs explaining what the change is, why we made the change, preferably with a link to the design document involved, and what the Contour user should do about it. If the change is a breaking one, this document should also include instructions on what to do, preferably with copy-pastable commands to do it. Below is an example from a previous changelog. Kubernetes Services of type `ExternalName` will now not be processed by Contour without active action by Contour's operator. This prevents a vulnerability where an attacker with access to create Service objects inside a cluster running Contour could force Contour's Envoy to expose its own admin interface to the internet with a Service with an ExternalName of `localhost` or similar. With access to Envoy's admin page, an attacker can force Envoy to restart or drain connections (which will cause Kubernetes to restart it eventually). The attacker can also see the names and metadata of TLS Secrets, but not their contents. This version includes two main changes: ExternalName Service processing is now disabled by default, and must be enabled. Even when processing is enabled, obvious attempts to expose `localhost` will be prevented. This is quite a porous control, and should not be relied on as your sole means of mitigation. In short, we recommend migration away from ExternalName Services as soon as you can. If you are currently using ExternalName Services with your Contour installation, it's still recommended that you update to this version. However, as part of updating, you will need to add the `enableExternalNameService: "true"` directive to your Contour configuration file. This is not recommended for general use, because of the concerns above, but we have but some mitigations in place to stop obvious misuse of ExternalName Services if you must have them enabled. Note that because of the cross-namespace control issues documented at kubernetes/kubernetes#103675, you should definitely consider if you can move away from using ExternalName Services in any production clusters. The ability to enable ExternalName Services for Contour is provided to help with migration, it is not recommended for use in production clusters.
Project: Gloo (Orchestration & Management / API Gateway)
File: ext.proto.sk.md

title: "ext.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: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-v0.8.md

Support Registration FeatureGates to pass feature gates ( ) Feat: Adding work subject executor feature related api ( ) Work Update strategy ( ) Add label selector to clusterset spec ( ) Add HostAlias in KlusterletDeployOption ( ) Add help func for cluster and clusterset ( ) Add status for clustersetbinding ( ) Add a helper function to get all valid ManagedClusterSetBindings ( ) move registration feature gates to api ( ) add help func for placement ( ) Register feature "V1beta1CSRAPICompatibility" into FateureGates ( ) Add subresource in binding crd ( ) update DefaultClusterSet feature gate description ( ) Add GOPATH, GOHOSTOS and GOHOSTARCH in makefile ( ) add validation rule to klusterlet namespace ( ) N/A
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: cluster-mapper.md

description: > How to use the cluster mapper. Every object assigned by a location exists on the target location Every object in the target location has appropriate metadata set indicating source Every object in the target location that has status and the appropriate policy choice set will reflect that status back in the source object No object exists in the target location that is not assigned by a source object(s) `1..N` mappers per location (sharding by virtual cluster?) mappers see only the objects assigned to them (special API) can load policy info during mapping? can load policy info from side channels like regular resources wants to watch many different resources at once and deal with them as unstructured assumption: all resources in the location are compatible with the target API (managed by control plane and CRD folding), and if that is broken the mapper is instructed to halt mapping how to deal with partial mapping when one object is broken how does CRD folding actually work (separate doc) assumption: higher level control (admission) manages location accessibility assumption: kcp has 1k virtual clusters with 50k resources, a given mapper may see 1k to 50k resources fully syncing will take `50k / default throttle` (50-100 req/s) ~ 1000s in serial order may be important there may be 100-1k locations, so we may have up to 1/1000 cardinality (implies indexing) mappers that favor summarization objects (deployments) have scale advantages over those that don't (pods) Assumption: we prefer not to require order to correctly map, but some order is implicit due to resource version ordering retrieve all objects assigned to a particular cluster (metadata.annotations["kcp.io/assigned-locations"] = ["a","b"]) transform them into one or more objects for the destination add labels? map namespace from source to target hide certain annotations (assigned-locations?) set and maintain other annotations (like the source namespace / virtual cluster) set a controller ref? perform a merge into the destination object (overwrite of spec) sync some fields (status?) back to source object delete all objects no longer assigned to the remote location read all mappable objects from all mappable resources? use `kcp.io/location=X` label to filter detect when an object policy on mapping is changed? only need the partial object (metadata) can we leverage the garbage collector to delete the object?
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-03-13-mesos-0-17-0-released-featuring-autorecovery.md

layout: post title: Mesos 0.17.0 Released, Featuring Autorecovery for the Replicated Log permalink: /blog/mesos-0-17-0-released-featuring-autorecovery/ published: true post_author: display_name: Jie Yu twitter: jie_yu tags: Release, Autorecovery, Replicatedlog The latest Mesos release, was made available for last week, introducing a new autorecovery feature for the replicated log that handles additional disk failure and operator error scenarios. The replicated log is a distributed append-only log that stores arbitrary data as entries. Replication comes into play as at least a quorum of log replicas are stored on different machines, protecting the data from individual disk or network failures. The replicated log uses the . We will describe additional implementation details in both an upcoming blog post and project documentation. Mesos has had replicated log since version 0.9.0 and , a framework used in production at Twitter, uses replicated log for its persistent storage. Additionally, the Mesos master will start using the replicated log to persist some cluster state with the introduction of the . Before Mesos version 0.17.0, the replicated log could become inconsistent if a replicas disk was replaced or the data was accidentally deleted by an operator. That meant that an operator couldnt safely, or easily, replace a replicas disk while the other replicas kept running. Instead, an operator had to stop all replicas, replace the disk, copy a pre-existing log, then restart all the replicas. As of this release, a replica with a new disk can automatically recover without operator involvement. As long as a quorum of replicas are available, applications using the replicated log wont notice a thing! The new autorecovery feature enables replacing a single replica at a time, but it does not allow an operator to easily add or remove replicas, known as reconfiguration. You can follow for the latest on this future work.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: email-templates.md

This is a collection of email templates to handle various situations the security team encounters. ``` Subject: Upcoming security release of etcd $VERSION To: etcd-dev@googlegroups.com Cc: etcd-maintainers@googlegroups.com Hello etcd Community, The etcd Product Security Committee and maintainers would like to announce the forthcoming release of etcd $VERSION. This release will be made available on the $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). This release will fix $NUMDEFECTS security defect(s). The highest rated security defect is considered $SEVERITY severity. No further details or patches will be made available in advance of the release. Thanks Thanks to $REPORTER, $DEVELOPERS, and the $RELEASELEADS for the coordination is making this release. Thanks, $PERSON on behalf of the etcd Product Security Committee and maintainers ``` ``` Subject: Security release of etcd $VERSION is now available To: etcd-dev@googlegroups.com Cc: etcd-maintainers@googlegroups.com Hello etcd Community, The Product Security Committee and maintainers would like to announce the availability of etcd $VERSION. This addresses the following CVE(s): CVE-YEAR-ABCDEF (CVSS score $CVSS): $CVESUMMARY ... Upgrading to $VERSION is encouraged to fix these issues. Am I vulnerable? Run `etcd --version` and if it indicates a base version of $OLDVERSION or older that means it is a vulnerable version. <!-- Provide details on features, extensions, configuration that make it likely that a system is vulnerable in practice. --> How do I mitigate the vulnerability? <!-- [This is an optional section. Remove if there are no mitigations.] --> How do I upgrade? Follow the upgrade instructions at https://etcd.io/docs Vulnerability Details <!-- [For each CVE] --> *CVE-YEAR-ABCDEF* $CVESUMMARY This issue is filed as $CVE. We have rated it as ($CVSS, $SEVERITY) Thanks Thanks to $REPORTER, $DEVELOPERS, and the $RELEASELEADS for the coordination in making this release. Thanks, $PERSON on behalf of the etcd Product Security Committee and maintainers ```
Project: Gloo (Orchestration & Management / API Gateway)
File: deprecation.proto.sk.md

title: "deprecation.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: SOFARPC (Orchestration & Management / Remote Procedure Call)
File: README.md

](https://codecov.io/gh/sofastack/sofa-rpc) ](https://github.com/sofastack/sofa-rpc/releases) ](https://isitmaintained.com/project/sofastack/sofa-rpc "Percentage of issues still open") ](https://codeblitz.cloud.alipay.com/github/sofastack/sofa-rpc) SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. In Ant Financial, SOFARPC has been used for more than ten years and developing for five generations. SOFARPC is dedicated to simplify RPC calls between applications, and provide convenient, no code intrusion, stable, and efficient point-to-point remote service invocation solutions for applications. For user and developer easy to improve features, SOFARPC provides a wealth of model abstraction and extensible interfaces, including filter, routing, load balancing, and so on. At the same time, it provides a rich MicroService governance solution around the SOFARPC framework and its surrounding components. No code intrusion, high-performance remote service call Supports multiple service routing and load balancing policies Supports multiple service registries Supports multiple protocols Supports multiple invoke type, such as synchronous, oneway, callback, generalized and more. Support cluster failover, service warm-up, automatic fault tolerance High extensibility for easy to improve features as needed SOFABoot projects for SOFARPC, include starter and samples. Build-time requirement: JDK 8 or above and Maven 3.2.5 or above. Runtime requirement: JDK 8 or above. DingTalk Group <img alt="DingTalk" src="https://gw.alipayobjects.com/mdn/sofastack/afts/img/A*1DklS7SZFNMAAAAAAAAAAAAAARQnAQ" height="250" width="250"> SOFARPC is licensed under the , and SOFARPC uses some third-party components, you can view their open source license here .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-08-15-mesos-1-3-1-released.md

layout: post title: Apache Mesos 1.3.1 Released permalink: /blog/mesos-1-3-1-released/ published: true post_author: display_name: Michael Park gravatar: 2ab9cab3a7cf782261c583c1f48a81b0 twitter: mcypark tags: Release The latest Mesos 1.3.x release, 1.3.1, is now available for . This release includes important bug fixes and improvements on top of 1.3.0. It is recommended to use this version if you are considering using Mesos 1.3. More specifically, this release includes the following: - The filesystem/linux isolator does not set the permissions of the host_path. - Need to fix resource check in long-lived framework. - Allow isolators to inject task-specific environment variables. - Add an agent flag for executor re-registration timeout. - `WAITNESTEDCONTAINER` sometimes returns 404. - Allow "old" executors with half-open connections to be preserved during agent upgrade / restart. - Fix interference of external Boost installations when using some unbundled dependencies. - Libprocess can crash on malformed request paths for libprocess messages. - The agent can crash when an unknown executor tries to register. - Default environment variables defined in Docker image are not available in Mesos containerizer. - Mesos fails to exec a custom executor when no shell is used. - Java HTTP adapter crashes JVM when leading master disconnects. - Persistent volume might not be mounted if there is a sandbox volume whose source is the same as the target of the persistent volume. - Agent failed to recover due to mount namespace leakage in Docker 1.12/1.13. - `LIBPROCESS_IP` isn't passed on to the fetcher. - Sandbox_path volume does not have ownership set correctly. Full release notes are available in the release Rolling upgrades from a Mesos 1.3.0 cluster to Mesos 1.3.1 are straightforward. Please refer to the [upgrade guide](http://mesos.apache.org/documentation/latest/upgrades/) for detailed information on upgrading to Mesos 1.3.1 from 1.2.x, 1.1.x or 1.0.x. Please try out this release and let us know what you think. If you run into any issues, let us know on the . Thanks to the 52 contributors who made 1.3.1 possible: Aaron Wood, Adam B, Alexander Rojas, Alexander Rukletsov, Anand Mazumdar, Andrei Budnik, Andrew Schwartzmeyer, Anindya Sinha, Armand Grillet, Avinash sridharan, Benjamin Bannier, Benjamin Hindman, Benjamin Mahler, Benno Evers, Chun-Hung Hsiao, Conrad Kleinespel, Dmitry Zhuk, Eric Chung, Gastn Kleiman, Gilbert Song, Greg Mann, Haosdent Huang, Jacob Janco, James Peach, Jan Schlicht, Jay Guo, Jeff Coffler, Jiang Yan Xu, Jie Yu, John Kordich, Joseph Wu, Kapil Arya, Kevin Klues, Li Li, Mao Geng, Megha Sharma, Michael Park, Neil Conway, Olivier Sallou, Qian Zhang, Quinn Leng, Shingo Kitayama, Silas Snider, Till Toenshoff, Tim Hansen, TobiLG, Vinod Kone, Zhitao Li, Zhongbo Tian, haosdent huang, hardy.jung, huangwenpeng
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: 'heimanba' Describe the bug A clear and concise description of what the bug is. Screenshots If applicable, add screenshots to help explain your problem. Desktop (please complete the following information): OS: [e.g. iOS] Version [e.g. 22] Additional context Add any other context about the problem here.