cwielenb/CNCF-Dataset huggingface dataset:
Project: Spiderpool (Runtime / Cloud Native Network)
File: spiderpool-controller.md

This page describes CLI options and ENV of spiderpool-controller. Run the spiderpool controller daemon. ``` --config-dir string config file path (default /tmp/spiderpool/config-map) ``` | env | default | description | |-||--| | SPIDERPOOLLOGLEVEL | info | Log level, optional values are "debug", "info", "warn", "error", "fatal", "panic". | | SPIDERPOOLENABLEDMETRIC | false | Enable/disable metrics. | | SPIDERPOOLENABLEDDEBUG_METRIC | false | Enable spiderpool agent to collect debug level metrics. | | SPIDERPOOLMETRICHTTP_PORT | false | The metrics port of spiderpool agent. | | SPIDERPOOLGOPSLISTEN_PORT | 5724 | The gops port of spiderpool Controller. | | SPIDERPOOLWEBHOOKPORT | 5722 | Webhook HTTP server port. | | SPIDERPOOLHEALTHPORT | 5720 | The http Port for spiderpoolController, for health checking and http service. | | SPIDERPOOLGCIP_ENABLED | true | Enable/disable IP GC. | | SPIDERPOOLGCSTATELESSTERMINATINGPODONREADYNODEENABLED | true | Enable/disable IP GC for stateless Terminating pod when the pod corresponding node is ready. | | SPIDERPOOLGCSTATELESSTERMINATINGPODONNOTREADYNODE_ENABLED | true | Enable/disable IP GC for stateless Terminating pod when the pod corresponding node is not ready. | | SPIDERPOOLGCADDITIONALGRACEDELAY | true | The gc delay seconds after the pod times out of deleting graceful period. | | SPIDERPOOLGCDEFAULTINTERVALDURATION | true | The gc all interval duration. | | SPIDERPOOLMULTUSCONFIG_ENABLED | true | Enable/disable SpiderMultusConfig. | | SPIDERPOOLCNICONFIG_DIR | /etc/cni/net.d | The host path of the cni config directory. | | SPIDERPOOLCILIUMCONFIGMAPNAMESPACENAME | kube-system/cilium-config. | The cilium's configMap, default is kube-system/cilium-config. | | SPIDERPOOLCOORDINATORDEFAULT_NAME | default | the name of default spidercoordinator CR | Notify of stopping spiderpool-controller daemon. Get local metrics. ``` --port string http server port of local metric (default to 5721) ``` Show status: Whether local is controller leader ... ``` --port string http server port of local metric (default to 5720) ```
Project: CRI-O (Runtime / Container Runtime)
File: crio.conf.d.5.md

% crio.conf.d(5) crio.conf.d - directory for drop-in configuration files for CRI-O Additionally to configuration in crio.conf(5), CRI-O allows to drop configuration snippets into the crio.conf.d directory. The default directory is /etc/crio/crio.conf.d/. The path can be changed via CRIO's --config-dir command line option. When it exists, the main configuration file (/etc/crio/crio.conf by default) is read before any file in the configuration directory (/etc/crio/crio.conf.d). Settings in that file have the lowest precedence. Files in the configuration directory are sorted by name in lexical order and applied in that order. If multiple configuration files specify the same configuration option the setting specified in file sorted last takes precedence over any other value. That is if both 00-default.conf and 10-custom.conf exist in crio.conf.d and both specify different values for a certain configuration option the value from 10-custom.conf will be applied. crio.conf(5), crio(8)
Project: lxd (Runtime / Container Runtime)
File: devices_unix_block.md

(devices-unix-block)= ```{note} The `unix-block` device type is supported for containers. It supports hotplugging. ``` Unix block devices make the specified block device appear as a device in the instance (under `/dev`). You can read from the device and write to it. `unix-block` devices have the following device options: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group devices-unix-char-block start --> :end-before: <!-- config group devices-unix-char-block end --> ``` (devices-unix-block-hotplugging)= Hotplugging is enabled if you set `required=false` and specify the `source` option for the device. In this case, the device is automatically passed into the container when it appears on the host, even after the container starts. If the device disappears from the host system, it is removed from the container as well.
Project: StratoVirt (Runtime / Container Runtime)
File: trace.md

This document describes the way for debugging and profiling in StratoVirt and how to use it. First, you need to modify or crate toml file in the trace/trace_info directory to add a new event or scope in order to generate the trace function. For example: ```toml [[events]] name = "virtioreceiverequest" args = "device: String, behaviour: String" message = "{}: Request received from guest {}, ready to start processing." enabled = true [[scopes]] name = "update_cursor" args = "" message = "" enabled = true ``` In the above configuration, "name" is used to represent the only trace, and duplication is not allowed; "message" and "args" will be formatted as information output by trace; "enabled" indicates whether it is enabled during compilation. Just call the trace function where needed. ```rust fn process_queue(&mut self) -> Result<()> { trace::virtioreceiverequest("Rng".tostring(), "to IO".tostring()); let mut queue_lock = self.queue.lock().unwrap(); let mut need_interrupt = false; ...... } fn updatecursor(&mut self, infocursor: &VirtioGpuUpdateCursor, hdr_type: u32) -> Result<()> { // Trace starts from here, and end when it leaves this scope trace::tracescopestart!(update_cursor); ...... } ``` Trace state in StratoVirt are disabled by default. Users can control whether the trace state is enabled through the command line or qmp command. Before starting, you can prepare the trace list that needs to be enabled and pass it to StratoVirt through . During the running, you can send the command through the qmp socket to enable or disable trace state. Similarly, using the command can check whether the setting is successful. By setting different features during compilation, trace can generate specified code to support different trace tools. StratoVirt currently supports two kinds of settings. StratoVirt supports outputting trace to the log file at trace level. Turn on the trace_to_logger feature to use is. Ftrace is a tracer provided by Linux kernel, which can help linux developers to debug or analyze issues. As ftrace can avoid performance penalty, it's especially suited for performance issues. It can be enabled by turning on the trace_to_ftrace feature during compilation. StratoVirt use ftrace by writing trace data to ftrace marker, and developers can read trace records from trace file under mounted ftrace director, e.g. /sys/kernel/debug/tracing/trace. HiTraceMeter(https://gitee.com/openharmony/hiviewdfx_hitrace) is tool used by developers to trace process and measure performance. Based on the Ftrace, it provides the ability to measure the execution time of user-mode application code. After turning on the trace_to_hitrace feature, it can be used on HarmonyOS.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_create_schedule.md

title: "ark create schedule" layout: docs Create a schedule The --schedule flag is required, in cron notation: | Character Position | Character Period | Acceptable Values | | -|:-:| --:| | 1 | Minute | 0-59,* | | 2 | Hour | 0-23,* | | 3 | Day of Month | 1-31,* | | 4 | Month | 1-12,* | | 5 | Day of Week | 0-7,* | ``` ark create schedule NAME --schedule [flags] ``` ``` ark create schedule NAME --schedule="0 /6 " ``` ``` --exclude-namespaces stringArray namespaces to exclude from the backup --exclude-resources stringArray resources to exclude from the backup, formatted as resource.group, such as storageclasses.storage.k8s.io -h, --help help for schedule --include-cluster-resources optionalBool[=true] include cluster-scoped resources in the backup --include-namespaces stringArray namespaces to include in the backup (use '' for all namespaces) (default ) --include-resources stringArray resources to include in the backup, formatted as resource.group, such as storageclasses.storage.k8s.io (use '*' for all resources) --label-columns stringArray a comma-separated list of labels to be displayed as columns --labels mapStringString labels to apply to the backup -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'. --schedule string a cron expression specifying a recurring schedule for this backup to run -l, --selector labelSelector only back up resources matching this label selector (default <none>) --show-labels show labels in the last column --snapshot-volumes optionalBool[=true] take snapshots of PersistentVolumes as part of the backup --ttl duration how long before the backup can be garbage collected (default 720h0m0s) ``` ``` --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 ``` - Create ark resources
Project: CubeFS (Runtime / Cloud Native Storage)
File: rest_docs.md

Generating ReST pages from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } err := doc.GenReSTTree(cmd, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a ReST document `/tmp/test.rst` This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "log" "io/ioutil" "os" "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "github.com/spf13/cobra/doc" ) func main() { kubectl := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, ioutil.Discard, ioutil.Discard) err := doc.GenReSTTree(kubectl, "./") if err != nil { log.Fatal(err) } } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenReST` instead of `GenReSTTree` ```go out := new(bytes.Buffer) err := doc.GenReST(cmd, out) if err != nil { log.Fatal(err) } ``` This will write the ReST doc for ONLY "cmd" into the out, buffer. Both `GenReST` and `GenReSTTree` have alternate versions with callbacks to get some control of the output: ```go func GenReSTTreeCustom(cmd *Command, dir string, filePrepender func(string) string, linkHandler func(string, string) string) error { //... } ``` ```go func GenReSTCustom(cmd Command, out bytes.Buffer, linkHandler func(string, string) string) error { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered ReST file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered links to the commands, given a command name and reference. This is useful while converting rst to html or while generating documentation with tools like Sphinx where `:ref:` is used: ```go // Sphinx cross-referencing format linkHandler := func(name, ref string) string { return fmt.Sprintf(":ref:`%s <%s>`", name, ref) } ```
Project: lxd (Runtime / Container Runtime)
File: devices_unix_hotplug.md

(devices-unix-hotplug)= ```{note} The `unix-hotplug` device type is supported for containers. It supports hotplugging. ``` Unix hotplug devices make the requested Unix device appear as a device in the instance (under `/dev`). If the device exists on the host system, you can read from it and write to it. The implementation depends on `systemd-udev` to be run on the host. `unix-hotplug` devices have the following device options: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group devices-unix-hotplug start --> :end-before: <!-- config group devices-unix-hotplug end --> ```
Project: Weave Net (Runtime / Cloud Native Network)
File: using-proxy.md

title: Using The Weave Docker API Proxy menu_order: 10 search_type: Documentation When containers are created via the Weave Net proxy, their entrypoint is modified to wait for the Weave network interface to become available. When they are started via the Weave Net proxy, containers are and connected to the Weave network. To create and start a container via the Weave Net proxy run: host1$ docker run -ti weaveworks/ubuntu or, equivalently run: host1$ docker create -ti --name=foo weaveworks/ubuntu host1$ docker start foo Specific IP addresses and networks can be supplied in the `WEAVE_CIDR` environment variable, for example: host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti weaveworks/ubuntu Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR` variable by space-separating them, as in `WEAVE_CIDR="10.2.1.1/24 10.2.2.1/24"`. The Docker NetworkSettings (including IP address, MacAddress, and IPPrefixLen), are still returned when `docker inspect` is run. If you want `docker inspect` to return the Weave NetworkSettings instead, then the proxy must be launched using the `--rewrite-inspect` flag. This command substitutes the Weave network settings when the container has a Weave Net IP. If a container has more than one Weave Net IP, then the inspect call only includes one of them. host1$ weave launch --rewrite-inspect By default, multicast traffic is routed over the Weave network. To turn this off, for example, because you want to configure your own multicast route, add the `--no-multicast-route` flag to `weave launch`. `--without-dns` -- stop telling containers to use `--log-level=debug|info|warning|error` -- controls how much information to emit for debugging `--no-restart` -- remove the default policy of `--restart=always`, if you want to control start-up of the proxy yourself If for some reason you need to disable the proxy, but still want to start other Weave Net components (router, weaveDNS), you can do so using: weave launch --proxy=false See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator_completion_powershell.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-operator completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-operator completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Velero (Runtime / Cloud Native Storage)
File: 2082-bsl-delete-associated-resources_design.md

Issue #2082 requested that with the command `velero backup-location delete <bsl name>` (implemented in Velero 1.6 with #3073), the following will be deleted: associated Velero backups (to be clear, these are custom Kubernetes resources called "backups" that are stored in the API server) associated Restic repositories (custom Kubernetes resources called "resticrepositories") This design doc explains how the request will be implemented. When a BSL resource is deleted from its Velero namespace, the associated custom Kubernetes resources, backups and Restic repositories, can no longer be used. It makes sense to clean those resources up when a BSL is deleted. Update the `velero backup-location delete <bsl name>` command to delete associated backup and Restic repository resources in the same Velero namespace. to fix bug #2697 alongside this issue. However, I think that should be fixed separately because although it is similar (restore objects are not being deleted), it is also quite different. One is adding a command feature update (this issue) and the other is a bug fix and each affect different parts of the code base. Update the `velero backup-location delete <bsl name>` command to do the following: find in the same Velero namespace from which the BSL was deleted the associated backup resources and Restic repositories, called "backups.velero.io" and "resticrepositories.velero.io" respectively delete the resources found The above logic will be added to . I had considered deleting the backup files (the ones in json format and tarballs) in the BSL itself. However, a standard use case is to back up a cluster and then restore into a new cluster. Deleting the backup storage location in either location is not expected to remove all of the backups in the backup storage location and should not be done.
Project: lxd (Runtime / Container Runtime)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at coc@linuxcontainers.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html> For answers to common questions about this code of conduct, see <https://www.contributor-covenant.org/faq>
Project: HwameiStor (Runtime / Cloud Native Storage)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-agent_completion_powershell.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-agent completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-agent completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Project Calico (Runtime / Cloud Native Network)
File: generate-purpose-issue-template.md

name: Generate Purpose Issue Template about: Generate Purpose Issue Template title: '' labels: '' assignees: '' <! Provide a general summary of the issue in the Title above --> <! If you believe the issue may have security implications, please report it as a vulnerability --> <! Report a vulnerability: https://github.com/projectcalico/calico/security --> <! If you're describing a bug, tell us what should happen --> <! If you're suggesting a change/improvement, tell us how it should work --> <! If describing a bug, tell us what happens instead of the expected behavior --> <! If suggesting a change/improvement, explain the difference from current behavior --> <! Not obligatory, but suggest a fix/reason for the bug, --> <! or ideas how to implement the addition or change --> <! Provide a link to a live example, or an unambiguous set of steps to --> <! reproduce this bug. Include code to reproduce, if relevant --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <! Include as many relevant details about the environment you experienced the bug in --> Calico version Orchestrator version (e.g. kubernetes, mesos, rkt): Operating System and version: Link to your project (optional):
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_policy_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Dump all policy maps ``` cilium-dbg bpf policy list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage policy related BPF maps