cwielenb/CNCF-Dataset huggingface dataset:
Project: YugabyteDB (App Definition and Development / Database)
File: operations-faq.md

title: FAQs about operating YugabyteDB clusters headerTitle: Operations FAQ linkTitle: Operations FAQ description: Answers to common questions about operating YugabyteDB clusters menu: preview_faq: identifier: faq-operations parent: faq weight: 50 type: docs unversioned: true showRightNav: false For YSQL, you should use a YugabyteDB smart driver. YugabyteDB smart drivers automatically balance connections to the database and eliminate the need for an external load balancer. If you are not using a smart driver, you will need an external load balancer. To learn more about smart drivers, refer to . For YCQL, YugabyteDB provides automatic load balancing. clusters automatically use the uniform load balancing provided by the cloud provider where the cluster is provisioned. YugabyteDB Managed creates an external load balancer to distribute the connection load across the nodes in a particular region. For multi-region clusters, each region has its own external load balancer. For regular connections, you need to connect to the region of choice, and application connections are then uniformly distributed across the region without the need for any special coding. For more information on connection load balancing in YugabyteDB Managed, refer to . To configure a YugabyteDB universe deployed on GCP to use GCP-provided load balancers, you must set the and flags. To set these flags for a universe in YugabyteDB Anywhere, refer to . For most YugabyteDB deployments, you should not need to adjust the configuration flags for the write ahead log (WAL). While your data size is small and growing, the WAL files may seem to be much larger, but over time, the WAL files should reach their steady state while the data size continues to grow and become larger than the WAL files. WAL files are per tablet and the retention policy is managed by the following two `yb-tserver` configuration flags: Also, the following `yb-tserver` configuration flag is a factor in the size of each WAL file before it is rolled into a new one: default is `64`.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.5.62.md

layout: release date: 2021-09-29 tag: v0.5.62 [performance] fix bugs related to load generators @DelusionalOptimist (#4264) Bump nokogiri from 1.11.7 to 1.12.5 in /docs @dependabot (#4260) [UI] Updated the UI of confirmation prompt @Meghana-12 (#4266) added maximize and minimize to application @warunicorn19 (#4268) Added meshkit style errors and comments @Revolyssup (#4263) Thank you to our contributors for making this release possible: @DelusionalOptimist, @Meghana-12, @Revolyssup, @dependabot, @dependabot[bot], @leecalcote and @warunicorn19
Project: Chef InSpec (Provisioning / Security & Compliance)
File: timezone.md

+++ title = "timezone resource" draft = false gh_repo = "inspec" platform = "linux" [menu] [menu.inspec] title = "timezone" identifier = "inspec/resources/os/timezone.md timezone resource" parent = "inspec/resources/os" +++ Use the `timezone` Chef InSpec audit resource to test timezone configurations of the system. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} A `timezone` resource block fetches the time zone configuration of a system and compares the output with the test: describe timezone do its('property') { should eq 'expected value' } end where `'property'` is one of `identifier` , `name` and `time_offset` `'expected value'` tests the output of the command run on the system versus the expected output stated in the test For example: describe timezone do its('identifier') { should eq 'Asia/Kolkata' } its('name') { should eq 'IST' } its('time_offset') { should eq '+0530' } end The `identifier` property verifies the time zone name of a system. An example of checking the identifier for the Asia/Kolkata time zone name: its('identifier') { should eq 'Asia/Kolkata' } The `name` property verifies the time zone of a system. {{< note >}} The `name` property accepts the time zone abbreviation on Linux systems and the full time zone name on Windows systems. {{< /note >}} An example of verifying that the time zone is set to IST on a Linux system: its('name') { should eq 'IST' } {{< note >}} Several time zones share the same time zone abbreviation. Use one of the other properties to verify a specific time zone with a common abbreviation. {{< /note >}} An example of verifying that the time zone is set to India Standard Time on a Windows system: its('name') { should eq 'India Standard Time' } The `time_offset` property verifies the time offset of a system from UTC (Coordinated Universal Time). An example of verifying that the time_offset is UTC+05:30: its('time_offset') { should eq '+0530' } {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: CDEvents (App Definition and Development / Streaming & Messaging)
File: cloudevents-binding.md

<!-- linkTitle: "CloudEvents Binding" weight: 100 hide_summary: true icon: "fa-solid fa-arrow-right-arrow-left" description: > CloudEvents Binding for CDEvents --> The CloudEvents Binding for CDEvents defines how CDEvents are mapped to CloudEvents headers and body. <!-- toc --> - - - - - <!-- /toc --> The CloudEvents context is built by the event producer using some of the data from the . The MUST be set to `1.0`. The . The . The of the CDEvent. The of the CDEvent. Note: since the subject is mandatory in CDEvents, the `subject` in the CloudEvents format will always be set - even if it's not mandated by the CloudEvents specification. The of the CDEvent. The CloudEvents specification allows for `time` to be set to either the current time or the time of the occurrence, but it requires all producers to be chose the same option. CDEvents requires all producers to use the `timestamp` from the CDEvent to meet the CloudEvents specification. The section for more details. The is MAY be set to a URL that points to the event data schema included in this specification. The content and format of the event data depends on the specific CloudEvents binding in use. All the examples, unless otherwise stated, refer to the in . In this format, the CloudEvents context is stored in HTTP headers. The MUST include the full CDEvents, i.e. , and any , rendered as JSON in the format specified by the for the event type. of type "application/json" MUST be embedded as is in the field. Data with any other content-type MUST be base64 encoded and set as value for the field. In CloudEvents HTTP binary mode, the `Content-Type` HTTP header MUST be set to `application/json`. In CloudEvents HTTP structured mode, the same information is carried in the CloudEvents context field `datacontenttype`. Full example of a CDEvents transported through a CloudEvent in HTTP binary mode: ```json POST /sink HTTP/1.1 Host: cdevents.example.com ce-specversion: 1.0 ce-type: dev.cdevents.taskrun.started.0.1.1 ce-time: 2018-04-05T17:31:00Z ce-id: A234-1234-1234 ce-source: /staging/tekton/ ce-subject: /namespace/taskrun-123 Content-Type: application/json; charset=utf-8 Content-Length: nnnn { "context": { "version": "0.3.0", "id" : "A234-1234-1234", "source" : "/staging/tekton/", "type" : "dev.cdevents.taskrun.started.0.1.1", "timestamp" : "2018-04-05T17:31:00Z", } "subject" : { "id": "/namespace/taskrun-123", "type": "taskRun", "content": { "task": "my-task", "url": "/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123" "pipelineRun": { "id": "/somewherelse/pipelinerun-123", "source": "/staging/jenkins/" } } } } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.153.md

layout: release date: 2023-10-01 tag: v0.6.153 Added info modal in meshery @Yashsharma1911 (#8912) Revert "Bump github.com/docker/cli from 20.10.21+incompatible to 24.0.6+incompatible" @theBeginner86 (#8990) Bump google.golang.org/api from 0.128.0 to 0.143.0 in /scripts/component_generation @dependabot (#8982) Bump github.com/layer5io/meshkit from 0.6.52 to 0.6.69 in /scripts/component_generation @dependabot (#8981) Bump golang.org/x/oauth2 from 0.9.0 to 0.12.0 in /scripts/component_generation @dependabot (#8980) Bump github.com/docker/cli from 20.10.21+incompatible to 24.0.6+incompatible @dependabot (#8978) Thank you to our contributors for making this release possible: @Aisuko, @Yashsharma1911, @dependabot, @dependabot[bot], @leecalcote and @theBeginner86
Project: Beam (App Definition and Development / Streaming & Messaging)
File: 17_advanced_ai_ml.md

Prompt: What are the AI and ML capabilities in Apache Beam? Response: Apache Beam has several built-in that enable you to: Process large datasets for both preprocessing and model inference. Conduct exploratory data analysis and smoothly scale up data pipelines in production as part of your MLOps ecosystem. Run your models in production with varying data loads, both in batch and streaming pipelines. For common AI platform integration patterns in Apache Beam, see . The recommended way to implement inference in Apache Beam is by using the . For more information about how to use RunInference for PyTorch, scikit-learn, and TensorFlow, see the example in GitHub. Using pre-trained models in Apache Beam is also supported with , , and . Running inference on is also supported. Apache Beam also supports automatically updating the model being used with the `RunInference PTransform` in streaming pipelines without stopping the pipeline. The feature lets you avoid downtime downtime. For more information, see . For more information about using machine learning models with Apache Beam, see . For an example that uses the Apache Beam ML integration, see .
Project: CloudTTY (App Definition and Development / Application Definition & Image Build)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: OpenYurt (Provisioning / Automation & Configuration)
File: GOVERNANCE.md

The governance model adopted in OpenYurt is influenced by many CNCF projects. Open: OpenYurt is open source community. See . Welcoming and respectful: See . Transparent and accessible: Work and collaboration should be done in public. Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles. The OpenYurt is aligned with the CNCF Code of Conduct. See Decisions are made based on consensus between maintainers. Proposals and ideas can either be submitted for agreement via a github issue or PR, or by sending an email to `openyurt@googlegroups.com`. In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background on the issue, but not involved in the conflict) to intercede and the final decision will be made. Decision making process should be transparent to adhere to the principles of OpenYurt project. Some contents in this documents have been borrowed from and and projects.
Project: ArangoDB (App Definition and Development / Database)
File: lazy.md

+++ title = "`lazy<T>/atomic_lazy<T>`" description = "A lazily evaluated coroutine awaitable with Outcome customisation." +++ This is very similar to {{% api "eager<T>" %}}, except that execution of the `lazy<T>` returning function suspends immediately. Functions which return `lazy<T>` are therefore suitable for tasks which you need to instantiate right now, but whose execution will occur elsewhere e.g. in a separate kernel thread. Because of the very common use case of using worker threads to execute the body of lazily executed coroutines, most people will want to use `atomic_lazy<T>` instead of `lazy<T>`. `atomic_lazy<T>` is like `lazy<T>`, except that the setting of the coroutine result performs an atomic release, whilst the checking of whether the coroutine has finished is an atomic acquire. `lazy<T>` has similar semantics to `std::lazy<T>`, which is being standardised. See https://wg21.link/P1056 Add lazy coroutine (coroutine task) type. Example of use (must be called from within a coroutinised function): ```c++ lazy<int> func(int x) { co_return x + 1; } ... // Always suspends perhaps causing other coroutines to execute, then resumes. int r = co_await func(5); ``` `lazy<T>` has special semantics if `T` is a type capable of constructing from an `exceptionptr` or `errorcode` -- any exceptions thrown during the function's body are sent via `T`, preferably via the error code route if {{% api "errorfromexception(" %}}`)` successfully matches the exception throw. This means that a {{% api "basicresult<T, E, NoValuePolicy>" %}} or {{% api "basicoutcome<T, EC, EP, NoValuePolicy>" %}} where one of its types is is compatible will have its `.error()` or `.exception()` set. Note that `lazy<T>` does not otherwise transport exception throws, and rethrows any exceptions thrown within the coroutine body through the coroutine machinery. This does not produce reliable consequences in current C++ compilers. You should therefore wrap the coroutine body in a `try...catch` if `T` is not able to transport exceptions on its own. Requires: C++ coroutines to be available in your compiler. Namespace: `BOOSTOUTCOMEV2_NAMESPACE::awaitables` Header: `<boost/outcome/coroutine_support.hpp>`
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_cleanup_images.md

title: "Command - devspace cleanup images" sidebar_label: devspace cleanup images Deletes all locally created images from docker ``` devspace cleanup images [flags] ``` ``` Deletes all locally created docker images from docker ``` ``` -h, --help help for images ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --disable-profile-activation If true will ignore all profile activations --inactivity-timeout int Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems (default 180) --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile strings The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified --profile-parent strings One or more profiles that should be applied before the specified profile (e.g. devspace dev --profile-parent=base1 --profile-parent=base2 --profile=my-profile) --profile-refresh If true will pull and re-download profile parent sources --restore-vars If true will restore the variables from kubernetes before loading the config --save-vars If true will save the variables to kubernetes after loading the config --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context DEPRECATED: Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) --vars-secret string The secret to restore/save the variables from/to, if --restore-vars or --save-vars is enabled (default "devspace-vars") ```
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-generate-spec.1.md

% podman-generate-spec 1 podman\-generate\-spec - Generate Specgen JSON based on containers or pods podman generate spec [options] container | pod* podman generate spec generates SpecGen JSON from Podman Containers and Pods. This JSON can be printed to a file, directly to the command line, or both. This JSON can then be used as input for the Podman API, specifically for Podman container and pod creation. Specgen is Podman's internal structure for formulating new container-related entities. Print the output in a compact, one line format. This is useful when piping the data to the Podman API Output to the given file. Rename the pod or container, so that it does not conflict with the existing entity. This is helpful when the JSON is to be used before the source pod or container is deleted.
Project: KICS (Provisioning / Security & Compliance)
File: c407c3cf-c409-4b29-b590-db5f4138d332.md

title: PostgreSQL Server Threat Detection Policy Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: c407c3cf-c409-4b29-b590-db5f4138d332 Query name: PostgreSQL Server Threat Detection Policy Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Resource Management URL: PostgreSQL Server Threat Detection Policy should be enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="22" resource "azurermpostgresqlserver" "positive1" { name = "example-psqlserver" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name administrator_login = "psqladminun" administratorloginpassword = "H@Sh1CoR3!" skuname = "GPGen5_4" version = "9.6" storage_mb = 640000 backupretentiondays = 7 georedundantbackup_enabled = true autogrowenabled = true publicnetworkaccess_enabled = false sslenforcementenabled = true sslminimaltlsversionenforced = "TLS1_2" threatdetectionpolicy { enabled = false } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" resource "azurermpostgresqlserver" "positive2" { name = "example-psqlserver" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name administrator_login = "psqladminun" administratorloginpassword = "H@Sh1CoR3!" skuname = "GPGen5_4" version = "9.6" storage_mb = 640000 backupretentiondays = 7 georedundantbackup_enabled = true autogrowenabled = true publicnetworkaccess_enabled = false sslenforcementenabled = true sslminimaltlsversionenforced = "TLS1_2" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermpostgresqlserver" "negative" { name = "example-psqlserver" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name administrator_login = "psqladminun" administratorloginpassword = "H@Sh1CoR3!" skuname = "GPGen5_4" version = "9.6" storage_mb = 640000 backupretentiondays = 7 georedundantbackup_enabled = true autogrowenabled = true publicnetworkaccess_enabled = false sslenforcementenabled = true sslminimaltlsversionenforced = "TLS1_2" threatdetectionpolicy { enabled = true } } ```
Project: YDB (App Definition and Development / Database)
File: dump.md

Using the `tools dump` subcommand, you can save a snapshot of a specific table, database schema, or database folder with all nested objects locally. General command format: ```bash {{ ydb-cli }} [global options...] tools dump [options...] ``` `global options`: . `options`: . View a description of the command to create a dump: ```bash {{ ydb-cli }} tools dump --help ``` | Parameter name | Parameter description | | | | | `-p <value>`<br/>`--path <value>` | The path to the folder or table to create a dump of.<br/>By default, a full DB dump will be made. | | `-o <value>`<br/>`--output <value>` | Required parameter.<br/>The path on the local file system where the dump objects will be placed.<br/>The dump folder must not exist or must be empty. | | `--scheme-only` | Make a dump of the DB schema only. | | `--avoid-copy` | Don't make a copy.<br/>By default, to reduce the impact on the user load and for data consistency, {{ ydb-short-name }} first makes a copy of the table and then dumps the copy. In some cases, for example, when dumping tables with external blobs, this approach isn't supported. | | `--save-partial-result` | Save the results of an incomplete dump.<br/>When this option is selected, all the data written before the operation was interrupted is saved. | | `--consistency-level <value>` | Consistency level.<br/>A data dump with a consistency level at the DB level takes longer and is more likely to impact the user load. Possible values:<br/><ul><li>`database`: Consistency at the DB level.</li><li>`table`: Consistency at the table level.</li></ul>The default value is `database`. | Create a dump of the `seasons` table in the local folder `~/dump` with consistency at the table level: ```bash {{ ydb-cli }} tools dump \ --path seasons \ --output ~/dump \ --consistency-level table ``` View a list of objects in the `dump` folder: ```bash ls -R ~/dump ``` Result: ```text /home/user/dump: episodes my-directory seasons series /home/user/dump/episodes: data_00.csv scheme.pb /home/user/dump/my-directory: sub-directory1 sub-directory2 /home/user/dump/my-directory/sub-directory1: sub-directory1-1 /home/user/dump/my-directory/sub-directory1/sub-directory1-1: /home/user/dump/my-directory/sub-directory2: /home/user/dump/seasons: data_00.csv scheme.pb /home/user/dump/series: data_00.csv scheme.pb ```
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_core.BadgeRegistration.md

/ / BadgeRegistration .BadgeRegistration Interpretation: if the resource passes the given "when" filter, then add the given sidecar badge | Name | Type | | : | :-- | | `Resource` | extends | badge: \| (`resource`: `Resource`, `tab`: ) => when: <`Resource`\>