cwielenb/CNCF-Dataset huggingface dataset:
Project: Druid (App Definition and Development / Database)
File: update.md

id: update title: "Data updates" <!-- ~ Licensed to the Apache Software Foundation (ASF) under one ~ or more contributor license agreements. See the NOTICE file ~ distributed with this work for additional information ~ regarding copyright ownership. The ASF licenses this file ~ to you 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. --> Apache Druid stores data and supports overwriting existing data using time ranges. Data outside the replacement time range is not touched. Overwriting of existing data is done using the same mechanisms as . For example: with `appendToExisting: false`, and `intervals` set to a specific time range, overwrites data for that time range. overwrites data for the entire table or for a specified time range. In both cases, Druid's atomic update mechanism ensures that queries will flip seamlessly from the old data to the new data on a time-chunk-by-time-chunk basis. Ingestion and overwriting cannot run concurrently for the same time range of the same datasource. While an overwrite job is ongoing for a particular time range of a datasource, new ingestions for that time range are queued up. Ingestions for other time ranges proceed as normal. Read-only queries also proceed as normal, using the pre-existing version of the data. :::info Druid does not support single-record updates by primary key. ::: Reindexing is an where the source of new data is the existing data itself. It is used to perform schema changes, repartition data, filter out unwanted data, enrich existing data, and so on. This behaves just like any other with regard to atomic updates and locking. With , use the [`druid` input source](../ingestion/input-sources.md#druid-input-source). If needed, can be used to filter or modify data during the reindexing job. With SQL, use with `SELECT ... FROM <table>`. (Druid does not have `UPDATE` or `ALTER TABLE` statements.) Any SQL SELECT query can be used to filter, modify, or enrich the data during the reindexing job. Rolled-up datasources can be effectively updated using appends, without rewrites. When you append a row that has an identical set of dimensions to an existing row, queries that use aggregation operators automatically combine those two rows together at query time. or can be used to physically combine these matching rows together later on, by rewriting segments in the background. If you have a dimension where values need to be updated frequently, try first using . A classic use case of lookups is when you have an ID dimension stored in a Druid segment, and want to map the ID dimension to a human-readable string that may need to be updated periodically.
Project: YDB (App Definition and Development / Database)
File: how_it_works.md

Fully explaining how YDB works in detail takes quite a while. Below you can review several key highlights and then continue exploring documentation to learn more. YDB clusters typically run on commodity hardware with shared-nothing architecture. If you look at YDB from a bird's eye view, you'll see a layered architecture. The compute and storage layers are disaggregated, they can either run on separate sets of nodes or be co-located. One of the key building blocks of YDB's compute layer is called a tablet. They are stateful logical components implementing various aspects of YDB. The next level of detail of overall YDB architecture is explained in the . From the user's perspective, everything inside YDB is organized in a hierarchical structure using directories. It can have arbitrary depth depending on how you choose to organize your data and projects. Even though YDB does not have a fixed hierarchy depth like in other SQL implementations, it will still feel familiar as this is exactly how any virtual filesystem looks like. YDB provides users with a well-known abstraction: tables. In YDB tables must contain a primary key, the data is physically sorted by the primary key. Tables are automatically sharded by primary key ranges by size or load. Each primary key range of a table is handled by a specific tablet called data shard. Data shards will automatically split into more ones as the load increases. They automatically merge back to the appropriate number when the peak load goes away. .png) Data shards also will automatically split when the data size increases. They automatically merge back if enough data will be deleted. YDB evenly distributes tablets among available nodes. It moves heavily loaded tablets from overloaded nodes. CPU, Memory, and Network metrics are tracked to facilitate this. YDB doesn't rely on any third-party filesystem. It stores data by directly working with disk drives as block devices. All major disk kinds are supported: NVMe, SSD, or HDD. The PDisk component is responsible for working with a specific block device. The abstraction layer above PDisk is called VDisk. There is a special component called DSProxy between a tablet and VDisk. DSProxy analyzes disk availability and characteristics and chooses which disks will handle a request and which won't. A common fault-tolerant setup of YDB spans 3 datacenters or availability zones (AZ). When YDB writes data to 3 AZ, it doesnt send requests to obviously bad disks and continues to operate without interruption even if one AZ and a disk in another AZ are lost.
Project: ArangoDB (App Definition and Development / Database)
File: eager.md

+++ title = "`eager<T>/atomic_eager<T>`" description = "An eagerly evaluated coroutine awaitable with Outcome customisation." +++ This is very similar to {{% api "lazy<T>" %}}, except that execution of the `eager<T>` returning function begins immediately, and if the function never suspends during the course of its execution, no suspend-resume cycle occurs. Functions which return `eager<T>` are therefore suitable for tasks which may require suspension, but will often complete immediately. `atomic_eager<T>` is like `eager<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. Example of use (must be called from within a coroutinised function): ```c++ eager<int> func(int x) { co_return x + 1; } ... // Executes like a non-coroutine function i.e. r is immediately set to 6. int r = co_await func(5); ``` `eager<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 `eager<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: Chef InSpec (Provisioning / Security & Compliance)
File: google_organization_iam_policy.md

+++ title = "googleorganizationiam_policy resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleorganizationiam_policy" identifier = "inspec/resources/gcp/googleorganizationiampolicy.md googleorganizationiampolicy resource" parent = "inspec/resources/gcp" +++ A `googleorganizationiam_policy` is used to test a Google Organization Iam Policy resource ```ruby describe googleorganizationiam_policy(name: "name") do it { should exist } end googleorganizationiam_policy(name: "name").bindings.each do |binding| describe binding do its('role') { should eq 'roles/editor'} its('members') { should include 'user:testuser@example.com'} end end ``` Properties that can be accessed from the `googleorganizationiam_policy` resource: `iambindingroles` : The list of roles that exist on the policy. `bindings` : Associates a list of members to a role. `role` : Role that is assigned to members. For example, roles/viewer, roles/editor, or roles/owner. `members` : Specifies the identities requesting access for a Cloud Platform resource. `audit_configs` : Specifies cloud audit logging configuration for this policy. `service` : Specifies a service that will be enabled for audit logging. For example, `storage.googleapis.com`, `cloudsql.googleapis.com`. `allServices` is a special value that covers all services. `auditlogconfigs` : The configuration for logging of each type of permission. `log_type` : The log type that this config enables. For example, ADMINREAD, DATAWRITE or DATA_READ `exempted_members` : Specifies the identities that do not cause logging for this type of permission. Ensure the is enabled for the current project.
Project: Clair (Provisioning / Security & Compliance)
File: code-of-conduct.md

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 through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. 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, or nationality. 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 others' private information, such as physical or electronic addresses, without explicit permission 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. 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 may be reported by contacting a project maintainer, Brandon Philips <brandon.philips@coreos.com>, and/or Rithu John <rithu.john@coreos.com>. This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 1.2.0, available at http://contributor-covenant.org/version/1/2/0/ CoreOS events are working conferences intended for professional networking and collaboration in the CoreOS community. Attendees are expected to behave according to professional standards and in accordance with their employers policies on appropriate workplace behavior. While at CoreOS events or related social networking opportunities, attendees should not engage in discriminatory or offensive speech or actions including but not limited to gender, sexuality, race, age, disability, or religion. Speakers should be especially aware of these concerns. CoreOS does not condone any statements by speakers contrary to these standards. CoreOS reserves the right to deny entrance and/or eject from an event (without refund) any individual found to be engaging in discriminatory or offensive speech or actions. Please bring any concerns to the immediate attention of designated on-site staff, Brandon Philips <brandon.philips@coreos.com>, and/or Rithu John <rithu.john@coreos.com>.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: operator-sdk_olm_uninstall.md

title: "operator-sdk olm uninstall" Uninstall Operator Lifecycle Manager from your cluster ``` operator-sdk olm uninstall [flags] ``` ``` -h, --help help for uninstall --olm-namespace string namespace from where OLM is to be uninstalled. (default "olm") --timeout duration time to wait for the command to complete before failing (default 2m0s) --version string version of OLM resources to uninstall. ``` ``` --plugins strings plugin keys to be used for this subcommand execution --verbose Enable verbose logging ``` - Manage the Operator Lifecycle Manager installation in your cluster
Project: KICS (Provisioning / Security & Compliance)
File: fb387023-e4bb-42a8-9a70-6708aa7ff21b.md

title: Nifcloud RDB Has Public DB Access hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fb387023-e4bb-42a8-9a70-6708aa7ff21b Query name: Nifcloud RDB Has Public DB Access Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: The rdb has public db access<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "nifclouddbinstance" "positive" { identifier = "example" instance_class = "db.large8" publicly_accessible = true } ``` ```tf title="Negative test num. 1 - tf file" resource "nifclouddbinstance" "negative" { identifier = "example" instance_class = "db.large8" publicly_accessible = false } ```
Project: BigchainDB (App Definition and Development / Database)
File: LICENSES.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 > Information about how the BigchainDB Server code and documentation are licensed can be found in of the bigchaindb/bigchaindb repository on GitHub.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.27.md

layout: release date: 2022-11-15 tag: v0.6.27 language: en [CI] Adding custom callback URL for playground @leecalcote (#6536) removed modal-like focus on popup @franklinekoh (#6534) [Provider-UI] Revert from v5 to v4 of styled-jsx @leecalcote (#6537) Thank you to our contributors for making this release possible: @MUzairS15, @franklinekoh and @leecalcote
Project: StarRocks (App Definition and Development / Database)
File: filemanager.md

displayed_sidebar: "English" With file manager, you can create, view, and delete files, such as the files that are used to access external data sources: public key files, private key files, and certificate files. You can reference or access the created files by using commands. File: refers to the file that is created and saved in StarRocks. After a file is created and stored in StarRocks, StarRocks assigns a unique ID to the file. You can find a file based on the database name, catalog, and file name. In a database, only an admin user can create and delete files, and all users who have permissions to access a database can use the files that belong to the database. Configure the following parameters for each FE. `smallfiledir`: the path in which the uploaded files are stored. The default path is `small_files/`, which is in the runtime directory of the FE. You need to specify this parameter in the fe.conf file and then restart the FE to allow the change to take effect. `maxsmallfilesizebytes`: the maximum size of a single file. The default value of this parameter is 1 MB. If the size of a file exceeds the value of this parameter, the file cannot be created. You can specify this parameter by using the statement. `maxsmallfile_number`: the maximum number of files that can be created within a cluster. The default value of this parameter is 100. If the number of files that you have created reaches the value of this parameter, you cannot continue creating files. You can specify this parameter by using the ADMIN SET CONFIG statement. Note: Increasing the values of the two parameters causes an increase in the memory usage of the FE. Therefore, we recommend that you do not increase the values of the two parameters unless necessary. Configure the following parameters for each BE. `smallfiledir`: the path in which the downloaded files are stored. The default path is `lib/small_files/`, which is in the runtime directory of the BE. You can specify this parameter in the be.conf file. You can execute the CREATE FILE statement to create a file. For more information, see . After a file is created, the file is uploaded and persisted in StarRocks. You can execute the SHOW FILE statement to view the information about a file stored in a database. For more information, see . You can execute the DROP FILE statement to delete a file. For more information, see . FE: The SmallFileMgr class stores the data related to the file in the specified directory of the FE. Then the SmallFileMgr class returns a local file path for the FE to use the file. BE: The BE calls the /api/get_small_file API (HTTP) to download the file to its specified directory and record the information of the file. When the BE requests to use the file, the BE checks whether the file has been downloaded and then verifies the file. If the file pass the verification, the path of the file is returned. If the file fails the verification, the file is deleted and re-downloaded from the FE. When a BE restarts, it preloads the downloaded file into its memory.
Project: Harbor (Provisioning / Container Registry)
File: 2-11-LDAP-user-create-project.md

Test 2-11 - User Create Project (LDAP Mode) ======= To verify that a non-admin user can create projects in (LDAP mode). User guide This test requires that a Harbor instance is running and available. Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to ldap_auth* .) The user data is stored in an LDAP or AD server. A linux host with Docker CLI installed (Docker client). At least two non-admin users are in Harbor. Same as Test 2-01 except that users are from LDAP/AD. Same as Test 2-01. None
Project: ClickHouse (App Definition and Development / Database)
File: use.md

slug: /en/sql-reference/statements/use sidebar_position: 53 sidebar_label: USE ``` sql USE db ``` Lets you set the current database for the session. The current database is used for searching for tables if the database is not explicitly defined in the query with a dot before the table name. This query cant be made when using the HTTP protocol, since there is no concept of a session.
Project: Harbor (Provisioning / Container Registry)
File: 7-03-Proj-replication-rules-delete.md

Test 7-03 Delete replication rules ======= To verify that an admin user can delete replication rules. User guide This test requires that a Harbor instance is running and available. Login as admin user. In `Administration->Replications` page,delete a rule which has no pending/running/retrying jobs. Delete a rule which has pending/running/retrying jobs. Repeat steps 1-3 under `Projects->Project_Name->Replication` page. In step2 rule can be deleted. In step3 rule can not be deleted. None
Project: Podman (App Definition and Development / Application Definition & Image Build)
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 behaviour 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 behaviour 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 behaviour and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behaviour. 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 behaviours 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 . 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 Contributor Covenant, version 1.4, available at .
Project: Carvel (App Definition and Development / Application Definition & Image Build)
File: README_Cognito.md

The following is a sample Lambda function that receives Amazon Cognito Sync event record data as an input and writes some of the record data to CloudWatch Logs. (Note that anything written to stdout or stderr will be logged as CloudWatch Logs events.) ```go package main import ( "fmt" "github.com/aws/aws-lambda-go/lambda" "github.com/aws/aws-lambda-go/events" ) func handler(cognitoEvent events.CognitoEvent) error { for datasetName, datasetRecord := range cognitoEvent.DatasetRecords { fmt.Printf("[%s -- %s] %s -> %s -> %s \n", cognitoEvent.EventType, datasetName, datasetRecord.OldValue, datasetRecord.Op, datasetRecord.NewValue) } return nil } func main() { lambda.Start(handler) } ```