Use hyphen in image path

Author: jotak

content/posts/2022-12-12-3d_topology.md

@@ -15,13 +15,13 @@ Red Hat OpenShift Container Platform (OCP) has had monitoring capabilities from
 Network Observability brings user interfaces in OpenShift web console administration to filter and visualize your cluster network flows as:
 
 - Graph (top 5 flow rates stacked with total example)
-![Graph example]({page.image('3d_topology/graph.png')})
+![Graph example]({page.image('3d-topology/graph.png')})
 
 - Table (showing sources and destinations sorted by time)
-![Table example]({page.image('3d_topology/table.png')})
+![Table example]({page.image('3d-topology/table.png')})
 
 - Topology (using directed graph layout)
-![Topology example]({page.image('3d_topology/topology.png')})
+![Topology example]({page.image('3d-topology/topology.png')})
 
 If you are interested in Network Observability for your cluster, check [official documentation for installation](https://docs.openshift.com/container-platform/4.12/networking/network_observability/installing-operators.html).
 
@@ -47,23 +47,23 @@ To arrange components by their ownership
 
 What happens in your network when you deploy a [httpd sample application](https://github.com/sclorg/httpd-ex) ?
 
-![Sample app deployment]({page.image('3d_topology/sample-app-deployment.png')})
+![Sample app deployment]({page.image('3d-topology/sample-app-deployment.png')})
 
 You can see that the final deployed pod in blue involved another pod called `httpd-sample-1-build` that pulled the image from `openshift-image-registry` (1), did some DNS resolution for provided image URL (2), pulled it from the resolved external IP (3) before creating our pod through kubernetes services (4).
 
 Finally, some flows are showing between our pod and `openshift-ingress` after opening the hosted page (5).
 
 After moving my time window or waiting a bit, the `httpd-sample-1-build` pod disappears as it's status is now `Completed`.
 
-![Sample app deployed]({page.image('3d_topology/sample-app-deployed.png')})
+![Sample app deployed]({page.image('3d-topology/sample-app-deployed.png')})
 
 ## Complex representations
 
 Sometimes we need to see more than a single application to troubleshoot network issues or to highlight bandwidth usage at cluster level.
 
 2D network topology may start to show its limits as you need to switch between multiple options and never get an overview into a single render.
 
-![Complex 2D topology]({page.image('3d_topology/huge-topology.png')})
+![Complex 2D topology]({page.image('3d-topology/huge-topology.png')})
 
 We can do the following observation from this:
 - it is almost impossible to have a good overview of your entire network
@@ -83,7 +83,7 @@ Then go to Topology tab -> Show advanced options -> Display options
 From there set Scope option as "Resource" and Layout as "3D".
 ```
 
-![3D topology building]({page.image('3d_topology/3d-building.png')})
+![3D topology building]({page.image('3d-topology/3d-building.png')})
 
 - **Building** drawn by dotted lines represent your `Cluster`
 Every internal communication is inside these lines
@@ -100,11 +100,11 @@ They will repeat on each node + namespace combination if the load is distributed
 - Finally, **rooms contents** depict `Pods`
 These are represented in the proper node + namespace + owner combination according to its kindred
 
-![3D topology ownership]({page.image('3d_topology/3d-ownership.png')})
+![3D topology ownership]({page.image('3d-topology/3d-ownership.png')})
 This representation emphasizes the entire ownership chain from `Node` to `Pod` passing by `Namespace`.
 It also pin up how your load is balanced between nodes.
 
-![3D topology connections]({page.image('3d_topology/3d-connection.png')})
+![3D topology connections]({page.image('3d-topology/3d-connection.png')})
 
 The important part of your network traffic is highlighted since lines are less likely to cross than in the 2D view and their size and color differ according to bytes rate. 
 A thin black line will represent a smaller amount than a heavy red line.
@@ -120,11 +120,11 @@ Feel free to contribute by commenting this post, opening issues in [netobserv co
 
 Tell us more about your expectations, the way you currently solve issues and what could help your daily experience.
 
-![Gallery 1]({page.image('3d_topology/gallery-1.png')})
-![Gallery 2]({page.image('3d_topology/gallery-2.png')})
-![Gallery 3]({page.image('3d_topology/gallery-3.png')})
-![Gallery 4]({page.image('3d_topology/gallery-4.png')})
-![Gallery 5]({page.image('3d_topology/gallery-5.png')})
-![Gallery 6]({page.image('3d_topology/gallery-6.png')})
-![Gallery 7]({page.image('3d_topology/gallery-7.png')})
-![Gallery 8]({page.image('3d_topology/gallery-8.png')})
+![Gallery 1]({page.image('3d-topology/gallery-1.png')})
+![Gallery 2]({page.image('3d-topology/gallery-2.png')})
+![Gallery 3]({page.image('3d-topology/gallery-3.png')})
+![Gallery 4]({page.image('3d-topology/gallery-4.png')})
+![Gallery 5]({page.image('3d-topology/gallery-5.png')})
+![Gallery 6]({page.image('3d-topology/gallery-6.png')})
+![Gallery 7]({page.image('3d-topology/gallery-7.png')})
+![Gallery 8]({page.image('3d-topology/gallery-8.png')})

content/posts/2023-09-12-dns_tracking.md

@@ -9,7 +9,7 @@ author: jpinsonneau
 
 # Network Observability Per Flow DNS tracking
 
-![logo]({page.image('dns_tracking/dns_tracking_logo.png')})
+![logo]({page.image('dns-tracking/dns-tracking-logo.png')})
 
 By: Julien Pinsonneau, Mehul Modi and Mohamed S. Mahmoud
 
@@ -95,46 +95,46 @@ Open your OCP Console and move to `Administrator view` -> `Observe` ->
 Three new filters, `DNS Id`, `DNS Latency` and `DNS Response Code` will be
 available in the common section:
 
-![dns filters]({page.image('dns_tracking/dns_filters.png')})
+![dns filters]({page.image('dns-tracking/dns-filters.png')})
 
 The first one will allow you to filter on a specific DNS Id (found using `dig`
 command or in flow table details) to correlate with your query.
 
-![dns id]({page.image('dns_tracking/dns_id.png')})
+![dns id]({page.image('dns-tracking/dns-id.png')})
 
 The second one helps to identify potential performance issues by looking at DNS
 resolution latency.
 
-![dns latency more than]({page.image('dns_tracking/dns_latency_more_than.png')})
+![dns latency more than]({page.image('dns-tracking/dns-latency-more-than.png')})
 
 The third filter surfaces DNS response codes, which can help detect errors or
 unauthorized resolutions.
 
-![dns rcode]({page.image('dns_tracking/dns_response_code.png')})
+![dns rcode]({page.image('dns-tracking/dns-response-code.png')})
 
 ### Overview
 
 New graphs are introduced in the `advanced options` -> `Manage panels` popup:
 
-![advanced options 1]({page.image('dns_tracking/advanced_options1.png')})
+![advanced options 1]({page.image('dns-tracking/advanced-options1.png')})
 
 - Top X average DNS latencies
 - Top X DNS response code
 - Top X DNS response code stacked with total
 
-![dns graphs 1]({page.image('dns_tracking/dns_graphs1.png')})
-![dns graphs 2]({page.image('dns_tracking/dns_graphs2.png')})
+![dns graphs 1]({page.image('dns-tracking/dns-graphs1.png')})
+![dns graphs 2]({page.image('dns-tracking/dns-graphs2.png')})
 
 ### Traffic flows
 
 The table view adds the new DNS columns `Id`, `Latency` and `Response code`,
 which are available from the `advanced options` -> `manage columns` popup.
 
-![advanced options 2]({page.image('dns_tracking/advanced_options2.png')})
+![advanced options 2]({page.image('dns-tracking/advanced-options2.png')})
 
 The DNS flows display this information in both the table and the side panel:
 
-![dns table]({page.image('dns_tracking/dns_table.png')})
+![dns table]({page.image('dns-tracking/dns-table.png')})
 
 ## Future support
 

content/posts/2023-09-12-packet_drops.md

@@ -8,7 +8,7 @@ author: Amoghrd
 
 # Network Observability Real-Time Per Flow Packets Drop
 
-![logo]({page.image('packet_drops/packets_drop_logo.png')})
+![logo]({page.image('packet-drops/packets-drop-logo.png')})
 
 By: Amogh RD, Julien Pinsonneau and Mohamed S. Mahmoud
 
@@ -82,7 +82,7 @@ Open your OCP Console and move to
 
 Now, a new query option is available to filter flows by their drop status:
 
-![drop filter query option]({page.image('packet_drops/drop_filter_query_option.png')})
+![drop filter query option]({page.image('packet-drops/drop-filter-query-option.png')})
 
 - `Fully dropped` shows the flows that have 100% dropped packets
 - `Containing drops` shows the flows having at least one packet dropped
@@ -92,18 +92,18 @@ Now, a new query option is available to filter flows by their drop status:
 Two new filters, `Packet drop TCP state` and `Packet drop latest cause` are available
 in the common section:
 
-![drop state & cause filters]({page.image('packet_drops/drop_state_cause_filters.png')})
+![drop state & cause filters]({page.image('packet-drops/drop-state-cause-filters.png')})
 
 The first one will allow you to set the TCP state filter:
 
-![state filter]({page.image('packet_drops/state_filter.png')})
+![state filter]({page.image('packet-drops/state-filter.png')})
 
 - A _LINUX_TCP_STATES_H number like 1, 2, 3
 - A _LINUX_TCP_STATES_H TCP name like `ESTABLISHED`, `SYN_SENT`, `SYN_RECV`
 
 The second one will let you pick causes to filter on:
 
-![cause filter]({page.image('packet_drops/cause_filter.png')})
+![cause filter]({page.image('packet-drops/cause-filter.png')})
 
 - A _LINUX_DROPREASON_CORE_H number like 2, 3, 4
 - A _LINUX_DROPREASON_CORE_H SKB_DROP_REASON name like
@@ -113,7 +113,7 @@ The second one will let you pick causes to filter on:
 
 New graphs are introduced in the `advanced options` -> `manage panels` popup:
 
-![advanced options]({page.image('packet_drops/advanced_options.png')})
+![advanced options]({page.image('packet-drops/advanced-options.png')})
 
 - Top X flow dropped rates stacked
 - Total dropped rate
@@ -123,28 +123,28 @@ New graphs are introduced in the `advanced options` -> `manage panels` popup:
 
 Select the desired graphs to render them in the overview panel:
 
-![drop graphs 1]({page.image('packet_drops/drop_graphs1.png')})
-![drop graphs 2]({page.image('packet_drops/drop_graphs2.png')})
-![drop graphs 3]({page.image('packet_drops/drop_graphs3.png')})
+![drop graphs 1]({page.image('packet-drops/drop-graphs1.png')})
+![drop graphs 2]({page.image('packet-drops/drop-graphs2.png')})
+![drop graphs 3]({page.image('packet-drops/drop-graphs3.png')})
 
 Note that you can compare the top drops against total dropped or total traffic
 in the last graph using the kebab menu
-![drop graph option]({page.image('packet_drops/drop_graph_options.png')})
+![drop graph option]({page.image('packet-drops/drop-graph-options.png')})
 
 ### Traffic flows
 
 The table view shows the number of `bytes` and `packets` sent in green and the
 related numbers dropped in red. Additionally, you can get details about the
 drop in the side panel that brings you to the proper documentation.
 
-![drop table]({page.image('packet_drops/drop_table.png')})
+![drop table]({page.image('packet-drops/drop-table.png')})
 
 ### Topology
 
 Last but not least, the topology view displays edges containing drops in red.
 That's useful especially when digging on a specific drop reason between two resources.
 
-![drop topology]({page.image('packet_drops/drop_topology.png')})
+![drop topology]({page.image('packet-drops/drop-topology.png')})
 
 ## Potential use-case scenarios
 
@@ -158,20 +158,20 @@ while : ; do curl <another nodeIP>:<unknown port>; sleep 5; done
 
 The drops can be observed on the console as seen below:
 
-![NO_SOCKET drop table]({page.image('packet_drops/NO_SOCKET_table.png')})
+![NO_SOCKET drop table]({page.image('packet-drops/NO-SOCKET-table.png')})
 
-![NO_SOCKET drop overview]({page.image('packet_drops/NO_SOCKET_overview.png')})
+![NO_SOCKET drop overview]({page.image('packet-drops/NO-SOCKET-overview.png')})
 
 - `OVS_DROP_LAST_ACTION` drop reason: OVS packet drops can be observed on
  RHEL9.2 and above. It can be emulated by running the iperf command with
  network-policy set to drop on a particular port.
  These drops can be observed on the console as seen below:
 
-![OVS drop table]({page.image('packet_drops/OVS_table.png')})
+![OVS drop table]({page.image('packet-drops/OVS-table.png')})
 
-![OVS drop topology]({page.image('packet_drops/OVS_topology.png')})
+![OVS drop topology]({page.image('packet-drops/OVS-topology.png')})
 
-![OVS drop overview]({page.image('packet_drops/OVS_overview.png')})
+![OVS drop overview]({page.image('packet-drops/OVS-overview.png')})
 
 ## Resource impact of using PacketDrop
 

content/posts/2023-10-02-secondary_interface.md

@@ -17,7 +17,7 @@ troubleshooting network issues in a Kubernetes cluster.
 ## Overview of how you can achieve network observability for secondary interface
 
 <p align="center">
-  <img src="{page.image('secondary_interface/sriov.png')}" alt="logo" width="75%"/>
+  <img src="{page.image('secondary-interface/sriov.png')}" alt="logo" width="75%"/>
 </p>
 
 1. **Multus CNI Plugin**: Multus is a CNI (Container Network Interface) plugin
@@ -151,7 +151,7 @@ By opening the console plugin and looking in the Traffic Flows table and filter
 `Network interface name == net1`  like the following for TCP flow 
 packets as an example
 
-<img src="{page.image('secondary_interface/sriov_flow.png')}" alt="logo" width="300%"/>
+<img src="{page.image('secondary-interface/sriov-flow.png')}" alt="logo" width="300%"/>
 
 ## Feedback