cwielenb/CNCF-Dataset huggingface dataset:
Project: Beam (App Definition and Development / Streaming & Messaging)
File: 39_ai_runinference_metrics.md

Prompt: What metrics are available for monitoring the performance of ML model inference in Apache Beam? Response: Apache Beam enables efficient inference on both local and remote ML models within your pipelines through the RunInference API. This functionality is available in the Python SDK versions 2.40.0 and later. The Java SDK versions 2.41.0 and later also support the API through Apache Beams framework. The RunInference API provides built-in support for monitoring the performance of ML model inference. Here is a list of commonly used metrics for inference benchmarking: `modelbytesize`: size of the memory footprint of the model load and initialization. `loadmodellatencymillisecs`: time taken to load and initialize the model. `numinferences`: total number of elements passed to `runinference()`. `inferencebatchlatencymicrosecs`: time taken to perform inference across all batches of examples. `inferencerequestbatchbytesize`: size of the batch in bytes. `inferencerequestbatch_size`: number of examples in the batch. `failedbatchescounter`: number of failed batches. You can derive additional metrics from the ones listed above. Example: Total time taken for inference = `numinferences` x `inferencebatchlatencymicrosecsMEAN` Here is a simplified example of how to use the RunInference API to perform inference on a language model (LM): ```python with beam.Pipeline(options=pipeline_options) as pipeline: _ = ( pipeline | "Create inputs" >> beam.Create(<INPUTS>>) | "Tokenize" >> beam.ParDo(Tokenize(<TOKENIZER_NAME>)) | "Inference" >> RunInference(<MODEL_HANDLER>)) ``` After running the pipeline, you can query the metrics using the following code: ```python metrics = pipeline.result.metrics().query(beam.metrics.MetricsFilter()) ``` Metrics are also available in the UI. For the complete source code of the example and instructions to run it in Dataflow, refer to the . For a sample implementation of a metrics collector that tracks ML-related performance and memory usage, see the in the Apache Beam GitHub repository.
Project: FOSSA (Provisioning / Security & Compliance)
File: custom-integrating-with-bower-example.md

With `fossa-deps.{yml, json, yaml}` file, FOSSA CLI can be integrated to support any package manager or custom and non-standard management solution, that is yet to be supported natively by FOSSA CLI. With the fossa-deps file, we can: For an example, we will look at . We can usually identify a list of dependencies from our custom tool by looking at configuration files or executing a command. Bower provides both of these options, we can inspect (1) `bower.json` or (2) parse the output from the `bower list` command. From an example `bower.json` file, lists direct dependencies: ```json { "name": "example-project", "authors": [ "user <user@example.com>" ], "description": "Example project", "main": "main.js", "license": "MIT", "homepage": "", "ignore": [ "/.*", "node_modules", "bower_components", "test", "tests" ], "dependencies": { "font-awesome": "^5.0.0", "jquery": "^3.6.0" } } ``` We can execute `bower list` command to list all of the resolved bower dependencies: ``` example-project /Users/example-user/path font-awesome#5.15.4 jquery#3.6.0 ``` We have two dependencies (1) jquery and (2) font-awesome. From documentation, we know that `bower` type dependencies are supported type as reference dependency. We can include all listed dependencies in fossa-deps.json. ```json { "referenced-dependencies": [ { "type": "bower", "name": "jquery", "version": "3.6.0" }, { "type": "bower", "name": "font-awesome", "version": "5.15.4" } ] } ``` To programmatically add these dependencies, you can write a script in your language of choice to translate the dependency graph produced by bower to a fossa-deps file. Provided below is an example python script, which parses a dependency graph and produces a fossa-deps file. is an example python script that parses bower list command, and prints fossa-deps file. Please note that with the fossa-deps file, we can report dependencies, but we cannot: differentiate between direct and transitive dependencies report edge information between dependencies
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: pidfile.md

When the pidfile location is specified, the container process' PID is written to the pidfile. (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines) If the pidfile option is not specified, the container process' PID is written to /run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile. After the container is started, the location for the pidfile can be discovered with the following `podman inspect` command: $ podman inspect --format '{{ .PidFile }}' $CID /run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: knip-report.md

| Name | Location | Severity | | :-- | :-- | :- | | @backstage/repo-tools | package.json | error | | node-fetch | package.json | error | | Name | Location | Severity | | :- | :-- | :- | | better-sqlite3 | package.json | error |
Project: Beam (App Definition and Development / Streaming & Messaging)
File: tencent.md

title: "Tencent" icon: /images/logos/powered-by/tencent.png hasLink: "https://www.tencent.com/en-us/index.html" <!-- Licensed 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 http://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. -->
Project: Chef InSpec (Provisioning / Security & Compliance)
File: windows_hotfix.md

+++ title = "windows_hotfix resource" draft = false gh_repo = "inspec" platform = "windows" [menu] [menu.inspec] title = "windows_hotfix" identifier = "inspec/resources/os/windowshotfix.md windowshotfix resource" parent = "inspec/resources/os" +++ Use the `windows_hotfix` Chef InSpec audit resource to test if the hotfix has been installed on a Windows system. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.39.1 of InSpec. A `windows_hotfix` resource block declares a hotfix to validate: describe windows_hotfix('name') do it { should be_installed } end where `('name')` must specify the name of a hotfix, such as `'KB4012213'` `be_installed` is a valid matcher for this resource The following examples show how to use this Chef InSpec audit resource. describe windows_hotfix('KB4012213') do it { should be_installed } end describe windows_hotfix('KB9999999') do it { shouldnot beinstalled } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `be_installed` matcher tests if the named hotfix is installed on the system: it { should be_installed }
Project: YugabyteDB (App Definition and Development / Database)
File: universe-creation.md

title: Universe creation headerTitle: Universe creation linkTitle: Universe creation description: Learn how YugabyteDB creates a universe with YB-TServer and YB-Master nodes. menu: v2.18: identifier: universe-creation parent: core-functions weight: 1182 type: docs Creation of a YugabyteDB universe involves a number of steps. When creating a YugabyteDB universe, the first step is to bring up a sufficient number of YB-Masters (as many as the replication factor), with each being made aware of the others. These YB-Masters initialize themselves with a universally unique identifier (UUID), learn about each other and perform a leader election. At the end of this step, one of the masters establishes itself as the leader. You need to start as many YB-TServers as there are nodes, with the master addresses being passed to them on startup. They start sending heartbeats to the masters, communicating the fact that they are alive. The heartbeats also communicate about the tablets the YB-TServers are currently hosting as well as their load information, however the tablets do not yet exist in the system. Suppose a table is created in a YugabyteDB universe with four nodes. In addition, suppose that the table has a replication factor of 3. First the three masters are started in create mode. This is done explicitly to prevent accidental errors in creating a universe while it is already running. The following diagram depicts the start of the universe creation process: The following diagram depicts the process of the masters learning about each other and electing one leader: Finally, the YB-TServers are started, and they all send heartbeats to the YB-Master, as per the following diagram:
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: sdnotify.md

Determines how to use the NOTIFY_SOCKET, as passed with systemd and Type=notify. Default is container, which means allow the OCI runtime to proxy the socket into the container to receive ready notification. Podman sets the MAINPID to conmon's pid. The conmon option sets MAINPID to conmon's pid, and sends READY when the container has started. The socket is never passed to the runtime or the container. The healthy option sets MAINPID to conmon's pid, and sends READY when the container has turned healthy; requires a healthcheck to be set. The socket is never passed to the runtime or the container. The ignore option removes NOTIFY_SOCKET from the environment for itself and child processes, for the case where some other process above Podman uses NOTIFY_SOCKET and Podman does not use it.
Project: YugabyteDB (App Definition and Development / Database)
File: cluster-topology.md

title: Cluster topology headerTitle: Cluster topology linkTitle: Cluster topology headcontent: List the servers in your cluster menu: preview: identifier: show-cluster-topology parent: going-beyond-sql weight: 400 rightNav: hideH3: true type: docs In YugabyteDB, the cluster topology refers to the physical and logical layout of the nodes that make up the distributed system. Understanding and choosing the right cluster topology is essential for designing, deploying, and maintaining your database effectively. Topology directly impacts the scalability, performance, fault tolerance, and reliability of the database and thereby your applications. You can use the `yb_servers()` function to return a list of all the nodes in your cluster and their location. {{<note>}} The use the `yb_servers()` function to retrieve the cluster information to be and . {{</note>}} The function returns the following information. | Name | Description | | --: | :- | | host | Internal IP address of the node. | | port | Port at which the service will accept connections. | | num_connections | Number of active connections to the node. | | node_type | Type of the node. One of `primary`, `readreplica` | | cloud | Name of cloud provider. For example, `aws`, `gcp`. | | region | Name of the region in which the node is located. For example, `us-east-1`. | | zone | Name of the zone in which the node is located. For example, `us-east-1a`. | | public_ip | Externally accessible public IP address of the node. | | uuid | A UUID that uniquely identifies the node. | For a 6-node cluster spread across 3 zones in `aws.west`, you should see an output similar to the following: ```output host | port | cxn | nodetype | cloud | region | zone | publicip | uuid --++--+--+-+--+--+--+- 127.0.0.1 | 5433 | 0 | primary | aws | west | zone-a | 127.0.0.1 | d42d033f334242b2becbc43e028f64a2 127.0.0.2 | 5433 | 0 | primary | aws | west | zone-b | 127.0.0.2 | 8ab7569823c24d38a48ca2cd1e32ea18 127.0.0.3 | 5433 | 0 | primary | aws | west | zone-c | 127.0.0.3 | bf07b83fe52c479694d127948718dff3 127.0.0.4 | 5433 | 0 | primary | aws | west | zone-a | 127.0.0.4 | 7e4abfe19eb74c18a352fbfe99168372 127.0.0.5 | 5433 | 0 | primary | aws | west | zone-b | 127.0.0.5 | e3680e180e7046f287476fea45feef5e 127.0.0.6 | 5433 | 0 | primary | aws | west | zone-c | 127.0.0.6 | 80f5eb8622104851b7871a86fc66b5a5 ```
Project: BigchainDB (App Definition and Development / Database)
File: code-of-conduct.md

<! Copyright 2020 Interplanetary Database Association e.V., BigchainDB and IPDB software contributors. SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0) Code is Apache-2.0 and docs are CC-BY-4.0 > As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute to the project. We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or species--no picking on Wrigley for being a buffalo! Examples of unacceptable behavior by participants include: The use of sexualized language or imagery Personal attacks Trolling or insulting/derogatory comments Public or private harassment Publishing other's private information, such as physical or electronic addresses, without explicit permission Deliberate intimidation Other unethical or unprofessional conduct 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. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Instances of abusive, harassing, or otherwise unacceptable behavior directed at yourself or another community member may be reported by contacting a project maintainer at . All complaints will be reviewed and investigated and will result in a response that is appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident. This Code of Conduct is adapted from the , version 1.3.0, available at
Project: Trivy (Provisioning / Security & Compliance)
File: cache.md

The cache directory includes [^1] [^2] [^3] Cache of previous scans. The cache option is common to all scanners. The `--clear-cache` option removes caches. The scan is not performed. ``` $ trivy image --clear-cache ``` <details> <summary>Result</summary> ``` 2019-11-15T15:13:26.209+0200 INFO Reopening vulnerability DB 2019-11-15T15:13:26.209+0200 INFO Removing image caches... ``` </details> Specify where the cache is stored with `--cache-dir`. ``` $ trivy --cache-dir /tmp/trivy/ image python:3.4-alpine3.9 ``` !!! warning "EXPERIMENTAL" This feature might change without preserving backwards compatibility. Trivy supports local filesystem and Redis as the cache backend. This option is useful especially for client/server mode. Two options: `fs` the cache path can be specified by `--cache-dir` `redis://` `redis://[HOST]:[PORT]` TTL can be configured via `--cache-ttl` ``` $ trivy server --cache-backend redis://localhost:6379 ``` If you want to use TLS with Redis, you can enable it by specifying the `--redis-tls` flag. ```shell $ trivy server --cache-backend redis://localhost:6379 --redis-tls ``` Trivy also supports for connecting to Redis with your certificates. You need to specify `--redis-ca` , `--redis-cert` , and `--redis-key` options. ``` $ trivy server --cache-backend redis://localhost:6379 \ --redis-ca /path/to/ca-cert.pem \ --redis-cert /path/to/cert.pem \ --redis-key /path/to/key.pem ```
Project: ArangoDB (App Definition and Development / Database)
File: error_from_exception.md

+++ title = "`std::errorcode errorfromexception(std::exceptionptr &&ep = std::currentexception(), std::errorcode notmatched = std::makeerrorcode(std::errc::resourceunavailabletryagain)) noexcept`" description = "Returns an error code matching a thrown standard library exception." +++ This function saves writing boilerplate by rethrowing `ep` within a `try` block, with a long sequence of `catch()` handlers, one for every standard C++ exception type which has a near or exact equivalent code in {{% api "std::errc" %}}. If matched, `ep` is set to a default constructed {{% api "std::exception_ptr" %}}, and a {{% api "std::error_code" %}} is constructed using the ADL discovered free function `makeerrorcode()` upon the `std::errc` enumeration value matching the thrown exception. If not matched, `ep` is left intact, and the `not_matched` error code supplied is returned instead. Overridable: Not overridable. Requires: C++ exceptions to be globally enabled. Namespace: `BOOSTOUTCOMEV2_NAMESPACE` Header: `<boost/outcome/utils.hpp>`
Project: Shifu (Provisioning / Automation & Configuration)
File: CHANGELOG-v0.41.0.md

Added a step to install Go 1.22 by @tomqin93 in Bump golang.org/x/crypto from 0.19.0 to 0.21.0 by @dependabot in Bump github.com/microsoft/go-mssqldb from 1.6.0 to 1.7.0 by @dependabot in Bump github.com/Azure/azure-sdk-for-go/sdk/azcore from 1.9.2 to 1.10.0 by @dependabot in Bump go.uber.org/zap from 1.26.0 to 1.27.0 by @dependabot in Bump github.com/onsi/gomega from 1.30.0 to 1.32.0 by @dependabot in Bump github.com/Azure/azure-sdk-for-go/sdk/ai/azopenai from 0.4.1 to 0.5.0 by @dependabot in Bump github.com/taosdata/driver-go/v3 from 3.5.2 to 3.5.3 by @dependabot in Bump k8s.io/client-go from 0.29.2 to 0.29.3 by @dependabot in Bump github.com/go-sql-driver/mysql from 1.7.1 to 1.8.1 by @dependabot in Bump github.com/onsi/ginkgo/v2 from 2.15.0 to 2.17.1 by @dependabot in Full Changelog: https://github.com/Edgenesis/shifu/compare/v0.40.0...v0.41.0
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.33.md

layout: release date: 2024-03-17 tag: v0.7.33 feat: relationship between Limit-range and other components @RipulHandoo (#10070) Bump follow-redirects from 1.15.4 to 1.15.6 in /install/docker-extension/ui @dependabot (#10571) [Add]: Relationship between KubeArmorHostPolicy and k8s components @pandeyshubham03 (#10553) Move all components to sistent single package @sudhanshutech (#10548) Fix exp components cmd bugs @alphaX86 (#10337) Move all components to sistent single package @sudhanshutech (#10548) Bump follow-redirects from 1.15.4 to 1.15.6 in /ui @dependabot (#10572) Bump follow-redirects from 1.15.4 to 1.15.6 in /provider-ui @dependabot (#10570) Simplify the Environment assign in connections table @sudhanshutech (#10552) Bump github.com/99designs/gqlgen from 0.17.42 to 0.17.45 @dependabot (#10573) Bump follow-redirects from 1.15.4 to 1.15.6 in /ui @dependabot (#10572) Bump follow-redirects from 1.15.4 to 1.15.6 in /provider-ui @dependabot (#10570) [chore] fix integrations updater workflow @MUzairS15 (#10547) Bump google.golang.org/protobuf from 1.31.0 to 1.33.0 @dependabot (#10561) Bump github.com/jackc/pgx/v5 from 5.4.3 to 5.5.4 @dependabot (#10568) solves hover effect issue in dark mode @ayush844 (#10402) Update jekyll docker image to 4.0 in Makefile @sangramrath (#10545) Thank you to our contributors for making this release possible: @MUzairS15, @RipulHandoo, @alphaX86, @ayush844, @dependabot, @dependabot[bot], @iArchitSharma, @leecalcote, @pandeyshubham03, @sangramrath, @sudhanshutech and l5io
Project: YugabyteDB (App Definition and Development / Database)
File: cmd_reset.md

title: RESET statement [YSQL] headerTitle: RESET linkTitle: RESET description: Use the RESET statement to restore the value of a run-time parameter to the default value. menu: v2.18: identifier: cmd_reset parent: statements type: docs Use the `RESET` statement to restore the value of a run-time parameter to the default value. `RESET` is an alternative spelling for `SET runtimeparameter TO DEFAULT`. {{%ebnf%}} reset_stmt {{%/ebnf%}} Specify the name of a mutable run-time parameter.
Project: secureCodeBox (Provisioning / Security & Compliance)
File: new_security_scanner.md

name: ' New Security Scanner request' about: 'Suggest an idea for a new security scanner to integrate in this project.' labels: 'scanner' <!-- Thank you for contributing to our project Before opening a new issue, please make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead. Also, please, have a look at our FAQs and existing questions before opening a new question. --> <!-- Please describe a clear and concise description of what the problem is. Use commmon user story patterns like https://en.wikipedia.org/wiki/User_story: As a <role> I can <capability>, so that <receive benefit> In order to <receive benefit> as a <role>, I can <goal/desire> As <who> <when> <where>, I <want> because <why> For example... As a secureCodeBox user i'm always frustrated when [...] --> <!-- A clear and concise description of what you want to happen. --> <!-- A clear and concise description of any alternative solutions or features you've considered. --> <!-- Add any other context or screenshots about the feature request here. --> Hint: A general guide how to implement a new SCB scanner is documented [ ] Create a new Helm Chart with the `make create-new-scanner NAME=new-scanner` command in the project directory (replace `new-scanner` with the name of the scanner) [ ] Add a basic description of your scanner Helm chart in the `Chart.yaml` [ ] (optional) Add/Edit fields in `values.yaml` [ ] Add (optional) a `Dockerfile` for the scanner if there is no existing one publicly available on DockerHub in the `scanner` directory to implement a new findings parser (currently based on NodeJS) in the `parser` directory [ ] Add unit tests with at minimum 80% test coverage for the hook [ ] Add a brief overview of the scanner and its configuration options in `.helm-docs.gotmpl`
Project: Chef InSpec (Provisioning / Security & Compliance)
File: uninstall.md

+++ title = "Uninstall Chef InSpec" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "Uninstall" identifier = "inspec/install/uninstall" parent = "inspec/install" weight = 40 +++ You can uninstall Chef InSpec using the steps below that are appropriate for the method of Chef InSpec installation. Use the following destructive command to remove the Chef InSpec standalone Homebrew package: ```bash brew cask uninstall inspec ``` Use the following destructive command in your terminal to remove the Chef InSpec package: ```bash sudo rm -rf /opt/inspec ``` Use Add / Remove Programs to remove Chef InSpec. Use the following destructive commands to uninstall Chef InSpec from Linux-based platforms. For Ubuntu, use the following destructive command to uninstall Chef InSpec: ```bash sudo dpkg -P inspec ``` For Red Hat Enterprise Linux, use the following destructive command to uninstall Chef InSpec: ```bash sudo rpm -e inspec ``` For SUSE Linux Enterprise Server, use the following destructive command to uninstall Chef InSpec: ```bash sudo zypper remove inspec ```