cwielenb/CNCF-Dataset huggingface dataset:
Project: runc (Runtime / Container Runtime)
File: runc-spec.8.md

% runc-spec "8" runc-spec - create a new specification file runc spec [option ...] The spec command creates the new specification file named config.json for the bundle. The spec generated is just a starter file. Editing of the spec is required to achieve desired results. For example, the newly generated spec includes an args parameter that is initially set to call the sh command when the container is started. Calling sh may work for an ubuntu container or busybox, but will not work for containers that do not include the sh binary. --bundle|-b path : Set path to the root of the bundle directory. --rootless : Generate a configuration for a rootless container. Note this option is entirely different from the global --rootless option. To run a simple "hello-world" container, one needs to set the args parameter in the spec to call hello. This can be done using sed(1), jq(1), or a text editor. The following commands will: create a bundle for hello-world; change the command to run in a container to /hello using jq(1); run the hello command in a new hello-world container named container1. mkdir hello cd hello docker pull hello-world docker export $(docker create hello-world) > hello-world.tar mkdir rootfs tar -C rootfs -xf hello-world.tar runc spec jq '.process.args |= ["/hello"]' < config.json > new.json mv -f new.json config.json runc run container1 In the run command above, container1 is the name for the instance of the container that you are starting. The name you provide for the container instance must be unique on your host. An alternative for generating a customized spec config is to use oci-runtime-tool; its sub-command oci-runtime-tool generate has lots of options that can be used to do any customizations as you want. See to get more information. When starting a container through runc, the latter usually needs root privileges. If not already running as root, you can use sudo(8), for example: sudo runc start container1 Alternatively, you can start a rootless container, which has the ability to run without root privileges. For this to work, the specification file needs to be adjusted accordingly. You can pass the --rootless option to this command to generate a proper rootless spec file. runc-run(8), runc(8).
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-alibabacloud_metrics_list.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> List all metrics for the operator ``` cilium-operator-alibabacloud metrics list [flags] ``` ``` -h, --help help for list -p, --match-pattern string Show only metrics whose names match matchpattern -o, --output string json| yaml| jsonpath='{}' -s, --server-address string Address of the operator API server (default "localhost:9234") ``` - Access metric status of the operator
Project: Velero (Runtime / Cloud Native Storage)
File: self-signed-certificates.md

title: "Use Velero with a storage provider secured by a self-signed certificate" layout: docs If you are using an S3-Compatible storage provider that is secured with a self-signed certificate, connections to the object store may fail with a `certificate signed by unknown authority` message. To proceed, provide a certificate bundle when adding the storage provider. When using the `velero install` command, you can use the `--cacert` flag to provide a path to a PEM-encoded certificate bundle to trust. ```bash velero install \ --plugins <PLUGINCONTAINERIMAGE [PLUGINCONTAINERIMAGE]> --provider <YOUR_PROVIDER> \ --bucket <YOUR_BUCKET> \ --secret-file <PATHTOFILE> \ --cacert <PATHTOCA_BUNDLE> ``` Velero will then automatically use the provided CA bundle to verify TLS connections to that storage provider when backing up and restoring. To use the describe, download, or logs commands to access a backup or restore contained in storage secured by a self-signed certificate as in the above example, you must use the `--cacert` flag to provide a path to the certificate to be trusted. ```bash velero backup describe my-backup --cacert <PATHTOCA_BUNDLE> ``` In case you are using a custom S3-compatible server, you may encounter that the backup fails with an error similar to one below. ``` rpc error: code = Unknown desc = RequestError: send request failed caused by: Get https://minio.com:3000/k8s-backup-bucket?delimiter=%2F&list-type=2&prefix=: remote error: tls: alert(116) ``` Error 116 represents certificate required as seen here in . Velero as a client does not include its certificate while performing SSL handshake with the server. From , verifying client certificate is optional on the server. You will need to change this setting on the server to make it work. Note: The `--insecure-skip-tls-verify` flag is insecure and susceptible to man-in-the-middle attacks and meant to help your testing and developing scenarios in an on-premise environment. Using this flag in production is not recommended. Velero provides a way for you to skip TLS verification on the object store when using the or by passing the `--insecure-skip-tls-verify` flag with the following Velero commands, velero backup describe velero backup download velero backup logs velero restore describe velero restore log If true, the object store's TLS certificate will not be checked for validity before Velero connects to the object store or Restic repo. You can permanently skip TLS verification for an object store by setting `Spec.Config.InsecureSkipTLSVerify` to true in the CRD. Note that Velero's Restic integration uses Restic commands to do data transfer between object store and Kubernetes cluster disks. This means that when you specify `--insecure-skip-tls-verify` in Velero operations that involve interacting with Restic, Velero will add the Restic global command parameter `--insecure-tls` to Restic commands.
Project: rkt (Runtime / Container Runtime)
File: api-service.md

The API service lists and introspects pods and images. The API service is implemented with . The API service is designed to run without root privileges, and currently provides a read-only interface. The API service is optional for running pods, the start/stop/crash of the API service won't affect any pods or images. The API service listens for gRPC requests on the address and port specified by the `--listen` option. The default is to listen on the loopback interface on port number `15441`, equivalent to invoking `rkt api-service --listen=localhost:15441`. Specify the address `0.0.0.0` to listen on all interfaces. Typically, the API service will be run via a unit file similar to the one included in the . The interfaces are defined in the . Here is a small that illustrates how to use the API service. | Flag | Default | Options | Description | | | | | | | `--listen` | `localhost:15441` | An address to listen on | Address to listen for client API requests | See the table with .
Project: Velero (Runtime / Cloud Native Storage)
File: ark_schedule_get.md

title: "ark schedule get" layout: docs Get schedules Get schedules ``` ark schedule get [flags] ``` ``` -h, --help help for get --label-columns stringArray a comma-separated list of labels to be displayed as columns -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. (default "table") -l, --selector string only show items matching this label selector --show-labels show labels in the last column ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Work with schedules
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-sse-s3.md

target-version: release-1.10 AWS server side encryption SSE-S3 support for RGW The S3 protocol supports three different types of : SSE-C, SSE-KMS and SSE-S3. For the last two RGW server need to configure with external services such as . Currently Rook configure RGW with `SSE-KMS` options to handle the S3 requests with the `sse:kms` header. Recently the support for handling the `sse:s3` was added to RGW, so Rook will now provide the option to configure RGW with `sse:s3`. The `sse:s3` is supported only from Ceph v17 an onwards, so this feature can only be enabled for Quincy or newer. Configure RGW with `SSE-S3` options, so that RGW can handle request with `sse:s3` headers. Introducing new field `s3` in `SecuritySpec` which defines `AWS-SSE-S3` support for RGW. ```yaml security: kms: .. s3: connectionDetails: KMS_PROVIDER: vault VAULT_ADDR: https://vault.default.svc.cluster.local:8200 VAULTSECRETENGINE: transit VAULTAUTHMETHOD: token tokenSecretName: rook-vault-token ``` The values for this configuration will be available in of `CephObjectStoreSpec`, so depending on the above option RGW can be configured with `SSE-KMS` and `SSE-S3` options. These two options can be configured independently and they both are mutually exclusive in Rook and Ceph level. Before this design is implemented, the user could manually set below options from the toolbox pod to configure with `SSE-S3` options for RGW. ``` ceph config set <ceph auth user for rgw> rgwcryptsses3backend vault ceph config set <ceph auth user for rgw> rgwcryptsses3vaultsecretengine <kv|transit> # https://docs.ceph.com/en/latest/radosgw/vault/#vault-secrets-engines ceph config set <ceph auth user for rgw> rgwcryptsses3vault_addr <vault address> ceph config set <ceph auth user for rgw> rgwcryptsses3vault_auth token ceph config set <ceph auth user for rgw> rgwcryptsses3vaulttokenfile <location of file containing token for accessing vault> ``` The `ceph auth user for rgw` is the (ceph client user)[https://docs.ceph.com/en/latest/rados/operations/user-management/#user-management] who has permissions change the settings for RGW server. This can be listed from `ceph auth ls` command and in Rook ceph client user for RGW will always begins with `client.rgw`, followed by `store` name.
Project: CubeFS (Runtime / Cloud Native Storage)
File: collect.md

The `Master` metric listening port is the service port, and the metric monitoring module is enabled by default. The `Blobstore` metric listening port is the service port, and the service custom monitoring metric items are enabled by default. Public metric items need to be opened by modifying the configuration file. : Other modules need to configure the metric listening port, which is disabled by default. `exporterPort`: Metric listening port. `consulAddr`: Consul registration server address. If set, the automatic discovery service of the CubeFS node exporter can be realized in conjunction with the Prometheus automatic discovery mechanism. If not set, the Consul automatic registration service will not be enabled. `consulMeta`: Consul metadata configuration. Non-required item, set metadata information when registering with Consul. `ipFilter`: Regular expression-based filter. Non-required item, default is empty. Exposed to Consul, used when the machine has multiple IPs. Supports forward and reverse filtering. `enablePid`: Whether to report partition id, default is false; if you want to display the information of dp or mp in the cluster, you can configure it as true. ```json { "exporterPort": 9505, "consulAddr": "http://consul.prometheus-cfs.local", "consulMeta": "k1=v1;k2=v2", "ipFilter": "10.17.*", "enablePid": "false" } ``` Requesting the corresponding metric listening interface of the service can obtain monitoring metrics, such as `curl localhost:port/metrics` For `Master`, `MetaNode`, `DataNode`, and `ObjectNode`, there are two ways to implement metric collection: Configure the Consul address of Prometheus (or the Consul address that supports the Prometheus standard syntax). After the configuration takes effect, Prometheus will actively pull monitoring metrics. If the Consul address is not configured, the following example is used: Modify the Prometheus YAML configuration file and add the metric collection source ```yaml job_name: 'cubefs01' filesdconfigs: files: [ '/home/service/app/prometheus/cubefs01/*.yml' ] refresh_interval: 10s ``` Access the exporter and create an exporter file under the above configuration directory. Taking `Master` as an example, create the `master_exporter.yaml` file ```yaml targets: [ 'master1_ip:17010' ] labels: cluster: cubefs01 ``` After the configuration is complete, start Prometheus. The relevant services of the `Erasure Coding Subsystem (Blobstore)` currently only support the second method of collecting metrics.
Project: CubeFS (Runtime / Cloud Native Storage)
File: data-partition.md

``` bash curl -v "http://10.196.59.198:17010/dataPartition/create?count=400&name=test" ``` Creates a specified number of data shards. Parameter List | Parameter | Type | Description | |--|--|| | count | int | Number of data shards to create | | name | string | Volume name | ``` bash curl -v "http://10.196.59.198:17010/dataPartition/get?id=100" | python -m json.tool ``` Displays detailed information about the data shard, including the number of replicas, volume information, etc. Parameter List | Parameter | Type | Description | |--|--|| | id | uint64 | Data shard ID | Response Example ``` json { "PartitionID": 100, "LastLoadedTime": 1544082851, "ReplicaNum": 3, "Status": 2, "Replicas": {}, "Hosts": {}, "Peers": {}, "Zones": {}, "MissingNodes": {}, "VolName": "test", "VolID": 2, "FileInCoreMap": {}, "FilesWithMissingReplica": {} } ``` ``` bash curl -v "http://10.196.59.198:17010/dataPartition/decommission?id=13&addr=10.196.59.201:17310" ``` Removes a replica of the data shard and creates a new replica. Parameter List | Parameter | Type | Description | |--|--|--| | id | uint64 | Data shard ID | | addr | string | Address of the replica to be removed | ``` bash curl -v "http://10.196.59.198:17010/dataPartition/load?id=1" ``` Sends a task to compare the replica files for each replica of the data shard, and then asynchronously checks whether the file CRC on each replica is consistent. Parameter List | Parameter | Type | Description | |--|--|| | id | uint64 | Data shard ID |
Project: Submariner (Runtime / Cloud Native Network)
File: membership.md

name: Submariner Member Request about: Request Submariner GitHub org Membership title: 'REQUEST: New Membership request for <your-GH-handle>' labels: member-request assignees: '' e.g. (at)example_user [ ] I have reviewed the contributor roles guidelines (https://submariner.io/community/contributor-roles/) [ ] I have enabled 2FA on my GitHub account (https://github.com/settings/security) [ ] I have subscribed to the submariner-dev e-mail list (https://groups.google.com/forum/#!forum/submariner-dev) [ ] I have multiple contributions to Submariner that meet the requirements listed in the community membership guidelines [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application (at)sponsor-1 (at)sponsor-2 Multiple contributions to Submariner that meet the requirements listed in the community membership guidelines
Project: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.5.md

- https://github.com/heptio/ark/tree/v0.5.1 If a Service is headless, retain ClusterIP = None when backing up and restoring. Use the specified --label-selector when listing backups, schedules, and restores. Restore namespace mapping functionality that was accidentally broken in 0.5.0. Always include namespaces in the backup, regardless of the --include-cluster-resources setting. https://github.com/heptio/ark/tree/v0.5.0 The backup tar file format has changed. Backups created using previous versions of Ark cannot be restored using v0.5.0. When backing up one or more specific namespaces, cluster-scoped resources are no longer backed up by default, with the exception of PVs that are used within the target namespace(s). Cluster-scoped resources can still be included by explicitly specifying `--include-cluster-resources`. Add customized user-agent string for Ark CLI Switch from glog to logrus Exclude nodes from restoration Add a FAQ Record PV availability zone and use it when restoring volumes from snapshots Back up the PV associated with a PVC Add `--include-cluster-resources` flag to `ark backup create` Add `--include-cluster-resources` flag to `ark restore create` Properly support resource restore priorities across cluster-scoped and namespace-scoped resources Support `ark create ...` and `ark get ...` Make ark run as cluster-admin Add pod exec backup hooks Support cross-compilation & upgrade to go 1.9 Make config change detection more robust
Project: HwameiStor (Runtime / Cloud Native Storage)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Longhorn (Runtime / Cloud Native Storage)
File: bug.md

name: Bug report about: Create a bug report title: "[BUG]" labels: ["kind/bug", "require/qa-review-coverage", "require/backport"] assignees: '' <!--A clear and concise description of the bug.--> <!--Please provide the steps to reproduce the case--> <!--A clear and concise description of what you expected to happen.--> <!--PLEASE provide a support bundle when the issue happens. You can generate a support bundle using the link at the footer of the Longhorn UI. Check . Then, attach to the issue or send to longhorn-support-bundle@suse.com --> <!-- Suggest checking the doc of the best practices of using Longhorn. --> Longhorn version: Impacted volume (PV): <!-- PLEASE specify the volume name to better identify the cause --> Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: Number of control plane nodes in the cluster: Number of worker nodes in the cluster: Node config OS type and version: Kernel version: CPU per node: Memory per node: Disk type (e.g. SSD/NVMe/HDD): Network bandwidth between the nodes (Gbps): Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Number of Longhorn volumes in the cluster: <!-- Please add any other context about the problem here. -->
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_group_add.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Add a multicast group. Add a multicast group to the node. ``` cilium-dbg bpf multicast group add <group> [flags] ``` ``` The following command adds group 229.0.0.1 to BPF multicast map of the node: cilium-dbg bpf multicast group add 229.0.0.1 ``` ``` -h, --help help for add ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage the multicast groups.
Project: Antrea (Runtime / Cloud Native Network)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: kind/feature assignees: '' Describe the problem/challenge you have <!-- A description of the current limitation/problem/challenge that you are experiencing.--> Describe the solution you'd like <!-- A description of what you want to happen. --> Anything else you would like to add? <!-- Anything else which is relevant and may help us understand the issue. -->
Project: CubeFS (Runtime / Cloud Native Storage)
File: zone.md

Setting cluster zones can prevent the entire cluster from becoming unavailable due to a single partition failure. When each node starts, the cell set will automatically join the partition. ``` bash $ cfs-cli zone list ``` If you accidentally set the volume partition incorrectly and want to change the partition: ``` bash $ cfs-cli volume update {volume name} --zone-name={zone name} ``` Most parameters in the cluster have default values, and the default zone name is "default". It should be noted that there must be enough datanodes and metanodes in a partition at the same time, otherwise, when creating a volume in the partition, either the data partition initialization will fail or the metadata partition initialization will fail. Each zone will have several nodesets, and the default capacity of each nodeset is 18 nodes. Because CubeFS has implemented multi-raft, each node has started a raft server process, and each raft server manages m raft instances on the node. If the other replicas of these raft instances are distributed on n nodes and the raft instances send raft heartbeats between them, the heartbeats will be transmitted between n nodes. As the cluster scales up, n will become relatively large. Through the nodeset restriction, the heartbeats are relatively independent within the nodeset, avoiding the heartbeat storm problem at the cluster level. We use the multi-raft and nodeset mechanisms together to avoid the problem of raft heartbeat storms. The dp/mp is evenly distributed in the ns. Each time a dp/mp is created, it will start polling from the ns where the previous dp/mp was located to find an available ns for creation. For dp/mp with 3 replicas, dp/mp will only select the ns when there are at least 3 available nodes in the ns. `count(ns)>= 18*n + 3`
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_group_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete a multicast group. Delete a multicast group from the node. ``` cilium-dbg bpf multicast group delete <group> [flags] ``` ``` The following command deletes group 229.0.0.1 from BPF multicast map of the node: cilium-dbg bpf multicast group delete 229.0.0.1 ``` ``` -h, --help help for delete ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage the multicast groups.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|