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

Secondary indexes can currently be either global (default) or local. Global indexes use the indexed column as its partition key, while local indexes share their partition key with their base table, which ensures local lookup. The distinction is stored in index target, which is a string kept in index's options map under the key "target". Example of a global and local indexes on the same table and column: ``` SELECT * FROM system\_schema.indexes; keyspace\name | table\name | index\_name | kind | options -+-+-++- demodb | t | localtv1 | COMPOSITES | {'target': '{"pk":["p"],"ck":["v1"]}'} demodb | t | tv1idx | COMPOSITES | {'target': 'v1'} ``` By default, index names are generated from table name, column name and "_idx" postfix. Because index names, like table names, must be word characters (letters, digits, or underscore), any characters in the column name which aren't word characters are dropped before constructing the index name. If the name is taken (e.g. because somebody already created a named index with the exact same name), "_X" is appended, where X is the smallest number that ensures name uniqueness. Default name for an index created on table t and column v1 is thus t\v1\idx, but it can also become t\v1\idx\_1 if the first one was already taken. Both global and local indexes share the same default naming conventions. When in doubt, `DESCRIBE indexname` or `SELECT * FROM systemschema.indexes` commands can be leveraged to see more details on index targets and type. Global index's target is usually just the indexed column name, unless the index has a specific type. All supported types are: regular index: v full collection index (for frozen collection): FULL(v) index on map keys: KEYS(v) index on map, set or list values: VALUES(v) index on map entries: ENTRIES(v) Their serialization is just string representation, so: "v", "FULL(v)", "KEYS(v)", "VALUES(v)", "ENTRIES(v)" are all valid targets. Local index's target consists of explicit partition key followed by indexed column definition. Currently the partition key must match the partition key of base table. Their serialization is a string representing primary key in JSON. Examples: { "pk": ["p1", "p2", "p3"], "ck": ["v"] } { "pk": ["p"], "ck": ["v"] }
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: shared-resource.eg.md

It's used in scenario. It can be used to configure which resources can be shared between applications. The target resource will allow multiple application to read it but only the first one to be able to write it. ```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app1 spec: components: name: ns1 type: k8s-objects properties: objects: apiVersion: v1 kind: Namespace metadata: name: example name: cm1 type: k8s-objects properties: objects: apiVersion: v1 kind: ConfigMap metadata: name: cm1 namespace: example data: key: value1 policies: name: shared-resource type: shared-resource properties: rules: selector: resourceTypes: ["Namespace"] ``` ```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app2 spec: components: name: ns2 type: k8s-objects properties: objects: apiVersion: v1 kind: Namespace metadata: name: example name: cm2 type: k8s-objects properties: objects: apiVersion: v1 kind: ConfigMap metadata: name: cm2 namespace: example data: key: value2 policies: name: shared-resource type: shared-resource properties: rules: selector: resourceTypes: ["Namespace"] ```
Project: ClickHouse (App Definition and Development / Database)
File: v22.4.5.9-stable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix `Missing column` exception which could happen while using `INTERPOLATE` with `ENGINE = MergeTree` table. (). Backported in : Fix vertical merges in wide parts. Previously an exception `There is no column` can be thrown during merge. (). Backported in : Fix bug in clickhouse-keeper which can lead to corrupted compressed log files in case of small load and restarts. (). Some fixes for replicated merge tree ().
Project: Buildpacks (App Definition and Development / Application Definition & Image Build)
File: pull_request_template.md

<!-- Provide a high-level summary of the change. --> <!-- If applicable, please provide examples of the output changes. --> <!-- If this change should be documented, please create an issue or PR on https://github.com/buildpacks/docs and link below. --> <!-- NOTE: This can be added (by editing the issue) after the PR is opened. --> Should this change be documented? [ ] Yes, see #_ [ ] No <!-- If this PR addresses an issue, please provide issue number below. --> Resolves #_
Project: KICS (Provisioning / Security & Compliance)
File: a6f34658-fdfb-4154-9536-56d516f65828.md

title: Docker Daemon Socket is Exposed to Containers hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a6f34658-fdfb-4154-9536-56d516f65828 Query name: Docker Daemon Socket is Exposed to Containers Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Sees if Docker Daemon Socket is not exposed to Containers<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="67 43 15" apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: image: k8s.gcr.io/test-webserver name: test-container volumeMounts: mountPath: /test-pd name: test-volume volumes: name: test-volume hostPath: path: /var/run/docker.sock type: Directory apiVersion: v1 kind: ReplicationController metadata: name: node-manager labels: name: node-manager spec: selector: name: node-manager template: metadata: labels: name: node-manager spec: containers: image: k8s.gcr.io/test-webserver name: test-container volumeMounts: mountPath: /test-pd name: test-volume volumes: name: test-volume hostPath: path: /var/run/docker.sock type: Directory apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "/1 *" jobTemplate: spec: template: spec: containers: image: k8s.gcr.io/test-webserver name: test-container volumeMounts: mountPath: /test-pd name: test-volume volumes: name: test-volume hostPath: path: /var/run/docker.sock type: Directory ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: image: k8s.gcr.io/test-webserver name: test-container volumeMounts: mountPath: /test-pd name: test-volume volumes: name: test-volume hostPath: path: /data type: Directory ```
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: generate-jdbc-connection.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: jdbc spec: components: name: db type: alibaba-rds properties: instance_name: favorite-links database_name: db1 account_name: oamtest password: U34rfwefwefffaked security_ips: [ "0.0.0.0/0" ] privilege: ReadWrite writeConnectionSecretToRef: name: db-conn name: express-server type: webservice properties: image: crccheck/hello-world port: 8000 workflow: steps: name: jdbc type: generate-jdbc-connection outputs: name: jdbc valueFrom: jdbc properties: name: db-conn namespace: default name: apply type: apply-component inputs: from: jdbc parameterKey: env properties: component: express-server ```
Project: KubeMQ (App Definition and Development / Streaming & Messaging)
File: kubemq_queues_send.md

Queues send a message to a queue channel command Queues send command allows to send one or many message to a queue channel ``` kubemq queues send [flags] ``` ``` kubemq queue send q1 some-message kubemq queue send q1 some-message --metadata some-metadata kubemq queue send q1 some-message --metadata some-metadata -m 5 kubemq queue send q1 some-message -e 5 kubemq queue send q1 some-message -d 5 kubemq queue send q1 some-message -r 5 -q dead-letter ``` ``` -q, --dead-letter-queue string set dead-letter queue name -d, --delay int set queue message sending delay seconds -e, --expiration int set queue message expiration seconds -h, --help help for send -r, --max-receive int set dead-letter max receive count -i, --messages int set how many messages to send in a batch (default 1) -m, --metadata string set queue message metadata field ``` - Execute Kubemq 'queues' commands
Project: NATS (App Definition and Development / Streaming & Messaging)
File: TODO.md

[ ] Auth for queue groups? [ ] Blacklist or ERR escalation to close connection for auth/permissions [ ] Protocol updates, MAP, MPUB, etc [ ] Multiple listen endpoints [ ] Websocket / HTTP2 strategy [ ] T series reservations [ ] _SYS. server events? [ ] No downtime restart [ ] Signal based reload of configuration [ ] brew, apt-get, rpm, chocately (windows) [ ] IOVec pools and writev for high fanout? [ ] Modify cluster support for single message across routes between pub/sub and d-queue [ ] Memory limits/warnings? [ ] Limit number of subscriptions a client can have, total memory usage etc. [ ] Multi-tenant accounts with isolation of subject space [ ] Pedantic state [X] _SYS.> reserved for server events? [X] Listen configure key vs addr and port [X] Add ENV and variable support to dconf? ucl? [X] Buffer pools/sync pools? [X] Multiple Authorization / Access [X] Write dynamic socket buffer sizes [X] Read dynamic socket buffer sizes [X] Info updates contain other implicit route servers [X] Sublist better at high concurrency, cache uses writelock always currently [X] Switch to 1.4/1.5 and use maps vs hashmaps in sublist [X] NewSource on Rand to lower lock contention on QueueSubs, or redesign! [X] Default sort by cid on connz [X] Track last activity time per connection? [X] Add total connections to varz so we won't miss spikes, etc. [X] Add starttime and uptime to connz list. [X] Gossip Protocol for discovery for clustering [X] Add in HTTP requests to varz? [X] Add favico and help link for monitoring? [X] Better user/pass support using bcrypt etc. [X] SSL/TLS support [X] Add support for / to point to varz, connz, etc.. [X] Support sort options for /connz via nats-top [X] Dropped message statistics (slow consumers) [X] Add current time to each monitoring endpoint [X] varz uptime do days and only integer secs [X] Place version in varz (same info sent to clients) [X] Place server ID/UUID in varz [X] nats-top equivalent, utils [X] Connz report routes (/routez) [X] Docker [X] Remove reliance on `ps` [X] Syslog support [X] Client support for language and version [X] Fix benchmarks on linux [X] Daemon mode? Won't fix
Project: OAuth2 Proxy (Provisioning / Key Management)
File: RELEASE.md

The is a legacy document to explain the manual process of creating and publishing a new release of oauth2-proxy. As of now the release process has been automated with GitHub Actions workflows. For more information have a look at the workflows `create-release.yml` and `publish-release.yml`. Here's how OAuth2 Proxy releases are created. Our aim is to release once a quarter, but bug fixes will be prioritised and might be released earlier. Note this uses `v4.1.0` as an example release number. Create a draft Github release Use format `v4.1.0` for both the tag and title Update Write the release highlights Copy in headings ready for the next release Create release commit ``` git checkout -b release-v4.1.0 ``` Create pull request getting other maintainers to review Copy the release notes in to the draft Github release, adding a link to Update you local master branch ``` git checkout master git pull ``` Create & push the tag ``` git tag v4.1.0 git push --tags ``` Make the release artefacts ``` make release ``` Upload all the files (not the folders) from the `/release` folder to Github release as binary artefacts. There should be both the tarballs (`tar.gz`) and the checksum files (`sha256sum.txt`). Publish release in Github Make and push docker images to Quay ``` make docker-all make docker-push-all ``` Note: Ensure the docker tags don't include `-dirty`. This means you have uncommitted changes. Verify everything looks good at and
Project: Akri (Provisioning / Automation & Configuration)
File: ADOPTERS.md

If you are using Akri in your solutions, we would love to have your organization in our adopters list. This is a small contribution that helps the project gain momentum and support. To add your organization to this list, feel free to PR the additions to this page, following . Alternatively, reach out to us on if you have any questions or need help around this process. | Organization | Reference or Description of Usage | ||| | | |
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: environment-types.md

Lagoon currently differentiates between two different environment types: `production` and `development`. When setting up your project via the Lagoon GraphQL API, you can define a `productionEnvironment`. On every deployment Lagoon executes, it checks if the current environment name matches what is defined in `productionEnvironment`. If it does, Lagoon will mark this environment as the `production` environment. This happens in two locations: Within the GraphQL API itself. As an environment variable named `LAGOONENVIRONMENTTYPE` in every container. But that's it. Lagoon itself handles `development` and `production` environments in exactly the same way \(in the end we want as few differences of the environments as possible - that's the beauty of Lagoon\). There are a couple of things that will use this information: By default, `development` environments are idled after 4 hours with no hits \(don't worry, they wake up automatically\). It is also possible for your Lagoon administrator to disable auto-idling on a per-environment basis, just ask! Our default Drupal `settings.php` files load additional settings files for `development.settings.php` and `production.settings.php` so you can define settings and configurations different per environment type. If you try to delete an environment that is defined as the production environment \(either via webhooks or REST\), Lagoon will politely refuse to delete the production environment, as it tries to prevent you from making a mistake. In order to delete a production environment, you can either change the `productionEnvironment` in the API or use the secret `forceDeleteProductionEnvironment: true` POST payload for the REST API. The Lagoon administrator might use the production environment information for some additional things. For example, at amazee.io we're calculating only the hits of the production environments to calculate the price of the hosting.
Project: SuperEdge (Provisioning / Automation & Configuration)
File: addnode_via_penetrator.md

How to build: Deploy directly using ```shell kubectl apply -f https://raw.githubusercontent.com/superedge/superedge/main/deployment/penetrator.yaml ``` Use SSH password file passwd to create sshCredential ```shell kubectl -n edge-system create secret generic login-secret --from-file=passwd=./passwd ``` Or use SSH private key file sshkey to create sshCredential ```shell kubectl -n edge-system create secret generic login-secret --from-file=sshkey=./sshkey ``` ```yaml apiVersion: nodetask.apps.superedge.io/v1beta1 kind: NodeTask metadata: name: nodes spec: nodeNamePrefix: "edge" targetMachines: 172.21.3.194 ... sshCredential: login-secret proxyNode: vm-2-117-centos ``` nodeNamePrefix: node name prefix, the format of node name: nodeNamePrefix-random string (6 digits) targetMachines: the ip list of the node to be installed sshCredential: Stores the secret of the password (passwd) and private key (sshkey) for SSH login to the node to be added. The key value of the password file must be passwd, and the key value of the private key file must be sshkey proxyNode: The node name of the node in the cluster that executes the job to add the node. The node and the node to be installed are on the same intranet (SSH can log in to the node to be installed) ```yaml apiVersion: nodetask.apps.superedge.io/v1beta1 kind: NodeTask metadata: name: nodes spec: nodeNamesOverride: edge-1mokvl: 172.21.3.194 ... sshCredential: login-secret proxyNode: vm-2-117-centos ``` nodeNamesOverride: Reinstall the node name and IP of the node The Status of NodeTask contains the execution status (creating and ready) of the task and the node name and IP of the node that has not been installed. You can use the command to view: ```shell kubectl get nt NodeTaskName -o custom-columns='STATUS:status.nodetaskStatus' ``` The success and error information of the task in the execution process is reported to the apiserver in the form of an event, and you can use the command to view: ```shell kubectl -n edge-system get event ```
Project: Meshery (Provisioning / Automation & Configuration)
File: wasmcloud.md

layout: integration title: Wasmcloud subtitle: Collaborative and visual infrastructure as code for Wasmcloud image: /assets/img/integrations/wasmcloud/icons/color/wasmcloud-color.svg permalink: extensibility/integrations/wasmcloud docURL: https://docs.meshery.io/extensibility/integrations/wasmcloud description: integrations-category: Orchestration & Management integrations-subcategory: Scheduling & Orchestration registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.0.1-alpha.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Conflict: Same security.log.file for multiple users. | Major | conf, security | Karthik Kambatla | Karthik Kambatla | | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Add retry support to WebHdfsFileSystem | Major | webhdfs | Tsz Wo Nicholas Sze | Tsz Wo Nicholas Sze |
Project: GraphScope (App Definition and Development / Database)
File: guide_and_examples.md

```{toctree} arguments caption: TOC maxdepth: 1 hidden: tutorialnodeclassification_local tutorialnodeclassification_k8s ``` This section contains a guide for the learning engine and a number of examples. ```{tip} We assume you has read the section and know how to launch a GraphScope session. ``` We present an end-to-end example, demonstrating how GLE trains a node classification model on a citation network using the local mode of GraphScope. ````{panels} :header: text-center :column: col-lg-12 p-2 ```{link-button} tutorialnodeclassification_local.html :text: Tutorial :classes: btn-block stretched-link ``` ^^^^^^^^^^^^^^ Training a Node Classification Model on Your Local Machine. ```` GraphScope is designed for processing large graphs, which are usually hard to fit in the memory of a single machine. With vineyard as the distributed in-memory data manager, GraphScope supports run on a cluster managed by Kubernetes(k8s). Next, we revisit the example we present in the first tutorial, showing how GraphScope process the node classification task on a Kubernetes cluster. ````{panels} :header: text-center :column: col-lg-12 p-2 ```{link-button} tutorialnodeclassification_k8s.html :text: Tutorial :classes: btn-block stretched-link ``` ^^^^^^^^^^^^^^ Training a Node Classification Model on K8s Cluster ```` GraphScope is also compatible with PyG models, the following examples shows ho2 to train a PyG model using GraphScope on your local machine. ````{panels} :header: text-center :column: col-lg-12 p-2 ```{link-button} tutorialnodeclassificationpyglocal.html :text: Tutorial :classes: btn-block stretched-link ``` ^^^^^^^^^^^^^^ Training a Node Classification Model(PyG) on Your Local Machine ```` ````{panels} :header: text-center :column: col-lg-12 p-2 ```{link-button} tutorialnodeclassificationpygk8s.html :text: Tutorial :classes: btn-block stretched-link ``` ^^^^^^^^^^^^^^ Tutorial: Training a Node Classification Model (PyG) on a K8S Cluster ````
Project: Trivy (Provisioning / Security & Compliance)
File: embed-in-dockerfile.md

Scan your image as part of the build process by embedding Trivy in the Dockerfile. This approach can be used to update Dockerfiles currently using Aquas . ```bash $ cat Dockerfile FROM alpine:3.7 RUN apk add curl \ && curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin \ && trivy rootfs --exit-code 1 --no-progress / $ docker build -t vulnerable-image . ``` Alternatively you can use Trivy in a multistage build. Thus avoiding the insecure `curl | sh`. Also the image is not changed. ```bash [...] FROM build AS vulnscan COPY --from=aquasec/trivy:latest /usr/local/bin/trivy /usr/local/bin/trivy RUN trivy rootfs --exit-code 1 --no-progress / [...] ```
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: read-config.eg.md

```yaml kind: Application apiVersion: core.oam.dev/v1beta1 metadata: name: test-config namespace: "config-e2e-test" spec: components: [] workflow: steps: name: read-config type: read-config properties: name: test outputs: fromKey: config name: read-config ```
Project: Redpanda (App Definition and Development / Streaming & Messaging)
File: awesome.md

Please send a pull request with your project name and description. : First impressions of Redpanda by Shair Daya, IBM Distinguished Engineer and Chief Architect : Real-time applications made simple with MongoDB and Redpanda : Building data-intensive apps with SingleStore, Redpanda, and Golang : Scaling worldwide parcel logistics with SingleStore and Redpanda : Using Redpanda to stream Docker Stats in Deephaven : Taking streaming analytics further faster with Materialize and Redpanda : Anomaly detection with Bytewax and Redpanda : Analyzing real-time movie reviews with Memgraph and Redpanda : We're bringing simple back (to streaming) : Realizing low latency streaming analytics with Timeplus and Redpanda : How to build a reliable and scalable real-time data pipeline with Ably and Redpanda Materialize: kPow: Conduktor: Datadog: : An event-processing system designed at Wayfair to introduce a configurable traffic-shaping mechanism. : A StreamOps platform for developers for discovery, analytics, and operations. : A lightweight streaming event collection system built for speed, flexibility, and scalability.