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

+++ title = "`BOOSTOUTCOMECO_TRYV2(spec, expr)`" description = "Evaluate an expression which results in an understood type, continuing execution if successful, immediately returning `tryoperationreturn_as(X)` from the calling function if unsuccessful." +++ Evaluate an expression which results in a type matching the following customisation points, continuing execution if successful, immediately returning {{% api "tryoperationreturn_as(X)" %}} from the calling function if unsuccessful: `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationhasvalue(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationreturnas(X)" %}} `BOOSTOUTCOMEV2NAMESPACE::`{{% api "tryoperationextractvalue(X)" %}} Default overloads for these customisation points are provided. See . Hints are given to the compiler that the expression will be successful. If you expect failure, you should use {{% api "BOOSTOUTCOMETRYV2FAILURELIKELY(spec, expr)" %}} instead. Overridable: Not overridable. Definition: Firstly the expression's temporary is bound to a uniquely named, stack allocated, `spec`. If that reference's bound object's `tryoperationhasvalue()` is false, immediately execute `return tryoperationreturnas(propagated unique reference);`, propagating the rvalue/lvalue/etc-ness of the original expression. Header: `<boost/outcome/try.hpp>`
Project: ClickHouse (App Definition and Development / Database)
File: role.md

slug: /en/sql-reference/statements/create/role sidebar_position: 40 sidebar_label: ROLE title: "CREATE ROLE" Creates new . Role is a set of . A assigned a role gets all the privileges of this role. Syntax: ``` sql CREATE ROLE [IF NOT EXISTS | OR REPLACE] name1 [ON CLUSTER clustername1] [, name2 [ON CLUSTER clustername2] ...] [IN accessstoragetype] [SETTINGS variable [= value] [MIN [=] minvalue] [MAX [=] maxvalue] [CONST|READONLY|WRITABLE|CHANGEABLEINREADONLY] | PROFILE 'profile_name'] [,...] ``` A user can be assigned multiple roles. Users can apply their assigned roles in arbitrary combinations by the statement. The final scope of privileges is a combined set of all the privileges of all the applied roles. If a user has privileges granted directly to its user account, they are also combined with the privileges granted by roles. User can have default roles which apply at user login. To set default roles, use the statement or the statement. To revoke a role, use the statement. To delete role, use the statement. The deleted role is being automatically revoked from all the users and roles to which it was assigned. ``` sql CREATE ROLE accountant; GRANT SELECT ON db.* TO accountant; ``` This sequence of queries creates the role `accountant` that has the privilege of reading data from the `db` database. Assigning the role to the user `mira`: ``` sql GRANT accountant TO mira; ``` After the role is assigned, the user can apply it and execute the allowed queries. For example: ``` sql SET ROLE accountant; SELECT FROM db.; ```
Project: FOSSA (Provisioning / Security & Compliance)
File: c-cpp.md

When developing C and C++ projects, no standard package manager is used. Consequently, we use statistical analysis of the project to determine likely vendored dependencies, and support inspecting output binaries for dynamically linked dependencies on some platforms. | Strategy | Direct Deps | Transitive Deps | Edges | Container Scanning | |-|--|--|-|--| | `detect-vendored` | :whitecheckmark: | :x: | :x: | :x: | | `detect-dynamic` | :whitecheckmark: | :whitecheckmark: | :x: | :x: | `detect-vendored`: The root of the scan directory is assumed to be the only "project". `detect-dynamic`: The binary indicated by the argument is assumed to be the only "project". `detect-vendored`: Run `fossa analyze --detect-vendored`. To only detect vendored dependencies, run `fossa analyze --detect-vendored --only-target vsi`. `detect-dynamic`: Run `fossa analyze --detect-dynamic <BINARY_PATH>`. This inspects the binary at `BINARY_PATH` for dynamically linked dependencies. This requires specific platform support, see extended documentation under further reading. Further reading: in in
Project: Meshery (Provisioning / Automation & Configuration)
File: 10-31-2023-04-00-10_d2f1b165.md

timestamp: "2023-10-31 04:00:04 UTC Tue" meshery-component: meshery-consul meshery-component-version: v1.0.0 meshery-server-version: "*name" k8s-distro: minikube k8s-version: "v1.21.5" service-mesh: Consul service-mesh-version: "v1.2.2" tests: consul-client: null consul-server: null overall-status: "failing"
Project: ShardingSphere (App Definition and Development / Database)
File: archetypes.en.md

title: Archetypes weight: 10 Using the command: `hugo new . It is pre-configured skeleton pages with default front matter. Please refer to the documentation for types of page to understand the differences. To create a Chapter page, run the following commands ``` hugo new --kind chapter <name>/_index.md ``` It will create a page with predefined Front-Matter: ```markdown +++ title = "{{ replace .Name "-" " " | title }}" date = {{ .Date }} weight = 5 chapter = true pre = "<b>X. </b>" +++ Lorem Ipsum. ``` To create a default page, run either one of the following commands ``` hugo new <chapter>/<name>/_index.md hugo new <chapter>/<name>.md ``` It will create a page with predefined Front-Matter: ```markdown +++ title = "{{ replace .Name "-" " " | title }}" date = {{ .Date }} weight = 5 +++ Lorem Ipsum. ```
Project: ClickHouse (App Definition and Development / Database)
File: v21.7.3.14-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix sharding_key from column w/o function for remote() (before `select from remote('127.1', system.one, dummy)` leads to `Unknown column: dummy, there are only columns .` error). (). Backported in : Fix rare server crash because of `abort` in ZooKeeper client. Fixes . (). Backported in : Fix possible crash in `pointInPolygon` if the setting `validate_polygons` is turned off. (). Backported in : Fix `joinGet` with LowCarinality columns, close . (). Backported in : Fix potential crash if more than one `untuple` expression is used. (). Backported in : Remove excessive newline in `threadname` column in `system.stacktrace` table. This fixes . (). Fix throwing exception when iterate over non existing remote directory. (). Remove misleading stderr output ().
Project: StarRocks (App Definition and Development / Database)
File: SHOW_DYNAMIC_PARTITION_TABLES.md

displayed_sidebar: "English" This statement is used to display the status of all the partitioned tables for which dynamic partitioning properties are configured in a database. ```sql SHOW DYNAMIC PARTITION TABLES FROM <db_name> ``` This statement returns the following fields: TableName: the name of the table. Enable: whether dynamic partitioning is enabled. TimeUnit: the time granularity for the partitions. Start: the starting offset of dynamic partitioning. End: the end offset of dynamic partitioning. Prefix: the prefix of the partition name. Buckets: the number of buckets per partition. ReplicationNum: the number of replicas for the table. StartOf LastUpdateTime: the time when the table was last updated. LastSchedulerTime: the time when data in the table was last scheduled. State: the status of the table. LastCreatePartitionMsg: the message for the latest partition creation operation. LastDropPartitionMsg: the message for the latest partition dropping operation. Display the status of all the partitioned tables for which dynamic partitioning properties are configured in `db_test`. ```sql SHOW DYNAMIC PARTITION TABLES FROM db_test; ```
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_add_sync.md

title: "Command - devspace add sync" sidebar_label: devspace add sync Add a sync path ``` devspace add sync [flags] ``` ``` Add a sync path to this project's devspace.yaml Example: devspace add sync --local=app --container=/app ``` ``` --container string Absolute container path --exclude string Comma separated list of paths to exclude (e.g. node_modules/,bin,*.exe) -h, --help help for sync --label-selector string Comma separated key=value selector list (e.g. release=test) --local string Relative local path ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --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 string The devspace profile to use (if there is any) --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context 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) ```
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: filesystem-pv-disks.md

So far Kubernetes PersistentVolumes are remote file-systems attached to a pod at runtime. This is currently the only way of exposing remote or local storage to pods, through a file-system. Despite the fact that storage is exposed as file-systems to pod, KubeVirt has no mechanism to use these plain file-system based PVs to act as backends for virtual disks. This proposal is about adding a simple mechanism to allow using file-system based PersistentVolumes for storing file images backing virtual disks. The focus is primarily on providing the right cluster levels mechanics to enable future changes for improving usability, performance, or other characteristics. Provide a totally automatic solution Cover snapshots explicitly The primary use-case is to allow a VMI to use PVs as backend storage for their virtual disks. The mechanism proposed in this proposal is leveraging Kubernetes to attach the remote storage as a file-system to a container, to use this file-system to store a disk image to act as a backend storage to the VMI's disk. To keep the story compatibility between the block and file-system storage, this proposal assumes that the file-system based storage will also just support a 1:1 mapping between the virtual disk and volume. This aligns with the fact that a block volume can also just back a single virtual disk. The general API to use PersistentVolume claims as virtual disk backends was introduced with . The change suggested by this proposal, does not require any API change. To use a PV as a virtual disk backend, a user needs to create a claim for the required PV, this claim is then used as a disk source for a virtual disk. An example: ```yaml kind: VMI spec: domain: devices: disks: name: root-disk volumeName: my-fs-store volumes: name: my-fs-store persistentVolumeClaim: my-fs-claim ``` Here the user attaches the PersistentVolumeClaim `my-fs-claim` as a disk to a VMI. The system needs to know if the referenced volume needs to be treated as a block or file-system volume. Since Kubernetes 1.9 this information can be inferred from the existing PV metadata. A file-system based volume will contain only a single image file, this file must be named `disk.img`. The format of the file must be `raw`. The file-system layout of a mounted volume then looks like: ``` /disk.img ``` In future we might want to add additional files to carry metadata, but the limit of a single image file per volume must not be changed. Virtfs might allow us to directly use file-systems as a backing store for virtual machines. This API design should not contradict with this use-case, but it will probably depend on the `driver` field mentioned above to signal the system how the PV has to be consumed (mounted).
Project: KICS (Provisioning / Security & Compliance)
File: d31cb911-bf5b-4eb6-9fc3-16780c77c7bd.md

title: CloudFront Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: d31cb911-bf5b-4eb6-9fc3-16780c77c7bd Query name: CloudFront Logging Disabled Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: AWS CloudFront distributions should have logging enabled to collect all viewer requests, which means the attribute 'logging' should be defined with 'enabled' set to true<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="2 62" name: create a distribution with an origin, logging and default cache behavior community.aws.cloudfront_distribution: state: present caller_reference: unique test distribution ID origins: id: 'my test origin-000111' domain_name: www.example.com origin_path: /production custom_headers: header_name: MyCustomHeaderName header_value: MyCustomHeaderValue defaultcachebehavior: targetoriginid: 'my test origin-000111' forwarded_values: query_string: true cookies: forward: all headers: '*' viewerprotocolpolicy: allow-all smooth_streaming: true compress: true allowed_methods: items: GET HEAD cached_methods: GET HEAD enabled: false comment: this is a CloudFront distribution with logging name: create a second distribution with an origin, logging and default cache behavior community.aws.cloudfront_distribution: state: present caller_reference: unique test distribution ID origins: id: 'my test origin-000111' domain_name: www.example.com origin_path: /production custom_headers: header_name: MyCustomHeaderName header_value: MyCustomHeaderValue defaultcachebehavior: targetoriginid: 'my test origin-000111' forwarded_values: query_string: true cookies: forward: all headers: '*' viewerprotocolpolicy: allow-all smooth_streaming: true compress: true allowed_methods: items: GET HEAD cached_methods: GET HEAD logging: enabled: false include_cookies: false bucket: mylogbucket.s3.amazonaws.com prefix: myprefix/ enabled: false comment: this is a CloudFront distribution with logging ``` ```yaml title="Negative test num. 1 - yaml file" name: create a distribution with an origin, logging and default cache behavior community.aws.cloudfront_distribution: state: present caller_reference: unique test distribution ID origins: id: my test origin-000111 domain_name: www.example.com origin_path: /production custom_headers: header_name: MyCustomHeaderName header_value: MyCustomHeaderValue defaultcachebehavior: targetoriginid: my test origin-000111 forwarded_values: query_string: true cookies: forward: all headers: '*' viewerprotocolpolicy: allow-all smooth_streaming: true compress: true allowed_methods: items: GET HEAD cached_methods: GET HEAD logging: enabled: true include_cookies: false bucket: mylogbucket.s3.amazonaws.com prefix: myprefix/ enabled: false comment: this is a CloudFront distribution with logging ```
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: 1.5.md

We cannot wait for you to try our new features: Brand new templates to help you get started with creating resources. Create and manage projects. Find support for Istio and Cert-Manager CRDs. New Kubernetes Secret Editor. Improved Form Editors. Quick-search Popup to quickly create a filter or select resources. Dynamic Validation and Form editors for discovered CRDs. Improved Link identification and Validation. Brand new Getting Started Page to help you getting onboard. And some more!
Project: Keycloak (Provisioning / Security & Compliance)
File: README-keystores-format-conversion.md

How to convert keystores and truststores Magic command to import PKCS12 keystore to BCFKS ``` keytool -importkeystore -srckeystore keycloak-fips.keystore.pkcs12 -destkeystore keycloak-fips.keystore.bcfks \ -srcstoretype PKCS12 -deststoretype BCFKS -deststorepass passwordpassword \ -providername BCFIPS \ -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \ -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \ -providerpath $MAVENREPOHOME/org/bouncycastle/bc-fips/1.0.2.3/bc-fips-1.0.2.3.jar \ -J-Djava.security.properties=$KEYCLOAK_SOURCES/testsuite/integration-arquillian/servers/auth-server/common/fips/kc.keystore-create.java.security ``` Default password is `passwordpassword`. When converting from `JKS` to `PKCS12` on non-FIPS host, only first 2 lines from this command are needed (no need to use BCFIPS provider). Original JKS keystore, which was used to create `PKCS12` (and transitively also `BCFKS`) keystore is . Original JKS truststore is .
Project: StarRocks (App Definition and Development / Database)
File: base64_decode_string.md

displayed_sidebar: "English" This function is the same as . Decodes a Base64-encoded string. and an inverse of . This function is supported from v3.0. ```Haskell base64decodestring(str); ``` `str`: the string to decode. It must be of the VARCHAR type. Returns a value of the VARCHAR type. If the input is NULL or an invalid Base64 string, NULL is returned. If the input is empty, an error is returned. This function accepts only one string. More than one input string causes an error. ```Plain Text mysql> select base64decodestring(to_base64("Hello StarRocks")); +-+ | base64decodestring(to_base64('Hello StarRocks')) | +-+ | Hello StarRocks | +-+ ```
Project: YDB (App Definition and Development / Database)
File: table-drop.md

Using the `table drop` subcommand, you can delete a specified table. General format of the command: ```bash {{ ydb-cli }} [global options...] table drop [options...] <table path> ``` `global options`: . `options`: . `table path`: The table path. To view a description of the table delete command: ```bash {{ ydb-cli }} table drop --help ``` | Name | Description | | | `--timeout` | The time within which the operation should be completed on the server. | {% include %} To delete the table `series`: ```bash {{ ydb-cli }} -p quickstart table drop series ```
Project: YDB (App Definition and Development / Database)
File: prepare-configs.md

Prepare a configuration file for {{ ydb-short-name }}: Download a sample config for the appropriate failure model of your cluster: : For a single-data center cluster. : For a cross-data center cluster consisting of 9 nodes. : For a cross-data center cluster consisting of 3 nodes. In the `host_configs` section, specify all disks and their types on each cluster node. Possible disk types: ROT: Rotational, HDD. SSD: SSD or NVMe. ```json host_configs: drive: path: /dev/disk/by-partlabel/ydbdiskssd_01 type: SSD hostconfigid: 1 ``` In the `hosts` section, specify the FQDN of each node, their configuration and location in a `data_center` or `rack`: ```json hosts: host: node1.ydb.tech hostconfigid: 1 walle_location: body: 1 data_center: 'zone-a' rack: '1' host: node2.ydb.tech hostconfigid: 1 walle_location: body: 2 data_center: 'zone-b' rack: '1' host: node3.ydb.tech hostconfigid: 1 walle_location: body: 3 data_center: 'zone-c' rack: '1' ``` Under `blobstorageconfig`, edit the FQDNs ofall the nodesaccommodating your static storage group: For the `mirror-3-dc` scheme, specify FQDNs for nine nodes. For the `block-4-2` scheme, specify FQDNs for eight nodes. Enable user authentication (optional). If you plan to use authentication and user access differentiation features in the {{ ydb-short-name }} cluster, add the following parameters to the `domains_config` section: ```json domains_config: security_config: enforceusertoken_requirement: true monitoringallowedsids: "root" "ADMINS" "DATABASE-ADMINS" administrationallowedsids: "root" "ADMINS" "DATABASE-ADMINS" viewerallowedsids: "root" "ADMINS" "DATABASE-ADMINS" ```
Project: kpt (Provisioning / Automation & Configuration)
File: 03-generation.md

When using template languages I am able to provide conditional statements based on parameter values. This allows me to ask the user for a little bit of information and generate a lot of boilerplate configuration. Some template languages like [Jinja] are very robust and feature rich. Increased usage and additional edge cases make a template a piece of code that requires testing and debugging. The interplay between different conditionals and loops is interleaved in the template making it hard to understand what exactly is configuration and what is the logic that alters the configuration. The consumer is left with one choice supply different parameter values, execute the template rendering code and see what happens. Templates are generally monolithic, when a change is introduced the package consumers need to either pay the cost of updating or the new consumers pay the cost of having to decipher more optional parameters. When the generated configuration is simple consider just using a sub-package and running customizations using [single value replacement] techniques. When a complex configuration needs to be generated the package author can create a generator function using turing complete languages and debugging tools. Example of such a function is [folder generation]. The output of the function is plain old KRM.
Project: YugabyteDB (App Definition and Development / Database)
File: TODO.md

TODO ==== Important [X] Choose a better naming convention, including the index oid [X] handle multiple columns [X] handle collation [ ] handle GIN access method [ ] handle GiST access method [ ] handle SP-GiST access method [X] handle BRIN access method [X] better formula for number of pages in index [ ] handle tree height [X] Add check for btree: total column size must not exceed BTMaxItemSize (maybe less, just in case?) Add some more (or enhance) function. Following are interesting: [X] estimated index size [ ] estimated number of lines [X] add hypopggetindexdef(oid) Less important -- [ ] specify tablespace [ ] Compatibility PG 9.2- [X] handle unique index [X] handle reverse and nulls first [X] handle index on expression [X] handle index on predicate [ ] specify a bloat factor
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.42.md

layout: release date: 2024-04-03 tag: v0.7.42 edge annotation arrow head color @aabidsofi19 (#10667) Fix Edge Annotation Relation @aabidsofi19 (#10665) feat: generate relationship docs @RipulHandoo (#10670) Bump eslint from 8.52.0 to 8.57.0 in /ui @dependabot (#10654) upgrade tar from 6.1.15 to 6.2.1 @deepak4566 (#10647) Bump @babel/traverse from 7.23.9 to 7.24.1 in /ui @dependabot (#10656) Bump cypress from 13.6.4 to 13.7.1 in /provider-ui @dependabot (#10659) chore: replace dashboard popup image @dragon-slayer875 (#10668) fix: dashboard charts @aabidsofi19 (#10669) Bump eslint from 8.52.0 to 8.57.0 in /ui @dependabot (#10654) Bump fortio.org/fortio from 1.63.2 to 1.63.5 @dependabot (#10653) Bump github.com/gosimple/slug from 1.13.1 to 1.14.0 @dependabot (#10651) Bump @babel/traverse from 7.23.9 to 7.24.1 in /ui @dependabot (#10656) Bump cypress from 13.6.4 to 13.7.1 in /provider-ui @dependabot (#10659) Remove meshery-perf references @lekaf974 (#10644) feat: generate relationship docs @RipulHandoo (#10670) upgrade tar from 6.1.15 to 6.2.1 @deepak4566 (#10647) Thank you to our contributors for making this release possible: @MUzairS15, @RipulHandoo, @aabidsofi19, @codeKraken19, @deepak4566, @dependabot, @dependabot[bot], @dragon-slayer875, @leecalcote, @lekaf974 and @sudhanshutech