cwielenb/CNCF-Dataset huggingface dataset:
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: health-checking.md

GRPC Health Checking Protocol ================================ Health checks are used to probe whether the server is able to handle rpcs. The client-to-server health checking can happen from point to point or via some control system. A server may choose to reply unhealthy because it is not ready to take requests, it is shutting down or some other reason. The client can act accordingly if the response is not received within some time window or the response says unhealthy in it. A GRPC service is used as the health checking mechanism for both simple client-to-server scenario and other control systems such as load-balancing. Being a high level service provides some benefits. Firstly, since it is a GRPC service itself, doing a health check is in the same format as a normal rpc. Secondly, it has rich semantics such as per-service health status. Thirdly, as a GRPC service, it is able reuse all the existing billing, quota infrastructure, etc, and thus the server has full control over the access of the health checking service. The server should export a service defined in the following proto: ``` syntax = "proto3"; package grpc.health.v1; message HealthCheckRequest { string service = 1; } message HealthCheckResponse { enum ServingStatus { UNKNOWN = 0; SERVING = 1; NOT_SERVING = 2; SERVICE_UNKNOWN = 3; // Used only by the Watch method. } ServingStatus status = 1; } service Health { rpc Check(HealthCheckRequest) returns (HealthCheckResponse); rpc Watch(HealthCheckRequest) returns (stream HealthCheckResponse); } ``` A client can query the servers health status by calling the `Check` method, and a deadline should be set on the rpc. The client can optionally set the service name it wants to query for health status. The server should register all the services manually and set the individual status, including an empty service name and its status. For each request received, if the service name can be found in the registry, a response must be sent back with an `OK` status and the status field should be set to `SERVING` or `NOT_SERVING` accordingly. If the service name is not registered, the server returns a `NOT_FOUND` GRPC status. The server should use an empty string as the key for server's overall health status, so that a client not interested in a specific service can query the server's status with an empty request. The server can just do exact matching of the service name without support of any kind of wildcard matching. However, the service owner has the freedom to implement more complicated matching semantics that both the client and server agree upon. A client can declare the server as unhealthy if the rpc is not finished after some amount of time. The client should be able to handle the case where server does not have the Health service. A client can call the `Watch` method to perform a streaming health-check. The server will immediately send back a message indicating the current serving status. It will then subsequently send a new message whenever the service's serving status changes.
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: gitflow.md

Each project has it's own way of doing things. The following simple rules capture the OpenNebula dev team gitflow. Comments are welcome (contact@opennebula.io)! OpenNebula branches =================== master: latest development version (stable... to some extent) one-X.Y: stable version (only bug fixing). No etc file changes. No migrator changes feature-Z or bug-Z: to develop Z New features are committed/merged to master Bug fixing are committed/merged to master and cherry-picked to the currently active (ie, latest release) one-X.Y Documentation ============= master: Docs for latest development one-X.Y: Docs for stable, automatically published one-X.Y-maintenance: Docs for next stable release (one-X.Y.+1) New features are documented on master and added to the What's New guide Bugs are documented on master and cherry-picked one-X.Y-maintenance. Also, added to one-X.Y.maintenance Resolved Issues X.Y+1 Documentation bugs are committed to master and cherry-picked to one-X.Y (no need to port it to one-X.Y-maintenance)
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: TROUBLESHOOTING.md

This guide is for troubleshooting gRPC implementations based on C core library (sources for most of them are living in the `grpc/grpc` repository). Extra logging can be very useful for diagnosing problems. All gRPC implementations based on C core library support the `GRPCVERBOSITY` and `GRPCTRACE` environment variables that can be used to increase the amount of information that gets printed to stderr. `GRPC_VERBOSITY` is used to set the minimum level of log messages printed by gRPC (supported values are `DEBUG`, `INFO` and `ERROR`). If this environment variable is unset, only `ERROR` logs will be printed. `GRPC_TRACE` can be used to enable extra logging for some internal gRPC components. Enabling the right traces can be invaluable for diagnosing for what is going wrong when things aren't working as intended. Possible values for `GRPC_TRACE` are listed in . Multiple traces can be enabled at once (use comma as separator). ``` GRPCVERBOSITY=debug ./helloworldapplicationusinggrpc ``` ``` GRPCVERBOSITY=info GRPCTRACE=api ./helloworldapplicationusing_grpc ``` ``` GRPCVERBOSITY=debug GRPCTRACE=tcp,http,api ./helloworldapplicationusing_grpc ``` Known limitations: `GPRC_TRACE=tcp` is currently not implemented for Windows (you won't see any tcp traces). Please note that the `GRPC_TRACE` environment variable has nothing to do with gRPC's "tracing" feature (= tracing RPCs in microservice environment to gain insight about how requests are processed by deployment), it is merely used to enable printing of extra logs.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: moving-to-c++.md

Originally written by ctiller, markdroth, and vjpai in October 2017 Revised by veblush in October 2019 gRPC core was originally written in C89 for several reasons (possibility of kernel integration, ease of wrapping, compiler support, etc). Over time, this was changed to C99 as all relevant compilers in active use came to support C99 effectively. gRPC started allowing to use C++ with a couple of exceptions not to have C++ library linked such as `libstdc++.so`. (For more detail, see the ) Finally gRPC became ready to use full C++11 with the standard library by the . Throughout all of these transitions, the public header files are committed to remain in C89. The goal now is to make the gRPC core implementation true idiomatic C++ compatible with . Most of features available in C++11 are allowed to use but there are some exceptions because gRPC should support old systems. Should be built with gcc 4.8, clang 3.3, and Visual C++ 2015. Should be run on Linux system with libstdc++ 6.0.9 to support . This would limit us not to use modern C++11 standard library such as `filesystem`. You can easily see whether PR is free from this issue by checking the result of `Artifact Build Linux` test. `thread_local` is not allowed to use on Apple's products because their old OSes (e.g. ios < 9.0) don't support `threadlocal`. Please use `GPRTLS_DECL` instead. gRPC main libraries (grpc, grpc+++, and plugins) cannot use following C++ libraries: (Test and example codes are relatively free from this constraints) `<thread>`. Use `grpc_core::Thread`. `<conditionvariable>`. Use `grpccore::CondVar`. `<mutex>`. Use `grpccore::Mutex`, `grpccore::MutexLock`, and `grpc_core::ReleasableMutexLock`. `<future>` `<ratio>` `<system_error>` `<filesystem>` What should be the phases of getting code converted to idiomatic C++ Opportunistically do leaf code that other parts don't depend on Spend a little time deciding how to do non-leaf stuff that isn't central or polymorphic (e.g., timer, call combiner) For big central or polymorphic interfaces, actually do an API review (for things like transport, filter API, endpoint, closure, exec_ctx, ...) . Core internal changes don't need a gRFC, but core surface changes do But an API review should include at least a PR with the header change and tests to use it before it gets used more broadly iomgr polling for POSIX is a gray area whether it's a leaf or central What is the schedule? In Q4 2017, if some stuff happens opportunistically, great; otherwise \\\()\/ More updates as team time becomes available and committed to this project For C++ structs, switch to `using` when possible (e.g., Slice, ByteBuffer, ...) The C++ API implementation might directly start using `grpctransportstreamopbatch` rather than the core surface `grpc_op`.
Project: Traefik (Orchestration & Management / API Gateway)
File: retry.md

title: "Traefik HTTP Retry Documentation" description: "Configure Traefik Proxy's HTTP Retry middleware, so you can retry requests to a backend server until it succeeds. Read the technical documentation." Retrying until it Succeeds {: .subtitle } <!-- TODO: add schema --> The Retry middleware reissues requests a given number of times to a backend server if that server does not reply. As soon as the server answers, the middleware stops retrying, regardless of the response status. The Retry middleware has an optional configuration to enable an exponential backoff. ```yaml tab="Docker & Swarm" labels: "traefik.http.middlewares.test-retry.retry.attempts=4" "traefik.http.middlewares.test-retry.retry.initialinterval=100ms" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: test-retry spec: retry: attempts: 4 initialInterval: 100ms ``` ```yaml tab="Consul Catalog" "traefik.http.middlewares.test-retry.retry.attempts=4" "traefik.http.middlewares.test-retry.retry.initialinterval=100ms" ``` ```yaml tab="File (YAML)" http: middlewares: test-retry: retry: attempts: 4 initialInterval: 100ms ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.test-retry.retry] attempts = 4 initialInterval = "100ms" ``` mandatory The `attempts` option defines how many times the request should be retried. The `initialInterval` option defines the first wait time in the exponential backoff series. The maximum interval is calculated as twice the `initialInterval`. If unspecified, requests will be retried immediately. The value of initialInterval should be provided in seconds or as a valid duration format, see .
Project: APISIX (Orchestration & Management / API Gateway)
File: authz-casdoor.md

title: authz-casdoor keywords: Apache APISIX API Gateway Plugin Authz Casdoor authz-casdoor description: This document contains information about the Apache APISIX authz-casdoor Plugin. <!-- --> The `authz-casdoor` Plugin can be used to add centralized authentication with . | Name | Type | Required | Description | ||--|-|-| | endpoint_addr | string | True | URL of Casdoor. | | client_id | string | True | Client ID in Casdoor. | | client_secret | string | True | Client secret in Casdoor. | | callback_url | string | True | Callback URL used to receive state and code. | NOTE: `encryptfields = {"clientsecret"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See . :::info IMPORTANT `endpointaddr` and `callbackurl` should not end with '/'. ::: :::info IMPORTANT The `callback_url` must belong to the URI of your Route. See the code snippet below for an example configuration. ::: You can enable the Plugin on a specific Route as shown below: ```shell curl "http://127.0.0.1:9180/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' { "methods": ["GET"], "uri": "/anything/*", "plugins": { "authz-casdoor": { "endpoint_addr":"http://localhost:8000", "callback_url":"http://localhost:9080/anything/callback", "client_id":"7ceb9b7fda4a9061ec1c", "client_secret":"3416238e1edf915eac08b8fe345b2b95cdba7e04" } }, "upstream": { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } } }' ``` Once you have enabled the Plugin, a new user visiting this Route would first be processed by the `authz-casdoor` Plugin. They would be redirected to the login page of Casdoor. After successfully logging in, Casdoor will redirect this user to the `callback_url` with GET parameters `code` and `state` specified. The Plugin will also request for an access token and confirm whether the user is really logged in. This process is only done once and subsequent requests are left uninterrupted. Once this is done, the user is redirected to the original URL they wanted to visit. To remove the `authz-casdoor` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/anything/*", "plugins": {}, "upstream": { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } } }' ```
Project: Envoy (Orchestration & Management / Service Proxy)
File: Support.md

Envoy Mobile has a support rotation system to ensure that discussions, issues and pull requests are handled in a timely manner from someone who works on Envoy Mobile at Lyft. The current support maintainer's GitHub username is defined . Monitor GitHub Issues & Pull Requests:* Ensure that discussions on GitHub are engaged with in a prompt manner. Monitor Slack:* Engage with Slack discussions in the Envoy slack org (, ). Even though there is no concrete SLA, the support maintainer will make a reasonable effort to engage with discussions within 1 business day. Envoy Mobile is a project maintained by contributors from multiple companies, as highlighted in , but as the project grows we believe it will be helpful to have a point of contact within a company that has been using Envoy Mobile in production.
Project: Sentinel (Orchestration & Management / Service Proxy)
File: CONTRIBUTING.md

Welcome to Sentinel! This document is a guideline about how to contribute to Sentinel. If you find something incorrect or missing, please leave comments / suggestions. Please make sure to read and observe our . You should have JDK 17 or later installed in your system. add `~/.m2/toolchains.xml`, to define JDK and path. See . With JDK 17 as your default JDK, you could specify the JDK version to run test, i.e. Run test at JDK 8: ```bash mvn test -Dsurefire.jdk-toolchain-version=8 ``` We are always very happy to have contributions, whether for typo fix, bug fix or big new features. Please do not ever hesitate to ask a question or send a pull request. We strongly value documentation and integration with other projects. We are very glad to accept improvements for these aspects. We use the `master` branch as the development branch, which indicates that this is a unstable branch. Here are the workflow for contributors: Fork to your own Clone fork to local repository Create a new branch and work on it Keep your branch in sync Commit your changes (make sure your commit message concise) Push your commits to your forked repository Create a pull request Please follow . Please make sure the PR has a corresponding issue. After creating a PR, one or more reviewers will be assigned to the pull request. The reviewers will review the code. Before merging a PR, squash any fix review feedback, typo, merged, and rebased sorts of commits. The final commit message should be clear and concise. We use and for trackers. If you find a typo in document, find a bug in code, or want new features, or want to give suggestions, you can to report it. Please follow the guideline message in the issue template. If you want to contribute, please follow the and create a new pull request. If your PR contains large changes, e.g. component refactor or new components, please write detailed documents about its design and usage. Note that a single PR should not be too large. If heavy changes are required, it's better to separate the changes to a few individual PRs. All code should be well reviewed by one or more committers. Some principles: Readability: Important code should be well-documented. Comply with our code style. Elegance: New functions, classes or components should be well designed. Testability: Important code should be well-tested (high unit test coverage). If you have any questions or advice, please contact <sentinel@linux.alibaba.com>. Our Gitter room: .
Project: Consul (Orchestration & Management / Service Mesh)
File: CA-GENERATION.md

if tests like `TestAPIClientTLSOptions` (or any other test using certificates located in `./test/clientcerts` ) are failing because of expired certificates, use `./generate.sh` script to regenerate a new set of certificate. ``` bash cd test/client_certs/ rm -rf .pem .crt *.key && ./generate.sh ``` if tests like `TestAgent_ReloadConfigTLSConfigFailure` (or any other test using certificates located in `./test/ca` ) are failing because of expired certificates, use `./generate.sh` script to regenerate a new set of certificate. ``` bash cd test/ca/ rm -rf .pem .crt *.key && ./generate.sh ``` It also possible for the root CA to expire. In this case, use the instructions to regenerate root.cer and privkey.pem. Configure the cert as follows: ``` Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []:San Francisco Organization Name (eg, company) [Internet Widgits Pty Ltd]:HashiCorp Test Cert Organizational Unit Name (eg, section) []:Dev Common Name (e.g. server FQDN or YOUR name) []:test.internal Email Address []:test@internal.com ``` Ensure that you run `./test/ca/generate.sh` after recreating the root CA. if tests like `TestNewDialer_WithALPNWrapper` (or any other test using certificates located in `./test/hostname` ) are failing because of expired certificates, use `./generate.sh` script to regenerate a new set of certificate. ``` bash cd test/hostname/ rm -rf "[Bonnie|Betty|Bob|Alice].crt" *.key && ./generate.sh ``` It also possible for the root CA to expire. In this case, use the instructions to regenerate CertAuth.crt and privkey.pem. ```bash openssl req -newkey rsa:2048 -days 3650 -x509 -nodes -out CertAuth.crt ``` Configure the cert as follows: ``` Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []:San Francisco Organization Name (eg, company) [Internet Widgits Pty Ltd]:HashiCorp Test Cert Organizational Unit Name (eg, section) []:Test Common Name (e.g. server FQDN or YOUR name) []:CertAuth Email Address []:test@internal.com ```
Project: Gloo (Orchestration & Management / API Gateway)
File: endpoint-discovery.md

Envoy supports a variety of mechanisms to configure , the mechanism Envoy uses to resolve the members of the cluster. One of the more complex mechanisms is , where the xDS management server (Gloo Edge) provides the Endpoints for a given Cluster via an API. In Gloo Edge, Endpoints can be discovered dynamically via the Endpoint Discovery feature, and then served to the Envoy proxy via the EDS API. EDS runs in the component of Gloo Edge. We rely on an , meaning that when we write an Endpoint, it is just persisted in memory. In Memory clients signal updates to the emitter by two mechanisms: Any writes are signaled, meaning that endpoint updates will trigger the resources being sent on the channel, which will be picked up by the emitter, and produce a new snapshot. Create an , which is responsible for the following: Process an Performs a on each iteration Each Sync will perform a new and any existing loops will be cancelled An EDS Sync is responsible for the following: Initiate a watch on the Upstreams, which produces a Open a goroutine to Similar to , EDS supports multiple plugins for discovering endpoints. Each plugin is responsible for producing Gloo Endpoints, and sending them back to the EDS loop to be persisted in our in-memory API Snapshot. Then during translation, the Gloo Endpoints and Gloo Upstreams are converted into Envoy Endpoints and Envoy Clusters. EDS behavior can be configured globally, in the resource under `refresh_rate`. Each EDS plugin may have additional configuration options on the Settings resource as well.
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature Request about: Help us make Crossplane more useful labels: enhancement <!-- Thank you for helping to improve Crossplane! Please be sure to search for open issues before raising a new one. We use issues for bug reports and feature requests. Please find us at https://slack.crossplane.io for questions, support, and discussion. --> <!-- Please tell us a little about your use case - it's okay if it's hypothetical! Leading with this context helps frame the feature request so we can ensure we implement it sensibly. > <!-- Let us know how you think Crossplane could help with your use case. -->
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.0-released.md

title: "Avro 1.7.0" linkTitle: "Avro 1.7.0" date: 2012-06-11 <!-- 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.7.0 has been released!