designs/centralized-configuration-db-with-netconf.md

@@ -133,13 +133,13 @@ This scenario features a single Kea instance with the Netconf ability. The Kea s
 - the configuration is stored in YANG/netconf
 - works well for a single instance, but quickly becomes hard to manage when deploying more servers
 
-[[Image(scenario-1b.jpeg)]]
+![scenario-1b](/uploads/49a48fbf0687f46c2dc4e34ee8755f08/scenario-1b.jpeg)
 
 ## 4.3: Single instance managed via Netconf with DB storage = 
 
 This scenario is a hybrid between 1a) and 1b) - provides Netconf and DB config storage. This scenario will typically be considered a stepping stone towards more advanced deployments.
 
-[[Image(scenario-1c.jpeg)]]
+![scenario-1c](/uploads/11039e58223c01af060f1555d752dd1d/scenario-1c.jpeg)
 
 ## 4.4: Multiple servers sharing DB configuration, REST managed  
 
@@ -148,7 +148,7 @@ In this configuration there are several Kea instances that share the same config
 - major scalability and resiliency benefit: several instances can share the same configuration. It provides resiliency against Kea server failure.
 - to maintain consistent configuration, there has to be a dedicated node that conducts the configuration updates. Initially it will be a dedicated Kea instance that will not be serving any traffic and its only purpose will be to manage configuration. It will be eventually replaced with kea-config.
 
-[[Image(scenario-2a.jpeg)]]
+![scenario-2a](/uploads/833c6436480dc18557c073a4304a03b1/scenario-2a.jpeg)
 
 ## 4.5: Multiple servers sharing DB configuration, Netconf managed  
 
@@ -157,7 +157,7 @@ This scenario is similar to 2a), but uses Netconf interface. The properties of t
 - one unified Netconf interface that deploys configuration to all Kea servers.
 - consistent configuration that is used by all servers.
 
-[[Image(scenario-2b.jpeg)]]
+![scenario-2b](/uploads/cf7c89a69418061abdf9870601559bfe/scenario-2b.jpeg)
 
 # 5. Deploying configuration (PUSH vs PULL model)