Demonstrate the "permapage" proposal

2024/projects/container_migration/README.md → blog/_posts/2024-08-25-container-migration.md

@@ -69,9 +69,9 @@ Our initial prototype was inspired by the load_balance exercise available in the
 The following diagram shows the initial network topology, with three hosts (`h1`, `h2`, `h3`) and three switches (`s1`, `s2`, `s3`), where `s1` is the load balancer:
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/simple_lb_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/simple_lb_dark.png">
-  <img alt="Shows a graph of nodes and switches to demostrate a simple load balancing solution." src="assets/simple_lb_dark.png" width="500">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/simple_lb_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/simple_lb_dark.png">
+  <img alt="Shows a graph of nodes and switches to demostrate a simple load balancing solution." src="../_assets/2024-container-migration/simple_lb_dark.png" width="500">
 </picture>
 
 
@@ -87,9 +87,9 @@ Next, we want to be able to change the hosts during runtime. We built a Python-b
 The controller also keeps track of the match-action table state, by a target IP -> index mapping. The index mapping corresponds to the value in the `ecmp_nhop` table. This makes it more efficient to look up the index of a specific IP in the table, without the need to fetch table state from the switch on each update request.
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/controller_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/controller_dark.png">
-  <img alt="Shows a flow chart of interaction between the user script, controller and BMv2 switch." src="assets/controller_dark.png" width="700">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/controller_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/controller_dark.png">
+  <img alt="Shows a flow chart of interaction between the user script, controller and BMv2 switch." src="../_assets/2024-container-migration/controller_dark.png" width="700">
 </picture>
 
 During this stage, we faced minor issues:
@@ -131,9 +131,9 @@ Using netns, veth pairs, and the iproute2 suite to set MAC and IP addresses of v
 The following diagram shows the created topology, including the virtual interfaces:
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/linux_network_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/linux_network_dark.png">
-  <img alt="Shows a graph with hosts and switches in the system, wired up via veth pairs." src="assets/linux_network_dark.png" width="600">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/linux_network_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/linux_network_dark.png">
+  <img alt="Shows a graph with hosts and switches in the system, wired up via veth pairs." src="../_assets/2024-container-migration/linux_network_dark.png" width="600">
 </picture>
 
 
@@ -152,9 +152,9 @@ Specifically, Podman uses the netavark backend for virtual networking. Each netw
 The following diagram shows the network topology of a single host and the connection of the network to a switch port:
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/container_interface_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/container_interface_dark.png">
-  <img alt="Shows how a container (h1) is connected to its network (h1-net) via a veth pair, and how that network is connected to the switch s1 via the network bridge h1-br." src="assets/container_interface_dark.png" width="400">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/container_interface_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/container_interface_dark.png">
+  <img alt="Shows how a container (h1) is connected to its network (h1-net) via a veth pair, and how that network is connected to the switch s1 via the network bridge h1-br." src="../_assets/2024-container-migration/container_interface_dark.png" width="400">
 </picture>
 
 We wrote a script to create a network and a pod for each container. A pod is a group of containers with a shared IP address. This is also the case within the Kubernetes network model. We built a container image using the TCP server executable from the previous steps. Analogously, we built a client image. 
@@ -180,9 +180,9 @@ For simplicity, the switch container runs on the host network. The container ima
 The following diagram shows the network topology, which consists of 4 Podman networks interfaced by bridges, connected to a single BMv2 switch running in a container, but on the host network:
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/container_network_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/container_network_dark.png">
-  <img alt="Shows how hosts h1-h4 are connected to their respective networks and how the container networks are connected to the switch s1." src="assets/container_network_dark.png" width="400">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/container_network_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/container_network_dark.png">
+  <img alt="Shows how hosts h1-h4 are connected to their respective networks and how the container networks are connected to the switch s1." src="../_assets/2024-container-migration/container_network_dark.png" width="400">
 </picture>
 
 ### Redis container migration
@@ -195,9 +195,9 @@ A client, also running on `h1`, that periodically fetches data from the BE and p
 A producer, also running on `h1`, periodically fetches a numerical ‘counter’ entry from the Redis DB, increments it by one, and updates the entry in the database.
 
 <picture>
-  <source media="(prefers-color-scheme: dark)" srcset="assets/redis_light.png">
-  <source media="(prefers-color-scheme: light)" srcset="assets/redis_dark.png">
-  <img alt="Shows the architecture of the Redis migration example, with BE, FE and producer running on h1, and Redis DB on h2, and an arrow showcasing how Redis DB should be migrated to h3." src="assets/redis_dark.png" width="500">
+  <source media="(prefers-color-scheme: dark)" srcset="../_assets/2024-container-migration/redis_light.png">
+  <source media="(prefers-color-scheme: light)" srcset="../_assets/2024-container-migration/redis_dark.png">
+  <img alt="Shows the architecture of the Redis migration example, with BE, FE and producer running on h1, and Redis DB on h2, and an arrow showcasing how Redis DB should be migrated to h3." src="../_assets/2024-container-migration/redis_dark.png" width="500">
 </picture>
 
 After deploying this system, we can observe the counter being periodically incremented by the producer. We perform a migration of the Redis DB from host 2 to host 3, the same way as in the previous examples, and observe little to no downtime from the client’s perspective. 

2024/projects/bmv2_pna/README.md → blog/_posts/2024-08-31-bmv2-pna.md

@@ -27,7 +27,7 @@
 As the P4 use cases on the NIC side increase, so does the need for a P4 simulator that supports [Portable NIC Architecture (PNA)](https://p4.org/p4-spec/docs/PNA-v0.7.html). Currently, the BMv2 simulator only supports the v1model and [Portable Switch Architecture (PSA)](https://p4.org/p4-spec/docs/PSA-v1.2.html) specifications. This project aims to integrate a minimal core subset of the PNA into the BMv2 and the P4C. The PNA Architecture Block Diagram is shown in below:
 
 <p align="center">
-  <img alt="PNA Block Diagram" src="assets/pna-block-diagram.png" width="700">
+  <img alt="PNA Block Diagram" src="../_assets/2024-bmv2-pna/pna-block-diagram.png" width="700">
 </p>
 
 
@@ -80,7 +80,7 @@ Resultant Binary: `p4c-bm2-pna`
 - To start the `pna_nic` target:
 
 <p align="center">
-  <img alt="pna_nic target demo" src="assets/pna_nic.gif" width="500">
+  <img alt="pna_nic target demo" src="../_assets/2024-bmv2-pna/pna_nic.gif" width="500">
 </p>
 
 - start the `pna_nic_CLI` and populate the `L2_fwd` table mentioned in the P4 program using the below example (or your own) data:
@@ -89,17 +89,17 @@ Resultant Binary: `p4c-bm2-pna`
   - `table_add L2_fwd L2_send_to_port 52:04:da:9b:15:59 => 2`
 
 <p align="center">
-  <img alt="PNA NIC CLI" src="assets/pna_nic_CLI.png" width="500">
+  <img alt="PNA NIC CLI" src="../_assets/2024-bmv2-pna/pna_nic_CLI.png" width="500">
 </p>
 
 - Send the Packets from one interface and listen on another interface. Example:
 
 <p align="center">
-  <img alt="Sending packet from one veth0" src="assets/scapy-send-packet.png" width="500">
+  <img alt="Sending packet from one veth0" src="../_assets/2024-bmv2-pna/scapy-send-packet.png" width="500">
 </p>
 
 <p align="center">
-  <img alt="Listening on veth3" src="assets/tcpdump_veth3.png" width="500">
+  <img alt="Listening on veth3" src="../_assets/2024-bmv2-pna/tcpdump_veth3.png" width="500">
 </p>
 
 ## Future Work

2024/projects/bmv2_pna/wiki.md → permapage/2024-bmv2-pna.md

@@ -1,7 +1,8 @@
-# BMv2 PNA
+# P4 GSoC 2024 Project: BMv2 PNA
 
-## Link to report
-- [BMv2 PNA Report](/2024/projects/bmv2_pna/README.md)
+## Major links
+- [Blog post (final report)](/blog/_posts/2024-08-31-bmv2-pna.md)
+- Final presentation (Slides, Recording)
 
 ## New PNA NIC target in BMv2
 Relevant PRs:
@@ -12,4 +13,4 @@ Relevant PRs:
 
 ## P4C backend for the new BMv2 PNA NIC target
 Relevant PR: 
-- https://github.com/p4lang/p4c/pull/4729
+- https://github.com/p4lang/p4c/pull/4729

2024/projects/container_migration/wiki.md → permapage/2024-container-migration.md

@@ -1,7 +1,8 @@
-# P4-Enabled Container Migration in Kubernetes
+# P4 GSoC 2024 Project: P4-Enabled Container Migration in Kubernetes
 
-## Link to report
-- [Container Migration Report](/2024/projects/container_migration/README.md)
+## Major links
+- [Blog post (final report)](/blog/_posts/2024-08-25-container-migration.md)
+- Final presentation (Slides, Recording)
 
 ## Controller
 Relevant PRs:

2024/projects/documentation/wiki.md → permapage/2024-documentation.md

@@ -1,7 +1,8 @@
-# P4 Compiler Documentation
+# P4 GSoC 2024 Project: P4 Compiler Documentation
 
-## Link to report
-- [ Compiler Documentation Report](/2024/projects/documentation/README.md)
+## Major links
+- [Blog post (final report)](/blog/_posts/2024-08-26-documentation.md)
+- Final presentation (Slides, Recording)
 
 ## Workflow Automation 
 Relevant PRs:
@@ -18,5 +19,3 @@ Relevant PR:
 - https://github.com/p4lang/p4c/pull/4708
 - https://github.com/p4lang/p4c/pull/4788
 - https://github.com/p4lang/p4c/pull/4849
-
-

2024/projects/formatter/wiki.md → permapage/2024-formatter.md

@@ -1,7 +1,8 @@
-# P4 Formatter
+# P4 GSoC 2024 Project: P4 Formatter
 
-## Link to report
-- [ P4 Formatter Report](/2024/projects/formatter/README.md)
+## Major links
+- [Blog post (final report)](/blog/_posts/2024-09-09-formatter.md)
+- Final presentation (Slides, Recording)
 
 ## New p4fmt backend
 Relevant PRs:
@@ -18,4 +19,4 @@ Relevant PR:
 
 ## Reference checker for p4fmt
 Relevant PR: 
-- https://github.com/p4lang/p4c/pull/4778
+- https://github.com/p4lang/p4c/pull/4778

permapage/README.md

@@ -0,0 +1,5 @@
+# P4 GSoC Project Permapages
+
+This directory hosts permapages (permenant pages) for all completed P4 GSoC projects.
+
+TODO: Explain more: the rationale, the file naming scheme, etc.