cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Net (Runtime / Cloud Native Network)
File: stop-remove-peers-ipam.md

title: Starting, Stopping and Removing Peers menu_order: 40 search_type: Documentation You may wish to `weave stop` and re-launch to change some config or to upgrade to a new version. Provided that the underlying protocol hasn't changed, Weave Net picks up where it left off and learns from peers in the network which address ranges it was previously using. If, however, you run `weave reset` this removes the peer from the network so if Weave Net is run again on that node it will start from scratch. For failed peers, the `weave rmpeer` command can be invoked to permanently remove the ranges allocated to said peers. This allows other peers to allocate IPs in the ranges previously owned by the removed peers, and as such should be used with extreme caution: if the removed peers had transferred some range of IP addresses to other peers but this is not known to the whole network, or if some of them later rejoin the Weave network, the same IP address may be allocated twice. Assume you had started the three peers in the , and then host3 caught fire, you can go to one of the other hosts and run: host1$ weave rmpeer host3 524288 IPs taken over from host3 Weave Net takes all the IP address ranges owned by host3 and transfers them to be owned by host1. The name "host3" is resolved via the 'nickname' feature of Weave Net, which defaults to the local host name. Alternatively, you can supply a peer name as shown in `weave status`. Do not invoke `weave rmpeer` for the same peer on more than one host. The removed peer's address range cannot be left dangling and is therefore reassigned to the peer on which `weave rmpeer` was run. Consequently, if you run `weave rmpeer` for the same peer on more than one host, the removed peer's address range will be owned by multiple peers. Once the peers detect this inconsistency, they log the error and drop the connection that supplied the inconsistent data. The rest of the peers will carry on with their view of the world, but the network will not function correctly. Depending on the timing of the `rmpeer` and the communication between peers, several peer cliques may form - groups of peers that are talking to each other, but repeatedly drop attempted connections with peers in other cliques. See Also *
Project: DatenLord (Runtime / Cloud Native Storage)
File: datenlord_dashboard.md

Datenlord is using Grafana dashboard to show all the metrics, which can be configured dynamically to display different information. Currently Datenlord has two dashboards. `Node resources` and `Application and Pod resources`. Both of them have 9 panels currently. All the nodes resources information is displayed in this dashboard, including memory usage, CPU usage, network information, etc. The default data is all nodes resources, you can filter the data to a specific node by clicking the top `Node` button. Currently it has 9 panels: Node memory usage rate, Node memory usage, Pods number, Node storage information, Namespace details, Node CPU usage rate, Node CPU usage, network and node information details. To add a new panel, just click the top side `Add Panel` button Then choose the `Pramethues` as the Data source and input the query to collect the metrics data. All the application, instance and Pod information are displayed in this dashboard. To display a specific application's resource information, you can use the top side filter panel: When you choose a specific application, all the following metrics (tables, charts, guages) will be filtered to only display the resources for this application.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: demo.md

In this chapter, we will cover two demo apps. We will build them from Rust source code, build OCI images around them, and then publish the images to Docker Hub. If you have not done so, please Next, explore the examples Since we have already built and published those demo apps on Docker Hub, you could also just go straight to the container runtime sections to use these images.
Project: gVisor (Runtime / Container Runtime)
File: community.md

To contribute code, please read the . Please note that the applies to community forums as well as technical participation. The project maintains two mailing lists: for accouncements and general discussion. for development and contribution. We also have a . We'd love to hear from you! The community calendar shows upcoming public meetings and opportunities to collaborate or discuss the project. Meetings are planned and announced ahead of time via the mailing list. These meetings are public: anyone can join. <iframe src="https://calendar.google.com/calendar/b/1/embed?showTitle=0&amp;height=600&amp;wkst=1&amp;bgcolor=%23FFFFFF&amp;src=bd6f4k210u3ukmlj9b8vl053fk%40group.calendar.google.com&amp;color=%23AB8B00&amp;ctz=America%2FLos_Angeles" style="border-width:0" width="600" height="400" frameborder="0" scrolling="no"></iframe>
Project: OpenEBS (Runtime / Cloud Native Storage)
File: NOTICE.md

The source code developed under the OpenEBS Project is licensed under Apache 2.0. However, the OpenEBS project contains unmodified/modified subcomponents from other Open Source Projects with separate copyright notices and license terms. Your use of the source code for these subcomponents is subject to the terms and conditions as defined by those source projects. OpenEBS uses to perform license scan on all its projects. The links to the auto-generated FOSSA reports on the 3rd Party Software used by each of the OpenEBS project are listed below: | Component | Repo Link | License | Dependency and Notes ||||| | Storage Device Management - NDM | https://github.com/openebs/node-disk-manager | Apache 2.0 | | Storage Management - Maya | https://github.com/openebs/maya | Apache 2.0 | | Data Engine - Jiva | https://github.com/openebs/jiva | Apache 2.0 | | Data Engine - cStor Replica | https://github.com/openebs/libcstor | Apache 2.0 | | Data Engine - cStor Target | https://github.com/openebs/istgt | Apache 2.0 | | Data Engine - cStor (uZFS) | https://github.com/openebs/cstor | CDDL 1.0 |
Project: Singularity (Runtime / Container Runtime)
File: COPYRIGHT.md

Copyright (c) 2017-2018, Sylabs, Inc. All rights reserved. Copyright (c) 2015-2017, Gregory M. Kurtzer. All rights reserved. Copyright (c) 2016-2017, The Regents of the University of California, through Lawrence Berkeley National Laboratory (subject to receipt of any required approvals from the U.S. Dept. of Energy). All rights reserved.
Project: lxd (Runtime / Container Runtime)
File: instance_config.md

(instance-config)= The instance configuration consists of different categories: Instance properties : Instance properties are specified when the instance is created. They include, for example, the instance name and architecture. Some of the properties are read-only and cannot be changed after creation, while others can be updated by {ref}`setting their property value <instances-configure-properties>` or {ref}`editing the full instance configuration <instances-configure-edit>`. In the YAML configuration, properties are on the top level. See {ref}`instance-properties` for a reference of available instance properties. Instance options : Instance options are configuration options that are related directly to the instance. They include, for example, startup options, security settings, hardware limits, kernel modules, snapshots and user keys. These options can be specified as key/value pairs during instance creation (through the `--config key=value` flag). After creation, they can be configured with the and commands. In the YAML configuration, options are located under the `config` entry. See {ref}`instance-options` for a reference of available instance options, and {ref}`instances-configure-options` for instructions on how to configure the options. Instance devices : Instance devices are attached to an instance. They include, for example, network interfaces, mount points, USB and GPU devices. Devices are usually added after an instance is created with the command, but they can also be added to a profile or a YAML configuration file that is used to create an instance. Each type of device has its own specific set of options, referred to as instance device options. In the YAML configuration, devices are located under the `devices` entry. See {ref}`devices` for a reference of available devices and the corresponding instance device options, and {ref}`instances-configure-devices` for instructions on how to add and configure instance devices. ```{toctree} :maxdepth: 1 :hidden: ../reference/instance_properties.md ../reference/instance_options.md ../reference/devices.md ../reference/instance_units.md ```
Project: Weave Net (Runtime / Cloud Native Network)
File: awsvpc.md

title: Configuring IP Routing on an Amazon Web Services Virtual Private Cloud menu_order: 80 search_type: Documentation If your container infrastructure is running entirely within Amazon Web Services (AWS) Elastic Compute Cloud (EC2), then you can enable AWS-VPC mode with Weave Net. In AWS-VPC mode, containers are networked without using an overlay and allows network speeds close to that of the underlying network. With AWS-VPC enabled, Weave Net manages IP addresses and connects containers to the network as usual, but instead of wrapping each packet and sending it to its destination, Weave Net instructs the AWS network router with the ranges of container IP addresses and the instances on which they live. First, your AWS instances need to be given write access to the route table via its . If you have an existing IAM Role then extend it, otherwise create a new role. The role must have a attached which allows the following : ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:ReplaceRoute", "ec2:DescribeRouteTables", "ec2:DescribeInstances" ], "Resource": [ "*" ] } ] } ``` Secondly, your Security Group must allow network traffic between instances. You must open TCP port 6783 which is the port that Weave Net uses to manage the network and also allow any ports which your own containers use. >Remember: There is no network overlay in this mode, and so, IP packets with container addresses will flow over the AWS network unmodified. Finally, since Weave will be operating with IP addresses outside of the range allocated by Amazon, you must disable "Source/Destination check" on each machine. Launch Weave Net with the `--awsvpc` flag: $ weave launch --awsvpc [other hosts] >>Note: You will still need to supply the names or IP addresses of other hosts in your cluster. AWS-VPC mode does not inter-operate with other Weave Net modes; it is all or nothing. In this mode, all hosts in a cluster must be AWS instances. (We hope to ease this limitation in future.) The `weave launch` command waits until the is ready, i.e. until after this peer has been able to make contact with other peers and confirm that it has joined the cluster the bridge. Without AWS-VPC, `weave launch` returns without waiting. The AWS network does not support multicast. The number of hosts in a cluster is limited by the maximum size of your AWS route table. This is limited to 50 entries though you can request an increase to 100 by contacting Amazon. All of your containers must be on the same network, with no subnet isolation. (We hope to ease this limitation in future.) The Maximum Transmission Unit, or MTU, is the technical term for the limit on how big a single packet can be on the network. Weave Net defaults to 1376 bytes. This default works across almost all networks, but for better performance you can set it to a larger MTU size. The AWS network supports packets of up to 9000 bytes. In AWS-VPC mode you can run the following: $ WEAVE_MTU=9000 weave launch --awsvpc host2 host3 See Also
Project: Carina (Runtime / Cloud Native Storage)
File: runtime-container.md

carina-node runs in a cumtomized containers, embedding lvm2. Refer `docs/runtime-container` to learn abount how it works. building carina-node runtime image ```shell $ cd docs/runtime-container $ docker build -t runtime-container:latest . ``` multi-arch buildin ```shell $ cd docs/runtime-container $ docker buildx build -t centos-mutilarch-lvm2:runtime --platform=linux/arm,linux/arm64,linux/amd64 . --push ```
Project: gVisor (Runtime / Container Runtime)
File: docker.md

This page shows you how to deploy a sample site using . to install runsc with Docker. This document assumes that the runtime name chosen is `runsc`. Now, let's deploy a WordPress site using Docker. WordPress site requires two containers: web server in the frontend, MySQL database in the backend. Note: This example uses gVisor to sandbox the frontend web server, but not the MySQL database backend. In a production setup, due to imposed by gVisor, it is not recommended to run your database in a sandbox. The frontend is the critical component with the largest outside attack surface, where gVisor's security/performance trade-off makes the most sense. See the [Production guide] for more details. First, let's define a few environment variables that are shared between both containers: ```bash export MYSQLPASSWORD=${YOURSECRETPASSWORDHERE?} export MYSQL_DB=wordpress export MYSQL_USER=wordpress ``` Next, let's start the database container running MySQL and wait until the database is initialized: ```shell $ docker run --name mysql -d \ -e MYSQLRANDOMROOT_PASSWORD=1 \ -e MYSQLPASSWORD="${MYSQLPASSWORD}" \ -e MYSQLDATABASE="${MYSQLDB}" \ -e MYSQLUSER="${MYSQLUSER}" \ mysql:5.7 $ docker logs mysql |& grep 'port: 3306 MySQL Community Server (GPL)' ``` Once the database is running, you can start the WordPress frontend. We use the `--link` option to connect the frontend to the database, and expose the WordPress to port 8080 on the localhost. ```shell $ docker run --runtime=runsc --name wordpress -d \ --link mysql:mysql \ -p 8080:80 \ -e WORDPRESSDBHOST=mysql \ -e WORDPRESSDBUSER="${MYSQL_USER}" \ -e WORDPRESSDBPASSWORD="${MYSQL_PASSWORD}" \ -e WORDPRESSDBNAME="${MYSQL_DB}" \ -e WORDPRESSTABLEPREFIX=wp_ \ wordpress ``` Now, you can access the WordPress website pointing your favorite browser to <http://localhost:8080>. Congratulations! You have just deployed a WordPress site using Docker and gVisor. Learn how to deploy WordPress with or . Before deploying this to production, see the [Production guide] for how to take full advantage of gVisor.
Project: runc (Runtime / Container Runtime)
File: SECURITY.md

The libseccomp-golang Security Vulnerability Handling Process =============================================================================== https://github.com/seccomp/libseccomp-golang This document document attempts to describe the processes through which sensitive security relevant bugs can be responsibly disclosed to the libseccomp-golang project and how the project maintainers should handle these reports. Just like the other libseccomp-golang process documents, this document should be treated as a guiding document and not a hard, unyielding set of regulations; the bug reporters and project maintainers are encouraged to work together to address the issues as best they can, in a manner which works best for all parties involved. Problems with the libseccomp-golang library that are not suitable for immediate public disclosure should be emailed to the current libseccomp-golang maintainers, the list is below. We typically request at most a 90 day time period to address the issue before it is made public, but we will make every effort to address the issue as quickly as possible and shorten the disclosure window. Paul Moore, paul@paul-moore.com Tom Hromatka, tom.hromatka@oracle.com Kir Kolyshkin, kolyshkin@gmail.com Upon disclosure of a bug, the maintainers should work together to investigate the problem and decide on a solution. In order to prevent an early disclosure of the problem, those working on the solution should do so privately and outside of the traditional libseccomp-golang development practices. One possible solution to this is to leverage the GitHub "Security" functionality to create a private development fork that can be shared among the maintainers, and optionally the reporter. A placeholder GitHub issue may be created, but details should remain extremely limited until such time as the problem has been fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to the problem, the GitHub issue title should include the vulnerability tag once the problem has been disclosed. Whenever possible, responsible reporting and patching practices should be followed, including notification to the linux-distros and oss-security mailing lists. https://oss-security.openwall.org/wiki/mailing-lists/distros https://oss-security.openwall.org/wiki/mailing-lists/oss-security
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bgp_peers.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List current state of all peers List state of all peers defined in CiliumBGPPeeringPolicy ``` cilium-dbg bgp peers [flags] ``` ``` -h, --help help for peers -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 ``` - Access to BGP control plane
Project: HwameiStor (Runtime / Cloud Native Storage)
File: 2022-04-22-welcome.md

slug: welcome title: Welcome authors: [Michael] tags: [hello, Hwameistor] Welcome to the Hwameistor blog space. Here you can keep up with the progress of the Hwameistor open source project and recent hot topics. We also plan to include release notes for major releases, guidance articles, community-related events, and possibly some development tips, and interesting topics within the team. If you are interested in contributing to this open source project and would like to join the discussion or make some guest blog posts, please contact us. GitHub address is: https://github.com/hwameistor
Project: Inclavare Containers (Runtime / Container Runtime)
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: Virtual Kubelet (Runtime / Container Runtime)
File: architecture.md

title: Architecture description: How Virtual Kubelet works weight: 3 This document provides a high-level overview of how Virtual Kubelet works. It begins by explaining how normali.e. non-virtual and then by way of contrast. Ordinarily, Kubernetes implement Pod and container operations for each Kubernetes Node. They run as an agent on each Node, whether that Node is a physical server or a virtual machine, and handles Pod/container operations on that Node. kubelets take a configuration called a PodSpec as input and work to ensure that containers specified in the PodSpec are running and healthy. From the standpoint of the Kubernetes API server, Virtual Kubelets seem like normal kubelets, but with the crucial difference that they scheduler containers elsewhere, for example in a cloud serverless API, and not on the Node. below shows a Kubernetes cluster with a series of standard kubelets and one Virtual Kubelet: {{< svg src="img/diagram.svg" caption="Standard vs. Virtual Kubelets" >}}
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-azure_completion_fish.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: cilium-operator-azure completion fish | source To load completions for every new session, execute once: cilium-operator-azure completion fish > ~/.config/fish/completions/cilium-operator-azure.fish You will need to start a new shell for this setup to take effect. ``` cilium-operator-azure completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_dump.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Dump StateDB contents as JSON ``` cilium-dbg statedb dump [flags] ``` ``` -h, --help help for dump ``` ``` --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: iSulad (Runtime / Container Runtime)
File: events_design.md

| Author | zhangxiaoyu | | | - | | Date | 2022-09-17 | | Email | zhangxiaoyu58@huawei.com | The events module mainly records the relevant operation events of the container or image. Users can view events through the isula events client, or view events for a container in a certain period of time through parameters. E.g ```bash $ isula events --help Usage: isula events [OPTIONS] Get real time events from the server -n, --name Name of the container -S, --since Show all events created since this timestamp -U, --until Show all events created until this timestamp $ isula events 2022-05-10T17:20:34.661862100+08:00 container start 3277ec2e57cde72cbd20a1fea4bb4444e29df67f6fc27e60f8532b733b7ef400 (image=busybox, name=3277ec2e57cde72cbd20a1fea4bb4444e29df67f6fc27e60f8532b733b7ef400, pid=9007) ```` ````mermaid sequenceDiagram participant client participant containereventscb participant clients_checker participant gcontextlist participant monitored participant geventsbuffer client->>containereventscb: events request containereventscb->>geventsbuffer: traverse containereventscb->>client: write events to client containereventscb->>gcontextlist: add containereventscb->>containereventscb: sem wait [events]->>monitored: add event loop epoll monitored->>geventsbuffer: add monitored->>gcontextlist: traverse monitored->>client: write event to client end loop clientschecker->>gcontext_list: traverse alt cancelled or now > until clientschecker->>gcontext_list: delete clientschecker->>containerevents_cb: sem post end end containereventscb->>client: return ```` ````c // Send container event to monitor fifo int isuladmonitorsendcontainerevent(const char *name, runtimestatet state, int pid, int exit_code, const char args, const char extra_annations); // Send mirror event to monitor fifo int isuladmonitorsendimageevent(const char *name, imagestatet state); ```` ````c // Process the newly generated event, including stopped event processing, and forward the event to the client in the context list of the subscription list void eventshandler(struct monitordmsg *msg); // Add the client to the events subscription list: context list int addmonitorclient(char name, const types_timestamp_t since, const typestimestampt *until, const streamfuncwrapper *stream); // Write the eligible events in the events lists back to the client int eventssubscribe(const char *name, const typestimestampt *since, const typestimestamp_t *until, const streamfuncwrapper *stream); // copy event struct isuladeventsformat dup_event(const struct isulad_events_format event); // Create collector thread and monitored thread int eventsmoduleinit(char msg); ````