Bring in FDIO (VPP+DPDK) scenario

- cmp, gtw: bump RAM allocation to accomodate hugepages/VPP;
  for now we overcommit, gtw01 resources can probably be lowered;
- submodule: add salt-formula-neutron so we can locally patch it;
- repo:
  * FD.IO repos for VPP packages;
  * networking-vpp PPA for python-networking-vpp Neutron driver;
- use vpp-router for L3, disable neutron-l3-agent;
- baremetal_init: apply repo config before network (otherwise UCA
  repo is missing when trying to install DPDK on baremetal nodes);
- arm64: iommu.passthrough=1 is required on ThunderX for VPP on
  newer kernels;

Design quirks:
- vpp service runs as 'neutron' user, which does not exist at the
  time VPP is installed and initially started, hence the need to
  restart it before starting the vpp-agent service;
- gtw01 node has DPDK, yet to configure it via IDF we use the
  compute-specific OVS-targeted parameters like
  `compute_ovs_dpdk_socket_mem`, which is a bit misleading;
- vpp-agent requires ml2_conf.ini on ALL compute AND network nodes
  to parse per-node physnet-to-real interface names;
- vpp process is bound to core '1' (not parameterized via IDF);

Change-Id: I659f7dbebcab7b154e7b1fb829cd7159b4372ec8
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/mcp/reclass/classes/cluster/.gitignore b/mcp/reclass/classes/cluster/.gitignore
index 0179ad987..37832a89c 100644
--- a/mcp/reclass/classes/cluster/.gitignore
+++ b/mcp/reclass/classes/cluster/.gitignore
@@ -17,8 +17,9 @@ mcp-*-ha/infra/init_vcp.yml
 mcp-odl-ha/infra/maas.yml
 mcp-odl-*/opendaylight/control.yml
 mcp-odl-ha/openstack/init.yml
-mcp-odl-noha/infra/config.yml
+mcp-odl-*/infra/config.yml
 mcp-*-noha/openstack/compute.yml
 mcp-common-noha/infra/init.yml
 mcp-common-noha/init_options.yml
 mcp-*-noha/openstack/gateway.yml
+mcp-fdio-noha/infra/config.yml