cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: namespaces-ipc.md

title: Apache Mesos - IPC Namespace Isolator in Mesos Containerizer layout: documentation The IPC Namespace isolator can be used on Linux to place container in a distinct IPC namespace (for isolating System V IPC resources and POSIX message queue) and provide the container its own /dev/shm (for isolating POSIX shared memory). The benefits of this are: Visibility: Any IPC objects created in the container are private and cannot be seen by any other containers. Clean termination: When the container is destroyed, any IPC objects created in the container will be automatically removed. To enable the IPC namespace isolator, append `namespaces/ipc` to the `--isolation` flag when starting the agent. Note that `filesystem/linux` isolator is required for turning on IPC namespace isolator. Framework users can control the behavior of a container's IPC namespace and /dev/shm by setting the `ContainerInfo.linuxinfo.ipcmode` field: If set to `SHARE_PARENT`, the container will share the IPC namespace and /dev/shm with its parent. If the container is a top level container, it will share the IPC namespace and /dev/shm with the agent host, if the container is a nested container, it will share the IPC namespace and /dev/shm with its parent container. The implication is if a nested container wants to share the IPC namespace and /dev/shm with the agent host, its parent container has to do it first. If set to `PRIVATE`, the container will have its own IPC namespace and /dev/shm. If not set, for backward compatibility we will keep the previous behavior: Top level container will have its own IPC namespace and nested container will share the IPC namespace with its parent container. If the container does not have its own rootfs, it will share agent's /dev/shm, otherwise it will have its own /dev/shm. As a security measure, operators can disallow any containers to share the agent's IPC namespace and /dev/shm by setting the agent flag `--disallowsharingagentipcnamespace` to `true`. If this agent flag is set to `false` and the framework requests to launch a top level container to share the agent's IPC namespace and /dev/shm, the container launch will be rejected. Framework users can specify the size of a container's /dev/shm in MB by setting the `ContainerInfo.linuxinfo.shmsize` field, and operators can specify the default size of /dev/shm via the agent flag `--defaultcontainershm_size`. So if the `ContainerInfo.linuxinfo.shmsize` field is not set, the size of container's /dev/shm will be value of the `--defaultcontainershm_size` agent flag, if that flag is not set too, the size of the /dev/shm will be half of the agent host RAM which is the default behavior of Linux. The `ContainerInfo.linuxinfo.shmsize` field will be ignored for the container which shares its parent's /dev/shm. Please note that we only support setting the `ContainerInfo.linuxinfo.shmsize` field when the `ContainerInfo.linuxinfo.ipcmode` field is set to `PRIVATE`, otherwise the container launch will be rejected.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooe.solo.io.project.sk.md

title: "glooe.solo.io.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `glooe.solo.io.enterprise` Gloo is a high-performance, plugin-extendable, platform-agnostic API Gateway built on top of Envoy. Gloo is designed for microservice, monolithic, and serverless applications. By employing function-level routing, Gloo can completely decouple client APIs from upstream APIs at the routing level. Gloo serves as an abstraction layer between clients and upstream services, allowing front-end teams to work independently of teams developing the microservices their apps connect to. <!-- 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: 2013-12-16-niklas-nielsen-becomes-mesos-committer.md

layout: post title: Niklas Nielsen Becomes Newest Mesos Committer and PMC Member published: true post_author: display_name: Apache Mesos twitter: apachemesos tags: Announcement, PMC The Apache Mesos PMC has voted to make the project's newest committer and PMC member. Niklas is an engineer at Engineer at , and has a background in virtual machines, compilers and supercomputer tooling (distributed debuggers, profilers and so on). Nielsen has particular interests in performance, scalability and tooling to give insights in otherwise fairly complex setups. Welcome, Niklas!
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: namespaces-pid.md

title: Apache Mesos - Pid Namespace Isolator in Mesos Containerizer layout: documentation The `namespaces/pid` isolator can be used to isolate each container in a separate pid namespace with two main benefits: Visibility: Processes running in the container (executor and descendants) are unable to see or signal processes outside the namespace. Clean termination: Termination of the leading process in a pid namespace will result in the kernel terminating all other processes in the namespace. You can turn on this isolator by specifying the `--isolation` agent flag (i.e., `--isolation=namespaces/pid,...`). Note that `filesystem/linux` isolator is required for turning on pid namespace isolator. The Launcher will use (2) during destruction of a container in preference to the freezer cgroup, avoiding known kernel issues related to freezing cgroups under OOM conditions. `/proc` will be mounted for containers so tools such as `ps` will work correctly. To enable the PID Namespace isolator, append `namespaces/pid` to the `--isolation` flag when starting the agent. By default, each container will have its own PID namespace if this isolator is enabled. Framework users can allow a container to share pid namespace with its parent by setting the `ContainerInfo.linuxinfo.sharepid_namespace` field to `true`. If the container is a top level container, it will share the pid namespace with the agent. If the container is a nested container, it will share the pid namespace with its parent container. The container will have its own pid namespace if the `ContainerInfo.linuxinfo.sharepid_namespace` field is set to `false`. As a security measure, operators can disallow any container to share the agent's PID namespace by setting the agent flag `--disallowsharingagentpidnamespace` to `true`. If this agent flag is set as `true` and the framework requests to launch a top level container which shares its pid namespace with the agent, the container launch will be rejected.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you very much for contributing to Apache Avro - we are happy that you want to help us improve Avro. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed. Please understand that we do not do this to make contributions to Avro a hassle. In order to uphold a high standard of quality for code contributions, while at the same time managing a large number of contributions, we need contributors to prepare the contributions well, and give reviewers enough contextual information for the review. Please also understand that contributions that do not follow this guide will take longer to review and thus typically be picked up with lower priority by the community. Make sure that the pull request corresponds to a . Exceptions are made for typos in JavaDoc or documentation files, which need no JIRA issue. Name the pull request in the form "AVRO-XXXX: [component] Title of the pull request", where AVRO-XXXX should be replaced by the actual issue number. The component is optional, but can help identify the correct reviewers faster: either the language ("java", "python") or subsystem such as "build" or "doc" are good candidates. Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review. Make sure that the change passes the automated tests. You can or just the . Each pull request should address only one issue, not mix up code from multiple issues. Each commit in the pull request has a meaningful commit message (including the JIRA id) Every commit message references Jira issues in their subject lines. In addition, commits follow the guidelines from Subject is separated from body by a blank line Subject is limited to 50 characters (not including Jira issue reference) Subject does not end with a period Subject uses the imperative mood ("add", not "adding") Body wraps at 72 characters Body explains "what" and "why", not "how" --> (For example: This pull request improves file read performance by buffering data, fixing AVRO-XXXX.) (Please pick one of the following options) This change is a trivial rework / code cleanup without any test coverage. (or) This change is already covered by existing tests, such as (please describe tests). (or) This change added tests and can be verified as follows: (example:) Extended interop tests to verify consistent valid schema names between SDKs Added test that validates that Java throws an AvroRuntimeException on invalid binary data Manually verified the change by building the website and checking the new redirect Does this pull request introduce a new feature? (yes / no) If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: pull_request_template.md

Hint: In most cases this should match the changelog entry. Hint: Refer to closed/related issues here. Dear reviewer, I want you to gain knowledge - I think it's important for you to know about the change. check that the code works on your machine. suggest implementation-code design/structure/readability improvements. suggest test-code design/structure/readability improvements. suggest documentation improvements. suggest language/writing improvements. help to find bugs (described below!). Hint: remove anything you don't need and use `@` mentions for "assigning" tasks to different people Hint: if you find yourself adding the same "task" more than once, consider adding it to the . The goal is to improve not only the code in this PR but also our skills! The "rules": The review is considered "done" as soon as all reviewers have added their review, and all their comments have been addressed. For knowledge-sharing reviews, each reviewer should "approve" the PR after studying its content. After the approval, the merge is concluded by the developer. Have fun!
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_settings_ratelimit.md

title: "glooctl edit settings ratelimit" weight: 5 Configure rate limit settings (Enterprise) Let gloo know the location of the rate limit server. This is a Gloo Enterprise feature. ``` glooctl edit settings ratelimit [flags] ``` ``` --deny-on-failure On a failure to contact rate limit server, or on a timeout - deny the request (default is to allow) (default nil) -h, --help help for ratelimit --ratelimit-server-name string name of the ext rate limit upstream --ratelimit-server-namespace string namespace of the ext rate limit upstream --request-timeout duration The timeout of the request to the rate limit server. set to 0 to use the default. ``` ``` -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 --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - root command for settings - Add rate-limit descriptor settings (Enterprise)
Project: Traefik (Orchestration & Management / API Gateway)
File: stripprefix.md

title: "Traefik StripPrefix Documentation" description: "In Traefik Proxy's HTTP middleware, StripPrefix removes prefixes from paths before forwarding requests. Read the technical documentation." Removing Prefixes From the Path Before Forwarding the Request {: .subtitle } <!-- TODO: add schema --> Remove the specified prefixes from the URL path. ```yaml tab="Docker & Swarm" labels: "traefik.http.middlewares.test-stripprefix.stripprefix.prefixes=/foobar,/fiibar" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: test-stripprefix spec: stripPrefix: prefixes: /foobar /fiibar ``` ```yaml tab="Consul Catalog" "traefik.http.middlewares.test-stripprefix.stripprefix.prefixes=/foobar,/fiibar" ``` ```yaml tab="File (YAML)" http: middlewares: test-stripprefix: stripPrefix: prefixes: "/foobar" "/fiibar" ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.test-stripprefix.stripPrefix] prefixes = ["/foobar", "/fiibar"] ``` The StripPrefix middleware strips the matching path prefix and stores it in a `X-Forwarded-Prefix` header. !!! tip Use a `StripPrefix` middleware if your backend listens on the root path (`/`) but should be exposed on a specific prefix. The `prefixes` option defines the prefixes to strip from the request URL. For instance, `/products` also matches `/products/shoes` and `/products/shirts`. If your backend is serving assets (e.g., images or JavaScript files), it can use the `X-Forwarded-Prefix` header to properly construct relative URLs. Using the previous example, the backend should return `/products/shoes/image.png` (and not `/image.png`, which Traefik would likely not be able to associate with the same backend). Optional, Default=true !!! warning `forceSlash` option is deprecated and should not be used. The `forceSlash` option ensures the resulting stripped path is not the empty string, by replacing it with `/` when necessary. ??? info "Behavior examples" `forceSlash=true` | Path | Prefix to strip | Result | ||--|--| | `/` | `/` | `/` | | `/foo` | `/foo` | `/` | | `/foo/` | `/foo` | `/` | | `/foo/` | `/foo/` | `/` | | `/bar` | `/foo` | `/bar` | | `/foo/bar` | `/foo` | `/bar` | `forceSlash=false` | Path | Prefix to strip | Result | ||--|--| | `/` | `/` | empty | | `/foo` | `/foo` | empty | | `/foo/` | `/foo` | `/` | | `/foo/` | `/foo/` | empty | | `/bar` | `/foo` | `/bar` | | `/foo/bar` | `/foo` | `/bar` | ```yaml tab="Docker" labels: "traefik.http.middlewares.example.stripprefix.prefixes=/foobar" "traefik.http.middlewares.example.stripprefix.forceSlash=false" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: example spec: stripPrefix: prefixes: "/foobar" forceSlash: false ``` ```yaml tab="File (YAML)" http: middlewares: example: stripPrefix: prefixes: "/foobar" forceSlash: false ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.example.stripPrefix] prefixes = ["/foobar"] forceSlash = false ```
Project: KrakenD (Orchestration & Management / API Gateway)
File: CONFIG.md

The configuration file needs to be a `json` file. The viper parser supports other formats but they haven't been as tested as the recommended one. { "version": 3, "name": "My lovely gateway", "port": 8080, "timeout": "10s", "cache_ttl": "3600s", "host": [ "http://127.0.0.1:8080", "http://127.0.0.2:8000", "http://127.0.0.3:9000", "http://127.0.0.4" ], "endpoints": [{ "endpoint": "/users/{user}", "method": "GET", "backend": [{ "host": [ "http://127.0.0.3:9000", "http://127.0.0.4" ], "url_pattern": "/registered/{user}", "allow": [ "some", "what" ], "mapping": { "email": "personal_email" } }, { "host": [ "http://127.0.0.1:8080" ], "url_pattern": "/users/{user}/permissions", "deny": [ "spam2", "notwanted2" ] } ], "concurrent_calls": 2, "timeout": "1000s", "cache_ttl": 3600, "inputquerystrings": [ "page", "limit" ] }, { "endpoint": "/foo/bar", "method": "POST", "backend": [{ "host": [ "https://127.0.0.1:8081" ], "urlpattern": "/_debug/tupu" }], "concurrent_calls": 1, "timeout": "1000s", "cache_ttl": 3600 }, { "endpoint": "/github", "method": "GET", "backend": [{ "host": [ "https://api.github.com" ], "url_pattern": "/", "allow": [ "authorizations_url", "codesearchurl" ] }], "concurrent_calls": 2, "timeout": "1000s", "cache_ttl": 3600 }, { "endpoint": "/combination/{id}/{supu}", "method": "GET", "backend": [{ "group": "first_post", "host": [ "https://jsonplaceholder.typicode.com" ], "url_pattern": "/posts/{id}?supu={supu}", "deny": [ "userId" ] }, { "host": [ "https://jsonplaceholder.typicode.com" ], "url_pattern": "/users/{id}", "mapping": { "email": "personal_email" } } ], "concurrent_calls": 3, "timeout": "1000s", "inputquerystrings": [ "page", "limit" ] } ]}
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: howtobuild.md

Kusk CLI uses embedded manifests for `kusk cluster install`. Embedded files are built using `go-bindata` uses directive to build file that contains all binary data from manifests ``` //go:generate go-bindata -prefix "../../" -o cmd/manifest_data.go -pkg=cmd -ignore=debug/ -ignore=local/ -ignore=prometheus/ -ignore=samples/ ../../config/... manifests/... ``` First set of manifests are taken from `config` directory in ther root directory of the project. These manifests are used by kustomize to build and deploy kusk CRDs, Controller, RBAC and Webhooks. Configuration `config` are generated each time when `make manifests` is executed in the root director of the project. `make manifests` ensures that directory `config` always has the latest changes on the controller. Another set of manifests being embedded are located in `cmd/kusk/manifests` directory. These hold standard deployment for Kusk Dashboard and API server. These are split as follows: fleets.yaml - holds manifest for the public envoyfleet we need for hosting the dashboard apiserverapi.yaml - holds manifest for API Server API api_server.yaml - holds manifest for the API Server service, deployment, ServiceAccount, ClusterRoleBinding and ClusterRole dashboard_envoyfleet.yaml - holds manifest of the private envoyfleet for Dashboard so it can access API Server dashboard_staticroute.yaml - holds manifest for the Static Route for hosting the Dashboard dashboard.yaml - holds manifests for the dashboard Dervice, Deployment and ServiceAccount When invoking `kusk cluster install` embedded manifests are unpacked and stored in temporary directory, and are removed after use. Integrated `kubectl apply -k config/default` is invoked to install all Kubernetes resources required for Kusk to run Installer waits for kusk-gateway-manager pod to become Ready Integrated `kubectl apply -f manifests/fleets.yaml` (see lines 131 to 165 in cmd/kusk/cmd/install.go) which are installing Kusk API Server and Kusk Dashboard resources. After each step installer waits for Envoyfleet deployment to become ready before moving to installing Kusk API Server on which it also waits. And finally it installs Kusk Dashboard. `kusk cluster install --latest` - This command will pull the latest manifests from the latest in Kusk repository. After downloading the release installer will unzip it and place files in a temporary directory and then execute steps as shown above. To build kusk CLI Makefile is used for example `VERSION=v1.2.5 make build` ``` build: kustomize ``` Installs kustomize binary ``` cd ../../config/default && $(KUSTOMIZE) edit set image kusk-gateway=${MANAGER_IMG} ``` Sets default container image using kustomize. `kustomize edit set image kusk-gateway=${MANAGER_IMG}` will set value in `config/default/kustomization.yaml` to construct manifests with default image as below ``` images: name: kusk-gateway newName: kubeshop/kusk-gateway newTag: v1.2.5 ``` ``` go generate go build -v -o ./kusk -ldflags="${LD_FLAGS}" ./main.go ``` Generates embedded manifests and build the binary
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: using-kcp-as-a-library.md

linkTitle: "Library Usage" description: > How to use kcp as a library. Instead of running the kcp as a binary using `go run`, you can include the kcp api-server in your own projects. To create and start the api-server with the default options (including an embedded etcd server): ```go options, err := serveroptions.NewOptions().Complete() if err != nil { panic(err) } cfg, err := server.NewConfig(options) if err != nil { panic(err) } completedCfg, err := cfg.Complete() if err != nil { panic(err) } srv, err := server.NewServer(completedCfg) if err != nil { panic(err) } // Run() will block until the apiserver stops or an error occurs. if err := srv.Run(ctx); err != nil { panic(err) } ``` You may also configure post-start hooks which are useful if you need to start a some process that depends on a connection to the newly created api-server such as a controller manager. ```go // Create a new api-server with default options options, err := serveroptions.NewOptions().Complete() if err != nil { panic(err) } cfg, err := server.NewConfig(options) if err != nil { panic(err) } completedCfg, err := cfg.Complete() if err != nil { panic(err) } srv, err := server.NewServer(completedCfg) if err != nil { panic(err) } // Register a post-start hook that connects to the api-server srv.AddPostStartHook("connect-to-api", func(ctx genericapiserver.PostStartHookContext) error { // Create a new client using the client config from our newly created api-server client := clientset.NewForConfigOrDie(ctx.LoopbackClientConfig) _, err := client.Discovery().ServerGroups() return err }) // Start the api-server if err := srv.Run(ctx); err != nil { panic(err) } ```