cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: kafka.md

title: Apache Kafka keywords: Apache APISIX API Gateway PubSub Kafka description: This document contains information about the Apache APISIX kafka pubsub scenario. <!-- --> Connecting to Apache Kafka in Apache APISIX is very simple. Currently, we provide a simpler way to integrate by combining two APIs, ListOffsets and Fetch, to quickly implement the ability to pull Kafka messages. Still, they do not support Apache Kafka's consumer group feature for now and cannot be managed for offsets by Apache Kafka. Offsets need to be managed manually They can be stored by a custom backend service or obtained via the list_offset command before starting to fetch the message, which can use timestamp to get the starting offset, or to get the initial and end offsets. Unsupported batch data acquisition A single instruction can only obtain the data of a Topic Partition, does not support batch data acquisition through a single instruction First, it is necessary to compile the as a language-specific SDK using the `protoc`, which provides the command and response definitions to connect to Kafka via APISIX using the WebSocket. The `sequence` field in the protocol is used to associate the request with the response, they will correspond one to one, the client can manage it in the way they want, APISIX will not modify it, only pass it back to the client through the response body. The following commands are currently used by Apache Kafka connect CmdKafkaFetch CmdKafkaListOffset The `timestamp` field in the `CmdKafkaListOffset` command supports the following value: `unix timestamp`: Offset of the first message after the specified timestamp `-1`Offset of the last message of the current Partition `-2`Offset of the first message of current Partition For more information, see Possible response body: When an error occurs, `ErrorResp` will be returned, which includes the error string; the rest of the response will be returned after the execution of the particular command. ErrorResp KafkaFetchResp KafkaListOffsetResp Create a route, set the upstream `scheme` field to `kafka`, and configure `nodes` to be the address of the Kafka broker. ```shell curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/kafka' \ -H 'X-API-KEY: <api-key>' \ -H 'Content-Type: application/json' \ -d '{ "uri": "/kafka", "upstream": { "nodes": { "kafka-server1:9092": 1, "kafka-server2:9092": 1, "kafka-server3:9092": 1 }, "type": "none", "scheme": "kafka" } }' ``` After configuring the route, you can use this feature. Simply turn on the `kafka-proxy` plugin on the created route and enable the Kafka TLS handshake and SASL authentication through the configuration, which can be found in the . ```shell curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/kafka' \ -H 'X-API-KEY: <api-key>' \ -H 'Content-Type: application/json' \ -d '{ "uri": "/kafka", "plugins": { "kafka-proxy": { "sasl": { "username": "user", "password": "pwd" } } }, "upstream": { "nodes": { "kafka-server1:9092": 1, "kafka-server2:9092": 1, "kafka-server3:9092": 1 }, "type": "none", "scheme": "kafka", "tls": { "verify": true } } }' ```
Project: Contour (Orchestration & Management / Service Proxy)
File: tls-delegation.md

In order to support wildcard certificates, TLS certificates for a `*.somedomain.com`, which are stored in a namespace controlled by the cluster administrator, Contour supports a facility known as TLS Certificate Delegation. This facility allows the owner of a TLS certificate to delegate, for the purposes of referencing the TLS certificate, permission to Contour to read the Secret object from another namespace. Delegation works for both HTTPProxy and Ingress v1beta1 resources (however it does not work with Ingress v1). TLS Certificate Delegation is not currently supported on Ingress v1 resources due to changes in the spec that make this impossible. See for details. The resource defines a set of `delegations` in the `spec`. Each delegation references a `secretName` from the namespace where the `TLSCertificateDelegation` is created as well as describing a set of `targetNamespaces` in which the certificate can be referenced. If all namespaces should be able to reference the secret, then set `"*"` as the value of `targetNamespaces` (see example below). ```yaml apiVersion: projectcontour.io/v1 kind: TLSCertificateDelegation metadata: name: example-com-wildcard namespace: www-admin spec: delegations: secretName: example-com-wildcard targetNamespaces: example-com secretName: another-com-wildcard targetNamespaces: "*" apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: www namespace: example-com spec: virtualhost: fqdn: foo2.bar.com tls: secretName: www-admin/example-com-wildcard routes: services: name: s1 port: 80 ``` In this example, the permission for Contour to reference the Secret `example-com-wildcard` in the `admin` namespace has been delegated to HTTPProxy objects in the `example-com` namespace. Also, the permission for Contour to reference the Secret `another-com-wildcard` from all namespaces has been delegated to all HTTPProxy objects in the cluster.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-02-06-mesos-1-0-3-released.md

layout: post title: Apache Mesos 1.0.3 Released permalink: /blog/mesos-1-0-3-released/ published: true post_author: display_name: Vinod Kone twitter: vinodkone tags: Release The latest Mesos release, 1.0.3, is now available for . This release includes some important bug fixes and improvements on top of 1.0.0. It is highly recommended to use this version if you are considering using Mesos 1.0. More specifically, this release includes the following fixes and improvements: Unable to launch containers on CNI networks on CoreOS Frameworks may RESERVE for an arbitrary role. SSL downgrade path will CHECK-fail when using both temporary and persistent sockets Always re-link with scheduler during re-registration. Segfault when the executor sets an invalid UUID when sending a status update. Full release notes are available in the release Rolling upgrades from a Mesos 1.0.0 cluster to Mesos 1.0.3 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.0.3. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the . Thanks to the 9 contributors who made 1.0.3 possible Aaron Wood, Alexander Rukletsov, Avinash sridharan, Benjamin Bannier, Gastn Kleiman, Joseph Wu, Michael Park,Neil Conway, Vinod Kone
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Welcome! We are glad that you want to contribute to our project! Below you can find some options Our is the place to ask questions and help them to solve. If you are interested in contribute and have knowledge about virtualization, cloud, automation, etc. You can help us by answering questions from other users. Create an account if you don't have one, and start checking the forum. You can report a bug by opening a new issue . Please, make sure that you follow the template for bug reports and all sections have been completed: Version of OpenNebula Component Brief description Expected behavior How to reproduce You can find more information on our Wiki page: You can request a new feature by opening an issue . Please, make sure that you follow the template for new features and all sections have been completed: Brief description of the new functionality How are you going to use this new feature? Why do you need it? Describe any changes to current interfaces including Sunstone, CLI and/or API More information can be found on the wiki: You can participate by developing a new addon, or contributing to the existing addons we have on . Please check our on the wiki page. We strongly suggest to use the in order to ask for help, or to make your addon official. QA & Testing of a cloud management tool is particularly challenging as it requires validating the integration of multiple software components, from different hypervisors and storage architectures to operating systems and DB backends. As part of OpenNebula QA we perform the following activities: Development and maintenance of a testing framework to exercise all the OpenNebula components Maintenance of a testing infrastructure with multiple hypervisors and storage configurations Regular test execution and circling feedback through to the development process by filing issues Manage up-to-date set of test cases for wide functionality scenario coverage. Automation of testing and bug identification process You can find how to help us on the We welcome contributions also to translate our platform to different languages. We use Transifex to localize the project, so you'll need to create an account (if you don't have one), or use your existing Transifex credential. Please check the status of the locale on the The OpenNebula Vulnerability Management Team (VMT) is responsible for coordinating the process of evaluating, fixing and disclosing those security vulnerabilities reported by members of the OpenNebula Community. Members of the VMT are all part of the Engineering Team at , the company that manages and coordinates the development of the OpenNebula project. Membership of this team is intentionally limited to a small number of people. Please check our Wiki to know more about how to
Project: BFE (Orchestration & Management / Service Proxy)
File: performance.md

BFE has built-in CPU profile interfaces, which can be used in conjunction with the FlameGraph tool to locate and analyze performance problems. Set monitor port in the BFE core configuration file (conf/bfe.conf). ```ini [Server] MonitorPort = 8421 ``` FlameGragh ```bash $ git clone https://github.com/brendangregg/FlameGraph ``` Which contains stackcollpase-go.pl and flamegraph.pl tools Get performance sampling data ```bash $ go tool pprof -seconds=60 -raw -output=bfe.pprof http://<addr>:<port>/debug/pprof/profile ``` Note: seconds=60 means capturing 60 seconds of stack samples Transform and draw FlameGraph ```bash $ ./stackcollpase-go.pl bfe.pporf > bfe.flame $ ./flamegraph.pl bfe.flame > bfe.svg ``` Open bfe.svg in browser
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: PROFILING.md

Knative Serving allows for collecting runtime profiling data expected by the pprof visualization tool. Profiling data is available for the autoscaler, activator, controller, webhook and for the queue-proxy container which is injected into the user application pod. When enabled Knative serves profiling data on the default port `8008` through a web server. Edit the `config-observability` ConfigMap and add `profiling.enable = "true"`: ```shell kubectl edit configmap config-observability -n knative-serving ``` Use port-forwarding to get access to Knative Serving pods. For example, activator: ```shell ACTIVATOR_POD=$(kubectl -n knative-serving get pods -l app=activator -o custom-columns=:metadata.name --no-headers) kubectl port-forward -n knative-serving $ACTIVATOR_POD 8008:8008 ``` View all available profiles at http://localhost:8008/debug/pprof/ through a web browser or request specific profiling data using one of the commands below: ```shell go tool pprof http://localhost:8008/debug/pprof/heap ``` ```shell go tool pprof http://localhost:8008/debug/pprof/profile?seconds=30 ``` ```shell go tool pprof http://localhost:8008/debug/pprof/block ``` ```shell wget http://localhost:8008/debug/pprof/trace\?seconds\=5 && go tool trace trace\?seconds\=5 ``` ```shell go tool pprof http://localhost:8008/debug/pprof/allocs ``` ```shell go tool pprof http://localhost:8008/debug/pprof/mutex ``` ```shell go tool pprof http://localhost:8008/debug/pprof/goroutine ``` ```shell go tool pprof http://localhost:8008/debug/pprof/threadcreate ``` ```shell curl http://localhost:8008/debug/pprof/cmdline --output - ``` More information on profiling Go applications in this
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: MSBUILD.md

<!-- 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. --> Microsoft Visual Studio 2019. CMake >= 3.12 (should be supplied as part of VS2019 installation). Clone , and follow build instructions in `README.md`. Install Boost from . Add `C:\<path to>\boost168_0\lib64-msvc-14.1` to PATH environment variable. cd lang\c++ cmake -G "Visual Studio 16 2019" -DBOOSTROOT=C:\<path to>\boost1680 -DBOOSTINCLUDEDIR=c:\<path to>\boost1680\boost -DBOOSTLIBRARYDIR=c:\<path to>\boost1680\lib64-msvc-14.1 -DSNAPPYINCLUDEDIR=C:\<path to>\snappy-visual-cpp -DSNAPPY_LIBRARIES=C:\<path to>\snappy-visual-cpp\x64\Release\snappy.lib .. msbuild Avro-cpp.sln /p:Configuration=Release /p:Platform=x64
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: DEPENDENCY.md

This policy describes how K8gb maintainers consume third-party packages. This policy applies to all K8gb maintainers and all third-party packages used in the K8gb project. K8gb maintainers must follow these guidelines when consuming third-party packages: Only use third-party packages that are necessary for the functionality of K8gb. Use the latest version of all third-party packages whenever possible. Avoid using third-party packages that are known to have security vulnerabilities. Pin all third-party packages to specific versions in the K8gb codebase. Use a dependency management tool, such as Go modules, to manage third-party dependencies. Dependencies must pass all automated tests before being merged into the K8gb codebase. When adding a new third-party package to K8gb, maintainers must follow these steps: Evaluate the need for the package. Is it necessary for the functionality of K8gb? Research the package. Is it well-maintained? Does it have a good reputation? Choose a version of the package. Use the latest version whenever possible. Pin the package to the specific version in the K8gb codebase. Update the K8gb documentation to reflect the new dependency. When a third-party package is discontinued, the K8gb maintainers must fensure to replace the package with a suitable alternative. This policy is enforced by the K8gb maintainers. Maintainers are expected to review each other's code changes to ensure that they comply with this policy. Exceptions to this policy may be granted by the K8gb project lead on a case-by-case basis. This policy was adapted from the &
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2019-07-29-mesos-1-8-1-released.md

layout: post title: Apache Mesos 1.8.1 Released permalink: /blog/mesos-1-8-1-released/ published: true post_author: display_name: Benno Evers tags: Release The latest Mesos 1.8.x release, 1.8.1, is now available for . This release includes important bug fixes and improvements on top of 1.8.0. It is recommended to use this version if you are considering using Mesos 1.8. More specifically, this release includes the following: - Check failure on `StorageLocalResourceProviderProcess::applyCreateDisk`. - `Filters.refuse_seconds` declines resources not in offers. - Executors cannot reconnect with agents using TLS1.3 - Agent V1 `GET_STATE` response may report a complete executor's tasks as non-terminal after a graceful agent shutdown. - /processes endpoint can hang. - `UPDATERESOURCEPROVIDER_CONFIG` agent call returns 404 ambiguously. - Random sorter fails to clear removed clients. - Race between two `REMOVE_QUOTA` calls crashes the master. - Memory leak caused by an infinite chain of futures in `UriDiskProfileAdaptor`. - Master should not report disconnected resource providers. - Slow memory growth in master due to deferred deletion of offer filters and timers. - REVIVE call with specified role(s) clears filters for all roles of a framework. - Simultaneous adding/removal of a role from framework's roles and its suppressed roles crashes the master. - Remove the duplicate pid check in Docker containerizer - Log required quota headroom and available quota headroom in the allocator. - Log slow SSL (TLS) peer reverse DNS lookup. Full release notes are available in the release Rolling upgrades from a Mesos 1.8.0 cluster to Mesos 1.8.1 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.8.1 from 1.7.x, 1.6.x, or 1.5.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 9 contributors who made 1.8.1 possible: Andrei Budnik, Andrei Sekretenko, Benjamin Mahler, Chun-Hung Hsiao, Gilbert Song, Joseph Wu, Meng Zhu, Qian Zhang, Stphane Cottin
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: azure-event-hubs.md

id: azure-event-hubs title: Azure Event Hubs sidebar_label: Azure Event Hubs is providing Kafka protocol and thus RIG can connect to it. However, it requires SASL and encrypted connection which might be a bit tricky to setup. This example should help to configure RIG properly. ```bash KAFKASOURCETOPICS="rig" \ PROXYKAFKARESPONSE_TOPICS="rig" \ KAFKA_BROKERS="<name>.servicebus.windows.net:9093" \ KAFKASSLENABLED=1 \ KAFKASSLCA_CERTFILE=priv/ca.crt.pem \ KAFKASSLCERTFILE= \ KAFKASSLKEYFILE= \ KAFKA_SASL="plain:\$ConnectionString:Endpoint=..." ``` Important notes: enable SSL enable `CA_CERTFILE` - you can use the `priv/ca.crt.pem` for testing, however should use your own in production disable `CERTFILE` and `KEYFILE` note the `\` in the SASL username, otherwise it's stripped
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: Feature_request.md

name: Feature request about: Suggest an idea for this project Please describe your use case / problem. A clear and concise description of your use case / problem. The "why" is really valuable to us. For example, "I have a set of services whose clients have long-lived connections." 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 about the feature request here.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: search_test.md

| Test Case | E2E Describe Text | Comments | |-|-|-| | Test search Service when there is no ResourceRegistry | [Service] should be not searchable | | | Test search a searchable deployment | [member1 deployments] should be searchable | | | Test search a not searchable deployment | [member2 deployments] should be not searchable | | | Test search a searchable namespace | [member1 deployments namespace] should be searchable | | | Test search a not searchable namespace | [member2 deployments namespace] should be not searchable | | | Test search node member1 | [member1 nodes] should be searchable | | | Test search node member2 | [member2 nodes] should be searchable | | | Test search member1's pods | [member1 pods] should be searchable | | | Test search member2's pods | [member2 pods] should be searchable | | | Test search clusterRole | [clusterrole] should be searchable | | | Test search a not searchable clusterRoleBinding | [clusterrolebinding] should not be searchable | | | Test search a clusterRoleBinding | [clusterrolebinding] should be searchable | | | Test search a daemonSet | [daemonset] should be searchable | | | Test search a not searchable daemonSet | [daemonset] should not be searchable | | | Test search pods/nodes when create/update/delete resourceRegistry | create, update, delete resourceRegistry | | | Test get node | could get node | | | Test list nodes | could list nodes | | | Test get chunk list nodes | could chunk list nodes | | | Test list and watch nodes | could list & watch nodes | | | Test patch nodes | could path nodes | | | Test update node | could update node | | | Test Case | E2E Describe Text | Comments | |||-| | Test search deployment after join the cluster | [member clusters joined] could reconcile ResourceRegistry | | | Test search deployment after manage and unmanage the clusters | [member clusters updated, deleted label] could reconcile ResourceRegistry | |
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-portal-theme.md

You will be able to define your theme and observe live preview. The panel to the left of the preview allows you to define your design preferences. FULLSCREEN button makes it easier to edit if you have several screens, the preview opens in a new window. `Only if Portal URL is configured in Portal settings.` RESET action allows you to reset the theme since the last backup. SAVE button saves your theme. ENABLED switch makes the theme active at portal level. RESTORE TO DEFAULT THEME action overwrites your modifications with the theme that we provide by default. Images Add your logos. Optional logo is used for the home page and the footer but it is possible to use only the main logo with "Use default logo" link. Add your Homepage background image. Colors Define your primary, neutral, font and skeleton colors. Fonts Choose your font family. Choose your font size. Small are default. If you want more customization, you can define the graphic properties that we expose for each component. Each component uses its own properties, but when possible, we group the properties into common variables (see: simple usage) For the component colors, if you mouse over the color bubble, you can understand what is the common color used. For others properties, if common property is used, you can see this on the placeholder iof field.
Project: OpenResty (Orchestration & Management / Service Proxy)
File: ISSUE_TEMPLATE.md

This place is for bug reports and development discussions only. For general questions and discussions, please join the openresty-en mailing list instead: https://groups.google.com/group/openresty-en. If you want to use Chinese, please join the openresty (Chinese) mailing list instead: https://groups.google.com/group/openresty. Do not use Chinese in this place. Before you open a new issue, please search the internet and make sure it is not duplicate. Ensure you have provided the following details while reporting a problem: [ ] The exact version of the related software, including but not limited to the OpenResty version (if any), the NGINX core version, the `ngx_lua` module version(via `openresty -V` or `nginx -V`), and your operating system version(via `uname -a`). [ ] A minimal and standalone test case that others can easily run on their side and reproduce the issue you are seeing. [ ] Do not simply say "something is broken" or "something does not work". Always provide as much details as possible. Always describe the symptoms and your expected results. You can (temporarily) enable the nginx debugging logs to see the internal workings of NGINX in your nginx''s `error.log` file. See http://nginx.org/en/docs/debugging_log.html The same instructions apply equally well to OpenResty. If you are seeing crashes, please provide the full backtrace for the crash. See https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/#core-dump for more details. Thanks for your cooperation.