cwielenb/CNCF-Dataset huggingface dataset:
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: deployment-redundancy.md

layout: default title: Deployment redundancy description: "" permalink: /deployment-redundancy parent: Writing policies nav_order: 4 {: .no_toc } {: .no_toc .text-delta } TOC {:toc} Let's say you have a deployment (`mydeployment`), fronted by a service (`myservice`). The deployment has 3 instances, and in theory, you should be able to lose one with no traffic down. Let's test that. But only during the week, and before lunch, just in case something does break. ```yaml scenarios: name: Deployment redundancy steps: podAction: matches: deployment: name: mydeployment namespace: example filters: dayTime: onlyDays: monday tuesday wednesday thursday friday startTime: hour: 10 minute: 0 second: 0 endTime: hour: 12 minute: 30 second: 0 randomSample: size: 1 actions: kill: force: false probeHTTP: target: service: name: myservice namespace: example port: 8000 ``` Let's say that you have three pods in the deployment. If you'd like to be sure that your policy handles a situation when one of them was already down, you can pick a third of the running ones: ```yaml scenarios: name: Deployment redundancy 2 steps: podAction: matches: deployment: name: mydeployment namespace: example filters: property: name: state value: Running randomSample: ratio: 0.34 actions: kill: force: false probeHTTP: target: service: name: myservice namespace: example port: 8000 ```
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Checkmk (Observability and Analysis / Observability)
File: 16664.md

key | value | date | 2024-03-22T11:52:27+00:00 version | 2.4.0b1 class | fix edition | cre component | inv level | 1 compatible | yes The inventory data of `invciscovlans` and `inv_if` used to be combined in one row. This behavior was broken as of 2.3, where two different rows were displayed for each inventory plugin. Now the rows are unified again. Also fixed the missing color of the status displayed in the inventory rows.
Project: Grafana Loki (Observability and Analysis / Observability)
File: .checked-pr-template.md

Thanks submitting your Operator. Please check below list before you create your Pull Request. ? your Operator for Operator Framework? [x] Have you tested your Operator with all Custom Resource Definitions? ? ? ? set? ? [x] Is your new CSV pointing to the previous version with the `replaces` property if you chose `replaces-mode` via the `updateGraph` property in `ci.yaml`? defined in the `package.yaml` or `annotations.yaml` ? [ ] Have you tested an update to your Operator when deployed via OLM? ? [x] Modify more than one operator [x] Modify an Operator you don't own [x] Rename an operator - please remove and add with a different name instead [x] Submit operators to both `upstream-community-operators` and `community-operators` at once [x] Modify any files outside the above mentioned folders [x] Contain more than one commit. Please squash your commits.* [x] Description about the managed Application and where to find more information [x] Features and capabilities of your Operator and how to use it [x] Any manual steps about potential pre-requisites for using your Operator [x] Human readable name and 1-liner description about your Operator <sup>1</sup> <sup>2</sup> [x] Links to the maintainer, source code and documentation [x] Example templates for all Custom Resource Definitions intended to be used [x] A quadratic logo Remember that you can preview your CSV . -- <sup>1</sup> If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need <sup>2</sup> For more information see
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: oci.md

title: 'Gadgets as OCI artifacts' weight: 20 description: 'Reference documentation for the format of a gadget OCI artifact' Intro TODO The defines the [Image Format Specification](https://github.com/opencontainers/image-spec/blob/main/spec.md). This specification was initially defined for container images but it is extended to store other artifacts, see [Guidance for Artifacts Authors](https://github.com/opencontainers/image-spec/blob/main/artifacts-guidance.md). Inspektor Gadget supports multi architecture artifacts. The following architectures are supported: amd64 arm64 Media type: `application/vnd.gadget.config.v1+yaml` The content has the type [GadgetMetadata struct](https://github.com/inspektor-gadget/inspektor-gadget/blob/7d12644a89217bdbf861da54cd8bd2a370754ece/pkg/gadgets/run/types/metadata.go#L136). It is a work in progress. Each architecture can contain several layers, but each layer must have a different media type among the following: `application/vnd.gadget.ebpf.program.v1+binary` `application/vnd.gadget.wasm.program.v1+binary` `application/vnd.gadget.btfgen.v1+binary` There must be exactly one layer with the ebpf media type. It must not be empty. Its content must be a valid ELF file. There must be at most one layer with the wasm media type. If present, it must not be empty and it must be a valid wasm file. is used to enable running eBPF programs on kernels that don't provide BTF information. A gadget image can contain at most one btfgen layer. This layer must contain the generated BTF files in a tarball following the same folder structure of . OCI images can have annotations at different levels: index manifest config layer Inspektor Gadget automatically adds the following annotations at the manifest and config levels: `org.opencontainers.image.*`: defined by title description url documentation source created
Project: Loggie (Observability and Analysis / Observability)
File: CHANGELOG-7.0.md

See . The `SearchHit` structure changed from ``` // SearchHit is a single hit. type SearchHit struct { ... Source *json.RawMessage `json:"_source,omitempty"` // stored document source ... } ``` to ``` // SearchHit is a single hit. type SearchHit struct { ... Source json.RawMessage `json:"_source,omitempty"` // stored document source ... } ``` As `json.RawMessage` is a `[]byte`, there is no need to specify it as `*json.RawMessage` as `json.RawMessage` is perfectly ok to represent a `nil` value. So when deserializing the search hits, you need to change your code from: ``` for _, hit := range searchResult.Hits.Hits { var doc Doc err := json.Unmarshal(hit.Source, &doc) // notice the here if err != nil { // Deserialization failed } } ``` to ``` for _, hit := range searchResult.Hits.Hits { var doc Doc err := json.Unmarshal(hit.Source, &doc) // it's missing here if err != nil { // Deserialization failed } } ```
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: issue_template.md

<!-- GitHub is for bugs, feature and enhancement requests, and discussion on developing Service Fabric, as opposed to using it. If you need help or have any questions regarding using Service Fabric, you can ask on --> If you know the area of code this belongs to, please select an appropriate tag. Otherwise, select `triage-needed` Bug or Enhancement: Questionnaire for bug reports. Feel free to delete if filing an enhancement Describe the issue: Describe as best as possible how to reproduce the issue: If found from a deployment, please include the following Service Fabric Version: Guest OS version: Hosted on Azure or On-Prem:
Project: 3Scale (Orchestration & Management / API Gateway)
File: dns-resolver.md

APIcast ships with own DNS resolver implemented in Lua. Current nginx resolver has some issues like that it does not support multiple DNS servers properly. For example on OpenShift there are two DNS servers and one search path. Nginx is not able to properly resolve internal DNS names. Also we like to use nginx facilities for load balancing and proxying. That means we have to use `balancerbylua` directive which can set the load balancer. But it has to set it to the IP address, not the DNS name. So we have to resolve that DNS name into IP address and there is no API exposed in nginx to do that. Our DNS resolver should meet following criteria: caching for duration of TTL resolve A and CNAME records using stale cache when TTL expires and cache can't be updated many parallel requests to one worker result in one query connect to multiple DNS servers in parallel working search scope A request is made to APIcast and DNS cache is updated. Then there is no request for TTL of that record and another request is made after that record expires. First request after expired TTL is going to make new query. Other requests that arrive before that query is finished are going to use stale cache (if it is in the cache as it is LRU). 1000 requests are made in the same time. If there is no cache all the requests are going to git the DNS server which should de-duplicate queries. We rely on dnsmasq for now. With constant traffic 1000 requests per second when the DNS cache expires the first request is going to refresh the query but until it is finished stale cache is going to get used. Using OpenResty's `lua-resty-dns` we can connect to any DNS server and implement our own resolver. DNS resolver caches each record individually and fetches it from the cache recursively. That allows us to have layers of cache and fill just the missing layers. Example: CNAME (TTL 3600) -> CNAME (TTL 360) -> A (TTL 60) will just query the A record when it expires. Querying multiple nameservers in parallel is accomplished by using "light thread". The first nameserver that responds is used. De-duplicating queries is achieved by using dnsmasq running in the same container. Search scope defined in `/etc/resolv.conf` is evaluted one by one until matching record is returned. This could be optimized by executing all queries in parallel. But this is also improved by using dnsmasq which is going to search the scope on the first query so APIcast does not have to. Following rules apply to handle scenarios described above: When cache is missing query goes to DNS server. It is responsibiity of the deployment to provide local caching dns server. When cache is stale, first request is going to refresh the query but all others use stale cache until the cache is updated. If record can't be updated, use stale cache for unlimited time, but try to recover. This has one drawback: in low traffic scenario, the first requests after some time can hit wrong server before the cache is updated.
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: vertica.md

| Parameter | Description | |-|| | Datasource | Select VERTICA. | | Datasource Name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the Vertica service IP. | | Port | Enter the Vertica service port. | | Username | Set the username for Vertica connection. | | Password | Set the password for Vertica connection. | | Database name | Enter the database name of the Vertica connection. | | Jdbc connection parameters | Parameter settings for Vertica connection, in JSON format. | Yes, could use this datasource by default.
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: usage_metrics.md

Some functionality the executor has is to report how much cpu/memory jobs are using. This is turned on by changing the executor config file to include: ``` yaml metric: exposeQueueUsageMetrics: true ``` The metrics are calculated by getting values from metrics-server. When developing locally with Kind, you will also need to deploy metrics-server to allow this to work. The simplest way to do this it to apply this to your kind cluster: ``` kubectl apply -f https://gist.githubusercontent.com/hjacobs/69b6844ba8442fcbc2007da316499eb4/raw/5b8678ac5e11d6be45aa98ca40d17da70dcb974f/kind-metrics-server.yaml ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: OpenELB (Orchestration & Management / Service Proxy)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at ray@yunify.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: rig-dev-guide.md

id: rig-dev-guide title: Developer's Guide to the Reactive Interaction Gateway sidebar_label: Developer's Guide You'd like to help hacking? Great! To get started, install Elixir and the Mix build tool on your machine. If you use , all you need to do is `asdf install`. Otherwise, either follow the , or use to install and manage Elixir runtimes. With Elixir installed, do this: Install dependencies with `mix deps.get` Start Phoenix endpoint with `mix phx.server` RIG doesn't come with a status website, but if you like to you can check its health endpoint: ```bash $ curl localhost:4000 {"message":"Route is not available"} $ curl localhost:4010/health OK ``` Additional notes: You can run tests with `mix test`. See for more details. When debugging multi-node features, it's helpful to run the (named) nodes in `iex` sessions using `iex --sname nodename -S mix`. Our conventions are documented in . See for more details. Run `mix docs` to see the source documentation. The module descriptions should make the code structure obvious; if they don't, please open an issue describing what you were looking for but couldn't find. Also, updates to the (source code) documentation are appreciated! To have the project use a newer Elixir version, make sure to change the following locations: `.travis.yml`: Update the Elixir and OTP versions in the `.elixir-env` section. `Dockerfile`, `aws.dockerfile`, `smoke_tests.dockerfile`: Make sure to change the `FROM` image tag for both the build image (elixir:...-alpine) as well as the runtime image (erlang:...-alpine). If the Erlang runtime (ERTS) in the runtime image doesn't match the ERTS version in the build image, chances are the built image won't work due to missing libraries. Because of this, it's best to use the most recent versions for both images when upgrading - they should always be compatible. `.tool-versions`: Again, make sure both the Elixir and the OTP versions match what you have used in the previous steps. Increment `@rig_version` in Increment `appVersion` in the and files Update Helm chart README files: install and run `helm-docs` in the root directory Increment image tag in the file In , rename `[Unreleased]` and add a corresponding link to the bottom of the file Create a signed Git tag either using `git -s` or by creating a release using the Github UI We use `tag`s to group tests together. Often, it makes sense to assign more than one tag to a test case. | `@tag` | When to use it? | | - | | | `:avro` | Integration tests that require a running Avro schema registry. | | `:kafka` | Integration tests that require a running Kafka broker. | | `:kinesis` | Integration tests that require an active Kinesis stream. | | `:smoke` | Quick integration test that is designed to catch obvious integration problems. |