cwielenb/CNCF-Dataset huggingface dataset:
Project: Kepler (Observability and Analysis / Observability)
File: RELEASING.md

A Ginkgo release is a tagged git sha and a GitHub release. To cut a release: Ensure CHANGELOG.md is up to date. Use ```bash LAST_VERSION=$(git tag --sort=version:refname | tail -n1) CHANGES=$(git log --pretty=format:'- %s [%h]' HEAD...$LAST_VERSION) echo -e "## NEXT\n\n$CHANGES\n\n### Features\n\n### Fixes\n\n### Maintenance\n\n$(cat CHANGELOG.md)" > CHANGELOG.md ``` to update the changelog Categorize the changes into Breaking Changes (requires a major version) New Features (minor version) Fixes (fix version) Maintenance (which in general should not be mentioned in `CHANGELOG.md` as they have no user impact) Update `VERSION` in `types/version.go` Commit, push, and release: ``` git commit -m "vM.m.p" git push gh release create "vM.m.p" git fetch --tags origin master ```
Project: Sensu (Observability and Analysis / Observability)
File: epic_template.md

name: 'Epic' about: 'Create an epic' <! Provide a summary of what the epic should accomplish --> <! Link to the proposal doc > <! Link to the spec doc --> <! Link(s) to sensu-go GH issues > <! Link(s) to sensu-enterprise-go GH issues > <! Link(s) to sensu-go-qa-crucible GH issues > <! Link(s) to sensu-staging GH issues > <! Link(s) to sensu-docs GH issues >
Project: Grafana Mimir (Observability and Analysis / Observability)
File: tenant-injector.md

aliases: ../../operators-guide/tools/tenant-injector/ description: Use the tenant injector to query data for a tenant during development and troubleshooting. menuTitle: Tenant injector title: Grafana Mimir tenant injector weight: 20 The tenant injector is a standalone HTTP proxy that injects the `X-Scope-OrgID` header with a value, which you specify via the `-tenant-id` flag into incoming HTTP requests, and then forwards the modified requests to the URL you specify via the `-remote-address` flag. You can use the tenant injector to query data for a tenant during development or troubleshooting. ``` Usage of tenant-injector: -local-address string Local address to listen on (host:port or :port). (default ":8080") -remote-address string URL of target to forward requests to to (eg. http://domain.com:80). -tenant-id string Tenant ID to inject to proxied requests. ```
Project: Vector (Observability and Analysis / Observability)
File: 2020-05-04-shutdown-vector-if-all-sources-finish.md

date: "2020-07-13" title: "Vector gracefully exits when specific sources finish" description: "One step closer to Vector replacing awk and sed!" authors: ["hoverbear"] hideonrelease_notes: false pr_numbers: [2533] release: "0.10.0" badges: type: "enhancement" sources: ["stdin"] We heard from some folks they were using Vector as a data processor in command line scripts! Good for you, UNIX hackers ! Now, in 0.10.0, you can use Vector in standard UNIX pipelines much easier! ```bash banana@tree:/$ echo "awk, sed the Vic" | vector --config test.toml --quiet {"host":"tree","message":"awk, sed the Vic","source_type":"stdin","timestamp":"2020-05-04T20:43:59.522211979Z"} ``` We've been exploring options for expanding `vector generate` to allow users to specify options from the command line. For example: ```bash banana@tree:/$ vector generate stdin//console(encoding=json) ``` Once this happens, it seems inevitable we'll add something like this eventually: ```bash banana@tree:/$ vector eval stdin//console(encoding=json) ``` Want to contribute?
Project: Netdata (Observability and Analysis / Observability)
File: consul_node_health_check_status.md

This alert is triggered when a Consul node health check status indicates a failure. Consul is a service mesh solution for service discovery and configuration. If you receive this alert, it means that the health check for a specific service on a node within the Consul cluster has failed. Consul performs health checks to ensure the services registered within the cluster are functioning as expected. The health check status represents the result of these checks, with a non-zero value indicating a failed health check. A failed health check can potentially cause downtime or degraded performance for the affected service. Check the alert details: The alert information provided should include the `checkname`, `nodename`, and `datacenter` affected. Note these details as they will be useful in further troubleshooting. Verify the health check status in Consul: To confirm the health check failure, access the Consul UI or use the Consul command-line tool to query the health status of the affected service and node: ``` consul members ``` ``` consul monitor ``` Investigate the failed service: Once you confirm the health check failure, start investigating the specific service affected. Check logs, resource usage, configuration files, and other relevant information to identify the root cause of the failure. Fix the issue: Based on your investigation, apply the necessary fixes to the service or its configuration. This may include restarting the service, adjusting resource allocation, or fixing any configuration errors. Verify service health: After applying the required fixes, verify the health status of the service once again through the Consul UI or command-line tool. If the service health check status has returned to normal (zero value), the issue has been resolved. Monitor for any recurrence: Keep an eye on the service, node, and overall Consul cluster health to ensure the issue does not reappear and to catch any other potential problems.
Project: Grafana Loki (Observability and Analysis / Observability)
File: version.md

title: Version description: Version Grafana Loki uses Semantic Versioning. The next version can be determined by looking at the current version and incrementing it. When the release is a new `major` version (for example, after 2.9.1 we decide to go 3.0.0 instead of 2.9.2) this should not be done. You need to set two environmental values `VERSION` and `VERSION_PREFIX` to do the release process. To determine the `VERSION` for a Stable Release or Patch Release, use the Semantic Version `A.B.C`. Examples For example, `2.9.0` is the Stable Release `VERSION` for the v2.9.0 release. For example, `2.9.1` is the first Patch Release `VERSION` for the v2.9.0 release. To determine the `VERSION PREFIX`, use only the major and minor version `A.B.x`. Examples `2.9.x`
Project: Checkmk (Observability and Analysis / Observability)
File: 16599.md

key | value | date | 2024-03-11T13:50:14+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The check plugin no longer showed any metrics if a product was not specified in the ruleset configuration. This werk restores the original behaviour, using as a default product the one reported in the info section of the agent output.
Project: Checkmk (Observability and Analysis / Observability)
File: 16488.md

key | value | date | 2024-03-22T07:17:07+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When no data was available for the ReservationUtilization section the special agent would crash. Now this error is handled and no longer crashes.
Project: Graylog (Observability and Analysis / Observability)
File: Button.md

```js import { MenuItem } from 'components/bootstrap'; const styles = ['Primary', 'Danger', 'Warning', 'Success', 'Info', 'Link', 'Default']; styles.map((style, i) => { return ( <p key={`button-example-${style}-${i}`}> <Button bsStyle={style.toLowerCase()}>{style}</Button>{' '} <Button active bsStyle={style.toLowerCase()}>{style} Active</Button>{' '} <Button disabled bsStyle={style.toLowerCase()}>{style} Disabled</Button>{' '} </p> ) }) ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: format_rfc5424.md

title: Format rfc5424 weight: 200 generated_file: true Sets app name in syslog from field in fluentd, delimited by '.' Default: app_name Sets host name in syslog from field in fluentd, delimited by '.' Default: hostname Sets log in syslog from field in fluentd, delimited by '.' Default: log Sets msg id in syslog from field in fluentd, delimited by '.' Default: message_id Sets proc id in syslog from field in fluentd, delimited by '.' Default: proc_id Prepends message length for syslog transmission Default: true Sets structured data in syslog from field in fluentd, delimited by '.' (default structured_data) Output line formatting: outfile,json,ltsv,csv,msgpack,hash,singlevalue Default: json
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: verify-pods.md

layout: default title: Verify pod status description: "" permalink: /verify parent: Writing policies nav_order: 5 {: .no_toc } {: .no_toc .text-delta } TOC {:toc} You can also use `PowerfulSeal` to just assert things about your cluster. ```yaml scenarios: name: Verify there only running pods steps: podAction: matches: namespace: "*" filters: property: name: state value: Running negative: true randomSample: size: 1 actions: checkPodCount: count: 0 ``` ```yaml scenarios: name: Count pods with a specific label steps: podAction: matches: labels: namespace: "*" selector: important=true actions: checkPodCount: count: 78 ```
Project: M3 (Observability and Analysis / Observability)
File: query.md

title: "API" menuTitle: "Query" weight: 1 Please note: This documentation is a work in progress and more detail is required. Query using PromQL and returns JSON datapoints compatible with the Prometheus Grafana plugin. `/api/v1/query_range` `GET` `start=[time in RFC3339Nano]` `end=[time in RFC3339Nano]` `step=[time duration]` `target=[string]` `debug=[bool]` `lookback=[string|time duration]`: This sets the per request lookback duration to something other than the default set in config, can either be a time duration or the string "step" which sets the lookback to the same as the `step` request parameter. {{% fileinclude file="headersoptionalreadwriteall.md" %}} {{% fileinclude file="headersoptionalread_all.md" %}} None. <!-- Note: keep this example similar to the one found in coordinator API documentation for consistency/ease of readers. --> ```shell curl '{{% apiendpoint %}}queryrange?query=abs(httprequests_total)&start=1530220860&end=1530220900&step=15s' { "status": "success", "data": { "resultType": "matrix", "result": [ { "metric": { "code": "200", "handler": "graph", "method": "get" }, "values": [ [ 1530220860, "6" ], [ 1530220875, "6" ], [ 1530220890, "6" ] ] }, { "metric": { "code": "200", "handler": "label_values", "method": "get" }, "values": [ [ 1530220860, "6" ], [ 1530220875, "6" ], [ 1530220890, "6" ] ] } ] } } ```
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: openfeature_python.md

sidebar_position: 51 title: Python description: How to use the OpenFeature Python SDK with GO Feature Flag The first things we will do is install the Open Feature SDK and the GO Feature Flag provider. ```shell pip install gofeatureflag-python-provider ``` To evaluate the flags you need to have an Open Feature configured in you app. This code block shows you how you can create a client that you can use in your application. ```python from gofeatureflagpythonprovider.provider import GoFeatureFlagProvider from gofeatureflagpythonprovider.options import GoFeatureFlagOptions from openfeature import api from openfeature.evaluation_context import EvaluationContext // ... goff_provider = GoFeatureFlagProvider( options=GoFeatureFlagOptions(endpoint="https://gofeatureflag.org/") ) api.setprovider(goffprovider) client = api.get_client(name="test-client") ``` This code block explains how you can create an `EvaluationContext` and use it to evaluate your flag. In this example, we are evaluating a `boolean` flag, but other types are also available. Refer to the to know more about it. ```python // Context of your flag evaluation. // With GO Feature Flag you MUST have a targetingKey that is a unique identifier of the user. evaluation_ctx = EvaluationContext( targeting_key="d45e303a-38c2-11ed-a261-0242ac120002", attributes={ "email": "john.doe@gofeatureflag.org", "firstname": "john", "lastname": "doe", "anonymous": False, "professional": True, "rate": 3.14, "age": 30, "companyinfo": {"name": "mycompany", "size": 120}, "labels": ["pro", "beta"], }, ) adminflag = client.getboolean_value( flagkey=flagkey, defaultvalue=defaultvalue, evaluation_context=ctx, ) if admin_flag: else: ``` You can find the source of the provider in the .
Project: Netdata (Observability and Analysis / Observability)
File: hdfs_missing_blocks.md

This alert monitors the number of missing blocks in a Hadoop Distributed File System (HDFS). If you receive this alert, it means that there is at least one missing block in one of the DataNodes. This issue could be caused by a problem with the underlying storage or filesystem of a DataNode. Before you perform any action, make sure that you have taken any necessary backup steps. Netdata is not liable for any loss or corruption of any data, database, or software. Identify which files are facing issues. ```sh root@netdata # hdfs fsck -list-corruptfileblocks ``` Inspect the output and track the path(s) to the corrupted files. Determine where the file's blocks might live. If the file is larger than your block size, it consists of multiple blocks. ```sh root@netdata # hdfs fsck <pathtocorrupted_file> -locations -blocks -files ``` This command will print out locations for every "problematic" block. Search in the corresponding DataNode and the NameNode's logs for the machine or machines on which the blocks lived. Try looking for filesystem errors on those machines. Use `fsck`. If there are files or blocks that you cannot fix, you must delete them so that the HDFS becomes healthy again. For a specific file: ```sh root@netdata # hdfs fs -rm <pathtofilewithunrecoverable_blocks> ``` For all the "problematic" files: ```sh hdfs fsck / -delete ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: prettier_rules.md

This files contains rules for prettifying PromQL expressions. Note: The current version of prettier does not preserve comments. `maxcharactersper_line`: Maximum number of characters that will be allowed on a single line in a prettified PromQL expression. A node exceeding the `maxcharactersper_line` will qualify for split unless It is a `MatrixSelector` It is a `VectorSelector`. Label sets in a `VectorSelector` will be in the same line as metric_name, separated by commas and a space Note: Label groupings like `by`, `without`, `on`, `ignoring` will remain on the same line as their parent node Nodes that are nested within another node will be prettified only if they exceed the `maxcharactersper_line` Expressions like `sum(expression) without (labelmatchers)` will be modified to `sum without(labelmatchers) (expression)` Functional call args will be split to different lines if they exceed the `maxcharactersper_line`
Project: Checkmk (Observability and Analysis / Observability)
File: 16659.md

key | value | date | 2024-04-24T08:37:31+00:00 version | 2.4.0b1 class | fix edition | cre component | wato level | 1 compatible | yes When using the "Authentication Expiration" sync plug-in for LDAP, users can be stuck in a locked state after too many failed login attempts. With this werk it is now allowed to edit the "Disable password" option in the UI (or "disable_login" in the REST API) for users managed by LDAP. Please note that a sync with the LDAP will restore the original value.
Project: Grafana Loki (Observability and Analysis / Observability)
File: prepare-release.md

title: Prepare Release description: Describes the prepare release pipeline that prepares release PRs for Grafana Loki. Releasing Grafana Loki consists of merging a long-running release PR. Two workflows keep these PRs up to date, one for patch releases (which runs on commits to branches matching `release-[0-9]+.[0-9]+.x`) and one for minor releases (which runs on commits to branches matching `k[0-9]+`). These pipelines use release please to do the following: Run tests and linting Build binaries and images for the proposed release version Generate release notes based on conventional commits since the last release Create or update the long-running release PR for that release, indicating which commit will be released if the PR is merged with a link to the built artifacts that will be published. Major releases follow the same process as minor and patch releases, but require a custom workflow to be created to run on the branch we want to release from. The reason for this is that we don't do major releases very often, so it is not economical to keep those workflows running all the time.To create a major release workflow, follow the steps in the document.
Project: M3 (Observability and Analysis / Observability)
File: cluster-architecture.md

<!-- TODO: Update image --> An M3 deployment typically has two main node types: (`m3dbnode`) are the workhorses of M3, they store data and serve reads and writes. (`m3coordinator`) coordinate reads and writes across all nodes in the cluster. It's a lightweight process, and does not store any data. This role typically runs alongside a Prometheus instance, or is part of a collector agent such as statsD. A `m3coordinator` node exposes two external ports: `7201` to manage the cluster topology, you make most API calls to this endpoint `7203` for Prometheus to scrape the metrics produced by M3DB and M3Coordinator There are two other less-commonly used node types: (`m3query`) are an alternative query option to using M3's built-in PromQL support. cluster and aggregate metrics before storing them in storage nodes. Coordinator nodes can also perform this role but are not cluster-aware. <!-- TODO: Add more about what's bundled --> M3 uses as a distributed key-value storage for the following functions: Update cluster configuration in realtime Manage placements for distributed and sharded clusters
Project: Headlamp (Observability and Analysis / Observability)
File: headless.md

title: Running in headless mode linktitle: Headless Mode weight: 50 Some users prefer running Headlamp using the desktop app, but directly in their web browser instead of the Electron's environment as this allows them to leverage the browser's functionality such as bookmarks, groups, etc. Running Headlamp in the system's browser can be done by using the `--headless` CLI option. Assuming you have already downloaded and installed Headlamp on your desktop, you can run it in headless mode as follows: Example: On Linux: `flatpak run io.kinvolk.Headlamp --headless` (or `./Headlamp.AppImage --headless` for AppImage) On MacOS: `./Headlamp --headless` On Windows: `./Headlamp.exe --headless`
Project: Grafana Tempo (Observability and Analysis / Observability)
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, gender identity and expression, level of experience, 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 oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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 .
Project: Hubble (Observability and Analysis / Observability)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`