cwielenb/CNCF-Dataset huggingface dataset:
Project: Vault (Provisioning / Key Management)
File: fetch-secrets-engine-config.md

The `fetch-secrets-engine-config` decorator is available in the core addon and can be used on a route that needs to be aware of the configuration details of a secrets engine prior to model hook execution. This is useful for conditionally displaying a call to action for the user to complete the configuration. The decorator accepts a single argument with the name of the Ember Data model to be fetched. modelName [string] - name of the Ember Data model to fetch which is passed to the `queryRecord` method. With the provided model name, the decorator fetches the record using the store `queryRecord` method in the `beforeModel` route hook. Several properties are set on the route class based on the status of the request: configModel [Model | null] - set on success with resolved Ember Data model. configError [AdapterError | null] - set if the request errors with any status other than 404. promptConfig [boolean] - set to `true` if the request returns a 404, otherwise set to `false`. This is for convenience since checking for `(!this.configModel && !this.configError)` would result in the same value. ```js @withConfig('foo/config') export default class FooConfigureRoute extends Route { @service store; @service secretMountPath; model() { const backend = this.secretMountPath.currentPath; return this.configModel || this.store.createRecord('foo/config', { backend }); } } ``` In the scenario of creating/updating the configuration, the model is used to populate the form if available, otherwise the form is presented in an empty state. Fetch errors are not a concern, nor is prompting the user to configure so only the `configModel` property is used. ```js @withConfig('foo/config') export default class FooConfigurationRoute extends Route { @service store; @service secretMountPath; model() { // the error could also be thrown to display the error template // in this example a component is used to display the error return { configModel: this.configModel, configError: this.configError, }; } } ``` For configuration routes, the model and error properties may be used to determine what should be displayed to the user: `configuration.hbs` ```hbs {{#if @configModel}} {{#each @configModel.fields as |field|}} <InfoTableRow @label={{field.label}} @value={{field.value}} /> {{/each}} {{else if @configError}} <Page::Error @error={{@configError}} /> {{else}} <ConfigCta /> {{/if}} ``` This is the most basic usage where a route only needs to be aware of whether or not to show the config prompt: ```js @withConfig('foo/config') export default class FooOverviewRoute extends Route { @service store; @service secretMountPath; model() { const backend = this.secretMountPath.currentPath; return hash({ promptConfig: this.promptConfig, roles: this.store.query('foo/role', { backend }).catch(() => []), libraries: this.store.query('foo/library', { backend }).catch(() => []), }); } } ```
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: restart-a-pulsar-cluster.md

title: Restart Pulsar cluster description: How to restart a Pulsar cluster keywords: [pulsar, restart] sidebar_position: 4 sidebar_label: Restart You can restart all pods of the cluster. When an exception occurs in a database, you can try to restart it. :::note Restarting a Kafka cluster triggers a concurrent restart and the leader may change after the cluster restarts. ::: Restart a cluster. You can use `kbcli` or create an OpsRequest to restart a cluster. Option 1. (Recommended) Use kbcli Configure the values of `components` and `ttlSecondsAfterSucceed` and run the command below to restart a specified cluster. ```bash kbcli cluster restart NAME --components="pulsar" \ --ttlSecondsAfterSucceed=30 ``` `components` describes the component name that needs to be restarted. `ttlSecondsAfterSucceed` describes the time to live of an OpsRequest job after the restarting succeeds. Option 2. Create an OpsRequest Run the command below to apply the restarting to a cluster. ```bash kubectl apply -f - <<EOF apiVersion: apps.kubeblocks.io/v1alpha1 kind: OpsRequest metadata: name: ops-restart spec: clusterRef: pulsar type: Restart restart: componentName: pulsar EOF ``` Validate the restarting. Run the command below to check the cluster status to check the restarting status. ```bash kbcli cluster list <name> ``` *Example* ```bash kbcli cluster list kafka > NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE pulsar pulsar pulsar-2.11 Delete Running 19m ``` STATUS=Restarting: it means the cluster restart is in progress. STATUS=Running: it means the cluster has been restarted.
Project: ClickHouse (App Definition and Development / Database)
File: v22.3.18.37-lts.md

sidebar_position: 1 sidebar_label: 2023 Backported in : Fix too big memory usage for vertical merges on non-remote disk. Respect `maxinsertdelayedstreamsforparallelwrite` for the remote disk. (). Backported in : Allow using Vertical merge algorithm with parts in Compact format. This will allow ClickHouse server to use much less memory for background operations. This closes . (). Backported in : Fix zookeeper downloading, update the version, and optimize the image size. (). Backported in : Another fix for `Cannot read all data` error which could happen while reading `LowCardinality` dictionary from remote fs. Fixes . (). Backported in : Fix `SELECT ... FROM system.dictionaries` exception when there is a dictionary with a bad structure (e.g. incorrect type in xml config). (). Automatically merge green backport PRs and green approved PRs (). Fix wrong approved_at, simplify conditions (). Get rid of artifactory in favor of r2 + ch-repos-manager (). Another attempt to fix automerge, or at least to have debug footprint (). Trim refs/tags/ from GITHUB_TAG in release workflow (). Add check for running workflows to merge_pr.py (). Get rid of progress timestamps in release publishing (). Add helping logging to auto-merge script (). Fix write buffer destruction order for vertical merge. ().
Project: StackRox (Provisioning / Security & Compliance)
File: template.md

Author(s): name <email> Created: <date> (What is the status: Accepted, Rejected or Updated:) Status: Accepted/Rejected/Updated (If updated:) Updated By: Link to ADR (If this updates another ADR:) Updates: Link to ADR (What is the issue that we're seeing that is motivating this decision or change?) (What is the change that we're proposing and/or doing?) (What becomes easier or more difficult to do because of this change?)
Project: Beam (App Definition and Development / Streaming & Messaging)
File: theworkshop.md

title: "The Workshop" icon: /images/logos/powered-by/theworkshop.png hasLink: "https://theworkshop.com/" <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->
Project: Meshery (Provisioning / Automation & Configuration)
File: cockroachdb-operator.md

layout: integration title: Cockroachdb Operator subtitle: Collaborative and visual infrastructure as code for Cockroachdb Operator image: /assets/img/integrations/cockroachdb-operator/icons/color/cockroachdb-operator-color.svg permalink: extensibility/integrations/cockroachdb-operator docURL: https://docs.meshery.io/extensibility/integrations/cockroachdb-operator description: integrations-category: Database integrations-subcategory: App Definition and Development registrant: Artifact Hub components: name: crdb-cluster colorIcon: assets/img/integrations/cockroachdb-operator/components/crdb-cluster/icons/color/crdb-cluster-color.svg whiteIcon: assets/img/integrations/cockroachdb-operator/components/crdb-cluster/icons/white/crdb-cluster-white.svg description: featureList: [ "Use Couchbase's multi-purpose NoSQL database to supply your applications' JSON data, and seamlessly grow your environment.", "DevOps can deploy and scale Couchbase clusters up and down, automatically, and use their preferred CNCF observability tools.", "Use Couchbase's multi-purpose NoSQL database to supply your applications' JSON data, and seamlessly grow your environment. " ] 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: ArangoDB (App Definition and Development / Database)
File: ub.md

+++ title = "`static void _ub(Impl &&)`" description = "Special function which causes noticeable hard undefined behaviour." categories = ["special"] weight = 100 +++ This is a special function which does compiler-specific stuff to tell the compiler that this function can never, ever, ever be executed. The compiler's optimiser will hard assume that this function can never be executed, and will prune the possibility of it being executed completely. Generally this means that the code path stops dead, and if execution does proceed down this path, it will run off the end of a branch which doesn't go anywhere. Your program will have lost known state, and usually it will trash memory and registers and crash. This may seem highly undesirable. However, it also means that the optimiser can optimise more strongly, and so long as you never actually do execute this branch, you do get higher quality code generation. If the `NDEBUG` macro is not defined, an `assert(false)` is present. This will cause attempts to execute this function to fail in a very obvious way, but it also generates runtime code to trigger the obvious failure. If the `NDEBUG` macro is defined, and the program is compiled with the undefined behaviour sanitiser, attempts to execute this function will trigger an undefined behaviour sanitiser action. Requires: Always available. Complexity: Zero runtime overhead if `NDEBUG` is defined, guaranteed. If this function returns, your program is now in hard loss of known program state. Usually, but not always, it will crash at some point later. Rarely it will corrupt registers and memory, and keep going. Guarantees: An exception is never thrown.
Project: YDB (App Definition and Development / Database)
File: TROUBLESHOOTING.md

This guide is for troubleshooting gRPC implementations based on C core library (sources for most of them are living in the `grpc/grpc` repository). Extra logging can be very useful for diagnosing problems. All gRPC implementations based on C core library support the `GRPCVERBOSITY` and `GRPCTRACE` environment variables that can be used to increase the amount of information that gets printed to stderr. `GRPC_VERBOSITY` is used to set the minimum level of log messages printed by gRPC (supported values are `DEBUG`, `INFO` and `ERROR`). If this environment variable is unset, only `ERROR` logs will be printed. `GRPC_TRACE` can be used to enable extra logging for some internal gRPC components. Enabling the right traces can be invaluable for diagnosing for what is going wrong when things aren't working as intended. Possible values for `GRPC_TRACE` are listed in . Multiple traces can be enabled at once (use comma as separator). ``` GRPCVERBOSITY=debug ./helloworldapplicationusinggrpc ``` ``` GRPCVERBOSITY=info GRPCTRACE=api ./helloworldapplicationusing_grpc ``` ``` GRPCVERBOSITY=debug GRPCTRACE=tcp,http,api ./helloworldapplicationusing_grpc ``` Known limitations: `GPRC_TRACE=tcp` is currently not implemented for Windows (you won't see any tcp traces). Please note that the `GRPC_TRACE` environment variable has nothing to do with gRPC's "tracing" feature (= tracing RPCs in microservice environment to gain insight about how requests are processed by deployment), it is merely used to enable printing of extra logs.
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: Using-non-JVM-languages-with-Storm.md

title: Using non JVM languages with Storm layout: documentation two pieces: creating topologies and implementing spouts and bolts in other languages creating topologies in another language is easy since topologies are just thrift structures (link to storm.thrift) implementing spouts and bolts in another language is called a "multilang components" or "shelling" Here's a specification of the protocol: the thrift structure lets you define multilang components explicitly as a program and a script (e.g., python3 and the file implementing your bolt) In Java, you override ShellBolt or ShellSpout to create multilang components note that output fields declarations happens in the thrift structure, so in Java you create multilang components like the following: declare fields in java, processing code in the other language by specifying it in constructor of shellbolt multilang uses json messages over stdin/stdout to communicate with the subprocess storm comes with Ruby, Python, and Fancy adapters that implement the protocol. show an example of Python Python supports emitting, anchoring, acking, and logging "storm shell" command makes constructing jar and uploading to nimbus easy makes jar and uploads it calls your program with host/port of nimbus and the jarfile id The right place to start is src/storm.thrift. Since Storm topologies are just Thrift structures, and Nimbus is a Thrift daemon, you can create and submit topologies in any language. When you create the Thrift structs for spouts and bolts, the code for the spout or bolt is specified in the ComponentObject struct: ``` union ComponentObject { 1: binary serialized_java; 2: ShellComponent shell; 3: JavaObject java_object; } ``` For a non-JVM DSL, you would want to make use of "2" and "3". ShellComponent lets you specify a script to run that component (e.g., your Python code). And JavaObject lets you specify native java spouts and bolts for the component (and Storm will use reflection to create that spout or bolt). There's a "storm shell" command that will help with submitting a topology. Its usage is like this: ``` storm shell resources/ python3 topology.py arg1 arg2 ``` storm shell will then package resources/ into a jar, upload the jar to Nimbus, and call your topology.py script like this: ``` python3 topology.py arg1 arg2 {nimbus-host} {nimbus-port} {uploaded-jar-location} ``` Then you can connect to Nimbus using the Thrift API and submit the topology, passing {uploaded-jar-location} into the submitTopology method. For reference, here's the submitTopology definition: ``` void submitTopology(1: string name, 2: string uploadedJarLocation, 3: string jsonConf, 4: StormTopology topology) throws (1: AlreadyAliveException e, 2: InvalidTopologyException ite); ```
Project: ClickHouse (App Definition and Development / Database)
File: proxy.md

slug: /en/interfaces/third-party/proxy sidebar_position: 29 sidebar_label: Proxies , is an HTTP proxy and load balancer for ClickHouse database. Features: Per-user routing and response caching. Flexible limits. Automatic SSL certificate renewal. Implemented in Go. is designed to be a local proxy between ClickHouse and application server in case its impossible or inconvenient to buffer INSERT data on your application side. Features: In-memory and on-disk data buffering. Per-table routing. Load-balancing and health checking. Implemented in Go. is a simple ClickHouse insert collector. Features: Group requests and send by threshold or interval. Multiple remote servers. Basic authentication. Implemented in Go.
Project: Trivy (Provisioning / Security & Compliance)
File: rocky.md

Trivy supports the following scanners for OS packages. | Scanner | Supported | | :--: | :-: | | SBOM | | | Vulnerability | | | License | | Please see for supported versions. The table below outlines the features offered by Trivy. | Feature | Supported | |::|::| | Unfixed vulnerabilities | - | | | | Trivy detects packages that have been installed through package managers such as `dnf` and `yum`. Rocky Linux offers its own security advisories, and these are utilized when scanning Rocky Linux for vulnerabilities. See . Trivy takes fixed versions from , not NVD or somewhere else. See for more details. !!! architectures There are cases when the vulnerability affects packages of not all architectures. For example, vulnerable packages for are only `aarch64` packages. Trivy only detects vulnerabilities for packages of your architecture. Trivy calculates the severity of an issue based on the severity provided in . The table below is the mapping of Rocky Linux's severity to Trivy's severity levels. | Rocky Linux | Trivy | | :: | :: | | Low | Low | | Moderate | Medium | | Important | High | | Critical | Critical | Trivy supports the following [vulnerability statuses] for Rocky Linux. | Status | Supported | | :--: | :-: | | Fixed | | | Affected | | | Under Investigation | | | Will Not Fix | | | Fix Deferred | | | End of Life | | Trivy identifies licenses by examining the metadata of RPM packages.
Project: KusionStack (Provisioning / Automation & Configuration)
File: kusion_workspace_show.md

Show a workspace configuration This command gets a specified workspace configuration. ``` kusion workspace show ``` ``` kusion workspace show dev ``` ``` -h, --help help for show ``` ``` --profile string Name of profile to capture. One of (none|cpu|heap|goroutine|threadcreate|block|mutex) (default "none") --profile-output string Name of the file to write the profile to (default "profile.pprof") ``` - Workspace is a logical concept representing a target that stacks will be deployed to
Project: StarRocks (App Definition and Development / Database)
File: bitxor.md

displayed_sidebar: "English" Returns the bitwise XOR of two numeric expressions. ```Haskell BITXOR(x,y); ``` `x`: This expression must evaluate to any of the following data types: TINYINT, SMALLINT, INT, BIGINT, LARGEINT. `y`: This expression must evaluate to any of the following data types: TINYINT, SMALLINT, INT, BIGINT, LARGEINT. `x` and `y` must agree in data type. The return value has the same type as `x`. If any value is NULL, the result is NULL. ```Plain Text mysql> select bitxor(3,0); +--+ | bitxor(3, 0) | +--+ | 3 | +--+ 1 row in set (0.00 sec) ```
Project: openGauss (App Definition and Development / Database)
File: PULL_REQUEST_TEMPLATE.en.md

<!-- Thanks for sending a pull request! --> Title : Content: Root Cause Analysis: Modification: xxx xxx Related issue: Testing reports: Please attach the self-test result (content or screenshot). Can you add the FastCheck test case? If yes, please add the FastCheck test case. Whether data modification is involved? If yes, supplement the data in the Docs repository. Determine whether to support expansion scenarios such as upgrade and online expansion. Determine whether to consider abnormal scenarios, concurrent scenarios, forward compatibility scenarios, and performance scenarios. Check whether other modules are affected.
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_kubeblocks_list-versions.md

title: kbcli kubeblocks list-versions List KubeBlocks versions. ``` kbcli kubeblocks list-versions [flags] ``` ``` kbcli kubeblocks list-versions kbcli kubeblocks list-versions --devel ``` ``` --devel Use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. -h, --help help for list-versions --limit int Maximum rows of versions to return, 0 means no limit (default 10) (default 10) ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "$HOME/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use ``` - KubeBlocks operation commands.
Project: secureCodeBox (Provisioning / Security & Compliance)
File: overview.md

title: "AutoDiscovery Overview" sidebar_label: "Overview" path: "docs/auto-discovery/overview" sidebar_position: 0 The secureCodeBox (SCB) AutoDiscovery is an optional component that automates the process of setting up scheduled scans for Kubernetes resources inside a cluster. The AutoDiscovery will observe the scanned Kubernetes resources over their whole lifecycle. It will automatically create, update and delete scans when necessary. Currently the SCB AutoDiscovery supports two modes that can be enabled independently: : Creates scans for (http) services inside a kubernetes cluster. With it you can automatically start scanners like ZAP or nuclei for all web applications inside the cluster. : Creates scans for containers running inside a kubernetes cluster. This allows you to automatically create trivy container image scans for all container images inside a cluster.
Project: Meshery (Provisioning / Automation & Configuration)
File: wasmedgeruntime.md

layout: integration title: Wasmedge Runtime subtitle: Collaborative and visual infrastructure as code for Wasmedge Runtime image: /assets/img/integrations/wasmedgeruntime/icons/color/wasmedgeruntime-color.svg permalink: extensibility/integrations/wasmedgeruntime docURL: https://docs.meshery.io/extensibility/integrations/wasmedgeruntime description: integrations-category: Runtime integrations-subcategory: Container Runtime 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