cwielenb/CNCF-Dataset huggingface dataset:
Project: Antrea (Runtime / Cloud Native Network)
File: MAINTAINERS.md

This is the current list of maintainers for the Antrea project. The maintainer role is described in . | Maintainer | GitHub ID | Affiliation | | - | | -- | | Antonin Bas | antoninbas | VMware | | Jianjun Shen | jianjuns | VMware | | Quan Tian | tnqn | VMware | | Salvatore Orlando | salv-orlando | VMware |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_bandwidth-qdiscs.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show contents of table "bandwidth-qdiscs" ``` cilium-dbg statedb bandwidth-qdiscs [flags] ``` ``` -h, --help help for bandwidth-qdiscs -w, --watch duration Watch for new changes with the given interval (e.g. --watch=100ms) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Inspect StateDB
Project: Velero (Runtime / Cloud Native Storage)
File: namespace.md

title: "Run in a non-default namespace" layout: docs The Velero installation and backups by default are run in the `velero` namespace. However, it is possible to use a different namespace. Use the `--namespace` flag, in conjunction with the other flags in the `velero install` command (as shown in the ). This will inform Velero where to install. To have namespace consistency, specify the namespace for all Velero operational commands to be the same as the namespace used to install Velero: ```bash velero client config set namespace=<NAMESPACE_VALUE> ``` Alternatively, you may use the global `--namespace` flag with any operational command to tell Velero where to run.
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.9.md

title: "Upgrading to Velero 1.9" layout: docs Velero installed. If you're not yet running at least Velero v1.6, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Install the Velero v1.9 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.9.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.9.0 only v1 CRD will be supported during installation, therefore, the v1.9.0 will only work on kubernetes version >= v1.16 Update the container image used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.9.0 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.9.0 \ --namespace velero ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.9.0 Git commit: <git SHA> Server: Version: v1.9.0 ``` We have deprecated the way to indicate the default backup storage location. Previously, that was indicated according to the backup storage location name set on the velero server-side via the flag `velero server --default-backup-storage-location`. Now we configure the default backup storage location on the velero client-side. Please refer to the on how to indicate which backup storage location is the default one. After upgrading, if there is a previously created backup storage location with the name that matches what was defined on the server side as the default, it will be automatically set as the `default`.
Project: Alluxio (Runtime / Cloud Native Storage)
File: Azure-Blob-Store.md

layout: global title: Azure Blob Store This guide describes how to configure Alluxio with {:target="_blank"} as the under storage system. Azure Blob Storage is Microsoft's object storage solution for the cloud. Blob Storage is optimized for storing massive amounts of unstructured data. For more information about Azure Blob Store, please read its {:target="_blank"}. If you haven't already, please see before you get started. In preparation for using Azure Blob Store with Alluxio: <table class="table table-striped"> <tr> <td markdown="span" style="width:30%">`<AZURE_CONTAINER>`</td> <td markdown="span">{:target="_blank"} or use an existing container.</td> </tr> <tr> <td markdown="span" style="width:30%">`<AZURE_DIRECTORY>`</td> <td markdown="span">The directory you want to use in that container, either by creating a new directory or using an existing one</td> </tr> <tr> <td markdown="span" style="width:30%">`<AZURE_ACCOUNT>`</td> <td markdown="span">Your Azure storage account</td> </tr> <tr> <td markdown="span" style="width:30%">`<AZUREACCOUNTKEY>`</td> <td markdown="span">Your Azure account credientials</td> </tr> </table> To use Azure Blob Store as the UFS of Alluxio root mount point, you need to configure Alluxio to use under storage systems by modifying `conf/alluxio-site.properties`. If it does not exist, create the configuration file from the template. ```shell $ cp conf/alluxio-site.properties.template conf/alluxio-site.properties ``` Specify the underfs address by modifying `conf/alluxio-site.properties` to include: ```properties alluxio.dora.client.ufs.root=wasbs://<AZURECONTAINER>@<AZUREACCOUNT>.blob.core.windows.net/<AZURE_DIRECTORY>/ ``` Specify credentials for the Azure account of the root mount point by adding the following properties in `conf/alluxio-site.properties`: ```properties fs.azure.account.key.<AZUREACCOUNT>.blob.core.windows.net=<AZUREACCOUNT_KEY> ``` Once you have configured Alluxio to Azure Blob Store, try to see that everything works. If you mount the Blob and configure the Blob path start with `wasb://`, you may see the error as follows: ``` alluxio.exception.AlluxioException: com.microsoft.azure.storage.StorageException: The account being accessed does not support http. ``` You can change the Blob path start with `wasbs://`.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: BestPractices.md

It is recommended that you create a single file that imports Stow and all the implementations to save you from doing so in every code file where you might use Stow. You can also take the opportunity to abstract the top level Stow methods that your code uses to save other code files (including other packages) from importing Stow at all. Create a file called `storage.go` in your package and add the following code: ```go import ( "gomodules.xyz/stow" // support Azure storage _ "gomodules.xyz/stow/azure" // support Google storage _ "gomodules.xyz/stow/google" // support local storage _ "gomodules.xyz/stow/local" // support swift storage _ "gomodules.xyz/stow/swift" // support s3 storage _ "gomodules.xyz/stow/s3" // support oracle storage _ "gomodules.xyz/stow/oracle" ) // Dial dials stow storage. // See stow.Dial for more information. func Dial(kind string, config stow.Config) (stow.Location, error) { return stow.Dial(kind, config) } ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-bugtool_completion_zsh.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(cilium-bugtool completion zsh) To load completions for every new session, execute once: cilium-bugtool completion zsh > "${fpath[1]}/_cilium-bugtool" cilium-bugtool completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-bugtool You will need to start a new shell for this setup to take effect. ``` cilium-bugtool completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: rkt (Runtime / Container Runtime)
File: image-fetching-behavior.md

When fetching, rkt will try to avoid unnecessary network transfers: if an updated image is already in the local store there's no need to download it again. This behavior can be controlled with the `--pull-policy` flag. The following table describes the meaning of the `--pull-policy` flag. This flag accepts one of three options: Option | Description | `new` | Default behavior in run and prepare Check the store, and if the image is missing fetch from remote `update` | Default behavior in fetch Attempt to fetch from remote, but if the remote image matches something in our store don't pull it `never` | Only check the store, and don't fetch from remote. Here we detail the actions taken by rkt when fetching from store and remote for each type of image argument. Fetch from | Image argument | Detailed behavior | | -- store | file:// | Use the specified file store | http(s):// | Check for the URL in the local store. If found, use the corresponding image. store | docker:// | Check for the URL in the local store. If found, use the corresponding image. store | image name | Check local store. If found, use that image. If there's a file in the current directory named like the image name, use that file instead. remote | file:// | Use the specified file remote | http(s):// | Search in the store if the URL is available. If it's available and the saved Cache-Control maxage > 0 determine if the image should be downloaded. If it's not expired use the image. Otherwise download (sending if available the saved ETag). If the download returns a `304 Not Modified` use the image already saved in the local store. remote | docker:// | Fetch using docker2aci. remote | image name | Execute . If discovery is successful use the discovered URL doing the above `remote` http(s):// image case. If there's a file in the current directory named like the image name, use that file instead.
Project: DANM (Runtime / Cloud Native Network)
File: ISSUE_TEMPLATE.md

<!-- This form is for bug reports and feature requests only! --> Is this a BUG REPORT or FEATURE REQUEST?: Uncomment only one, leave it on its own line: bug feature What happened: What you expected to happen: How to reproduce it: Anything else we need to know?: Environment: DANM version (use `danm -version`): Kubernetes version (use `kubectl version`): DANM configuration (K8s manifests, kubeconfig files, CNI config file): OS (e.g. from /etc/os-release): Kernel (e.g. `uname -a`): Others:
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.11.md

title: "Upgrading to Velero 1.11" layout: docs Velero installed. If you're not yet running at least Velero v1.6, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Caution: From Velero v1.10, except for using restic to do file-system level backup and restore, kopia is also been integrated, it could be upgraded from v1.10 to v1.11 directly, but it would be a little bit of difference when upgrading to v1.11 from a version lower than v1.10.0. Install the Velero v1.11 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.11.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.10.0 only v1 CRD will be supported during installation, therefore, the v1.10.0 will only work on Kubernetes version >= v1.16 Update the container image and objects fields used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl get deploy -n velero -ojson \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.11.0\"#g" \ | sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \ | sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \ | sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \ | sed "s#restic-timeout#fs-backup-timeout#g" \ | kubectl apply -f - echo $(kubectl get ds -n velero restic -ojson) \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.11.0\"#g" \ | sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \ | sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \ | kubectl apply -f - kubectl delete ds -n velero restic --force --grace-period 0 ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.11.0 Git commit: <git SHA> Server: Version: v1.11.0 ``` If it's directly upgraded from v1.10, the other steps remain the same only except for step 3 above. The details as below: Update the container image used by the Velero deployment, plugin and, optionally, the node agent daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.11.0 \ velero-plugin-for-aws=velero/velero-plugin-for-aws:v1.7.0 \ --namespace velero kubectl set image daemonset/node-agent \ node-agent=velero/velero:v1.11.0 \ --namespace velero ``` If upgraded from v1.9.x, there still remains some resources left over in the cluster and never used in v1.11.x, which could be deleted through kubectl and it is based on your desire: resticrepository CRD and related CRs velero-restic-credentials secret in velero install namespace
Project: lxd (Runtime / Container Runtime)
File: migration.md

(migration)= Incus provides tools and functionality to migrate instances in different contexts. Migrate existing Incus instances between servers : The most basic kind of migration is if you have an Incus instance on one server and want to move it to a different Incus server. For virtual machines, you can do that as a live migration, which means that you can migrate your VM while it is running and there will be no downtime. See {ref}`move-instances` for more information. Migrate physical or virtual machines to Incus instances : If you have an existing machine, either physical or virtual (VM or container), you can use the `incus-migrate` tool to create an Incus instance based on your existing machine. The tool copies the provided partition, disk or image to the Incus storage pool of the provided Incus server, sets up an instance using that storage and allows you to configure additional settings for the new instance. See {ref}`import-machines-to-instances` for more information. Migrate instances from LXC to Incus : If you are using LXC and want to migrate all or some of your LXC containers to an Incus installation on the same machine, you can use the `lxc-to-incus` tool. The tool analyzes the LXC configuration and copies the data and configuration of your existing LXC containers into new Incus containers. See {ref}`migrate-from-lxc` for more information. ```{toctree} :maxdepth: 1 :hidden: Move instances <howto/move_instances> Import existing machines <howto/importmachinesto_instances> Migrate from LXC <howto/migratefromlxc> ```
Project: Cilium (Runtime / Cloud Native Network)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-aws_metrics_list.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> List all metrics for the operator ``` cilium-operator-aws 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: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_service_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List services ``` cilium-dbg service list [flags] ``` ``` --clustermesh-affinity Print clustermesh affinity if available -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 services & loadbalancers
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_endpoint_config.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> View & modify endpoint configuration ``` cilium-dbg endpoint config <endpoint id> [<option>=(enable|disable) ...] [flags] ``` ``` endpoint config 5421 DropNotification=false TraceNotification=false PolicyVerdictNotification=true ``` ``` -h, --help help for config --list-options List available options -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 endpoints
Project: Kata Containers (Runtime / Container Runtime)
File: x86_64_cpuid.md

CPUID is designed as the CPUID filter for Intel and AMD CPU Identification. Through CPUID configuration, we could set CPU topology, Cache topology, PMU status and other features for the VMs. CPUID is developed based on the Firecracker CPUID code while we add other extensions such as CPU Topology and VPMU features. To use CPUID, you should first use KVMGETCPUID2 ioctl to get the original CPUID then use process_cpuid() provided by the db-arch to filter CPUID with the information you want and suitable for VM conditions. Currently, we support following specifications that db-arch could use to filter CPUID: ```rust pub struct VmSpec { /// The vendor id of the CPU cpuvendorid: [u8; 12], /// The id of the current logical cpu in the range [0..cpu_count]. cpu_id: u8, /// The total number of logical cpus (includes cpus that could be hotplugged). cpu_count: u8, /// The desired brand string for the guest. brand_string: BrandString, /// threads per core for cpu topology information threadspercore: u8, /// cores per die for cpu topology information coresperdie: u8, /// dies per socket for cpu topology information diespersocket: u8, /// if vpmu feature is Disabled, it means vpmu feature is off (by default) /// if vpmu feature is LimitedlyEnabled, it means minimal vpmu counters are supported (cycles and instructions) /// if vpmu feature is FullyEnabled, it means all vpmu counters are supported vpmu_feature: VpmuFeatureLevel, } ``` We will show examples for filtering CPUID. First, you need to use KVMGETCPUID2 ioctl to get the original CPUID, this part is not included in the db-cpuid. ```rust // an example for getting the cpuid in the vmm. let mut cpuid = CpuId::new(numentries).maperr(|_| errno::Error::new(libc::ENOMEM))?; let ret = unsafe {ioctlwithmutptr(self, KVMGETCPUID2(), cpuid.asmutfamstruct_ptr())}; if ret != 0 { return Err(errno::Error::last()); } ``` Then we could create the `VmSpec` to describe the VM specification we want and use process_cpuid() to filter CPUID. ```rust let cpuidvmspec = VmSpec::new( self.id, vcpuconfig.maxallvcpucount as u8, vcpuconfig.threadsper_core, vcpuconfig.coresper_die, vcpuconfig.diesper_socket, vcpuconfig.vpmufeature, ) .map_err(VcpuError::CpuId)?; processcpuid(&mut self.cpuid, &cpuidvmspec).maperr(|e| { METRICS.vcpu.process_cpuid.inc(); error!("Failure in configuring CPUID for vcpu {}: {:?}", self.id, e); VcpuError::CpuId(e) })?; ``` After the CPUID is filtered, we could use it to set the guest's CPUID.
Project: Spiderpool (Runtime / Cloud Native Network)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```