Add internalapi routes for scenario A adoption

Doing data-plane adoption while testing scenario A (different
subnets between wallaby and next-gen) will result in connectivity
problem since pods will try to reach old CP using default route
(since both CP are on different subnets) and won't be able to reach it.

Adding this route in internalapi to support data-plane
adoption scenario A gates.

Currently only one route can be added, if needed logic can be improved
to include more than one route.

Ref: OSPRH-5602

Author: averdagu

Makefile

@@ -51,10 +51,9 @@ NETWORK_STORAGE_ADDRESS_PREFIX 	?= 172.18.0
 NETWORK_TENANT_ADDRESS_PREFIX 	?= 172.19.0
 NETWORK_STORAGEMGMT_ADDRESS_PREFIX 	?= 172.20.0
 NETWORK_DESIGNATE_ADDRESS_PREFIX 	?= 172.28.0
+# Additional routes that will be forwarded to nncp and net-attach-def
 INTERNALAPI_HOST_ROUTES ?=
-STORAGE_HOST_ROUTES ?=
 TENANT_HOST_ROUTES ?=
-STORAGEMGMT_HOST_ROUTES ?=
 
 # network isolation
 NETWORK_ISOLATION   ?= true
@@ -2395,6 +2394,8 @@ netattach: export DESIGNATE_PREFIX=${NETWORK_DESIGNATE_ADDRESS_PREFIX}
 netattach: export VLAN_START=${NETWORK_VLAN_START}
 netattach: export VLAN_STEP=${NETWORK_VLAN_STEP}
 netattach: export CTLPLANE_IP_ADDRESS_PREFIX=${NNCP_CTLPLANE_IP_ADDRESS_PREFIX}
+netattach: export NETATT_INTERNALAPI_HOST_ROUTES=${INTERNALAPI_HOST_ROUTES}
+netattach: export NETATT_TENANT_HOST_ROUTES=${TENANT_HOST_ROUTES}
 netattach: namespace ## Creates network-attachment-definitions for the networks the workers are attached via nncp
 	$(eval $(call vars,$@,netattach))
 	bash scripts/gen-netatt.sh

scripts/gen-netatt.sh

@@ -120,8 +120,19 @@ if [ -n "$IPV4_ENABLED" ]; then
     cat >> ${DEPLOY_DIR}/internalapi.yaml <<EOF_CAT
         "range": "${INTERNALAPI_PREFIX}.0/24",
         "range_start": "${INTERNALAPI_PREFIX}.30",
-        "range_end": "${INTERNALAPI_PREFIX}.70"
+        "range_end": "${INTERNALAPI_PREFIX}.70",
 EOF_CAT
+    # In the data-plane adoption scenario A (where different IP subnet ranges
+    # between next-gen and wallaby are used) the net-attach-def needs additional routes.
+    if [ -n "$NETATT_INTERNALAPI_HOST_ROUTES" ]; then
+    cat >> ${DEPLOY_DIR}/internalapi.yaml <<EOF_CAT
+        "routes": [
+          {
+             "dst": "${NETATT_INTERNALAPI_HOST_ROUTES}"
+          }
+        ]
+EOF_CAT
+    fi
 elif [ -n "$IPV6_ENABLED" ]; then
     cat >> ${DEPLOY_DIR}/internalapi.yaml <<EOF_CAT
         "range": "fd00:bbbb::/64",
@@ -188,8 +199,19 @@ if [ -n "$IPV4_ENABLED" ]; then
     cat >> ${DEPLOY_DIR}/tenant.yaml <<EOF_CAT
         "range": "${TENANT_PREFIX}.0/24",
         "range_start": "${TENANT_PREFIX}.30",
-        "range_end": "${TENANT_PREFIX}.70"
+        "range_end": "${TENANT_PREFIX}.70",
 EOF_CAT
+    # In the data-plane adoption scenario A (where different IP subnet ranges
+    # between next-gen and wallaby are used) the net-attach-def needs additional routes.
+    if [ -n "$NETATT_TENANT_HOST_ROUTES" ]; then
+    cat >> ${DEPLOY_DIR}/tenant.yaml <<EOF_CAT
+        "routes": [
+          {
+             "dst": "${NETATT_TENANT_HOST_ROUTES}"
+          }
+        ]
+EOF_CAT
+    fi
 elif [ -n "$IPV6_ENABLED" ]; then
     cat >> ${DEPLOY_DIR}/tenant.yaml <<EOF_CAT
         "range": "fd00:dddd::/64",