summaryrefslogtreecommitdiffstats
path: root/mcp/reclass/classes/cluster/virtual-mcp-pike-odl-noha
AgeCommit message (Collapse)AuthorFilesLines
2018-02-05[virtual] PDF-based network defs for cluster nodesAlexandru Avadanii2-11/+22
Decouple virtual cluster nodes (ctl, gtw etc.) from opnfv_fn_* vars in favor of parsing PDF/IDF. This is the first step towards unifying baremetal and virtual network definition templates, as well as allowing virtual nodes to run on a remote hypervisor (and eventually with a different arch). opnfv_fn_* vars will still be used for infra VMs spawned on FN (cfg01 and optionally mas01). Adopt new 'net_map.j2' from Pharos submodule for new templates (virt), as well as old ones (baremetal). JIRA: FUEL-322 Change-Id: I150c2416566bbe42ea11cd00f12a8a7bf96776c2 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-02-05[virtual] Parameterize cluster model based on PDFAlexandru Avadanii4-6/+5
- 10.1.0.0/24 (internal): * 10.1.0.101 -> opnfv_openstack_compute_node01_tenant_address * 10.1.0.124 -> opnfv_openstack_gateway_node01_tenant_address - 172.16.10.0/24 (mgmt): * 172.16.10.11 -> opnfv_openstack_control_node01_address * 172.16.10.100 -> opnfv_infra_config_address * 172.16.10.101 -> opnfv_openstack_compute_node01_control_address * 172.16.10.111 -> opnfv_opendaylight_server_node01_single_address * 172.16.10.124 -> opnfv_openstack_gateway_node01_address - 10.16.0.0/24 (public): * 10.16.0.11 -> opnfv_openstack_control_node01_external_address * 10.16.0.101 -> opnfv_openstack_compute_node01_external_address * 10.16.0.124 -> opnfv_openstack_gateway_node01_external_address To re-use DPDK config baremetal template, move: - cluster.baremetal-mcp-pike-ovs-dpdk-ha.infra.config_pdf + cluster.all-mcp-arch-common.infra.config_dpdk_pdf Drop unused 'ceilometer_graphite_publisher_host' (172.16.10.107). JIRA: FUEL-322 Change-Id: I3aef3415bd696a7ae5b566af12af4733a50c2135 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-02-05[virtual] Change IP addrs to align with baremetalAlexandru Avadanii2-3/+3
To be able to re-use pod_config.yaml parameters generated based on PDF for both baremetal and virtual scenarios without forking it, we first need to align the IP addresses used in virtual deployments. Currently hard set values will be parameterized in an ulterior change. - 10.1.0.0/24 (internal): * 105 -> 101 (cmp01); 106 -> 102 (cmp02); * 110 -> 124 (gtw01); - 172.16.10.0/24 (mgmt): * 101 -> 11 (ctl01); * 105 -> 101 (cmp01); 106 -> 102 (cmp02); * 110 -> 124 (gtw01); - 10.16.0.0/24 (public): * 101 -> 11 (ctl01); * 105 -> 101 (cmp01); 106 -> 102 (cmp02); * 110 -> 124 (gtw01); JIRA: FUEL-322 Change-Id: I5d5def4e92c3462f1a34f73dde65ef7a262a5d62 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-02-02Revert "[FN VMs] remove graphics"Alexandru Avadanii1-1/+1
RHEL family virtualization tools reserve 02:00 PCI slot for VGA, even if 'nographics' is specified when creating the VM (in case the user wants to later hook a video card, which usually *requires* PCI slot2). Debian systems do not follow this rule (tested with libvirt 1.x, 2.x, 3.x), hence 1st NIC lands on PCI slot 2 (and get eth name 'ens2'). To align the behavior across all possible jumpserver distros, bring back the virtio video. This reverts commit 738f6c3b68d1179de1ff790f9e72c25f10874da4. Change-Id: Ifd855c12e04aec1ff0ab047b13f8081365741889 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-01-29[FN VMs] remove graphicsAlexandru Avadanii1-1/+1
Since VCP VMs (created via salt formula) do not have a video controller defined in their domain XMLs, network devices end on different PCI slots and hence have different names assigned (ens2+ vs foundation node VMs, which start with ens3). To align network interface names for VMs on jumpserver vs kvm nodes, and reduce confusion, remove the video controller from FN VMs. This allows some cleanup: - drop extra AArch64 args from virt-install; - unify 'opnfv_vcp_vm_*' and 'opnfv_fn_vm_*' variables; Change-Id: I0d108b00914b3eaaa03b67c652174f8ed4573118 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2017-12-22[ovn] Weed out gateway node from reclass storageMichael Polenchuk1-0/+5
Change-Id: I87efd87f8ac05ed9b3189e5dba80748e07c86d5d Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
2017-12-21Bring in ovn based scenarioMichael Polenchuk1-0/+1
OVN based scenario doesn't require conventional gateway node since connectivity to external networks and routing occurs on compute nodes. Change-Id: I81e0d497170d5ffb067adf13b0e46290525f26a6 Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
2017-12-04virtual: Add infra/init.yml for each scenarioAlexandru Avadanii2-3/+15
Align our reclass model for virtual PODs with baremetal, by adding an infra init file for each scenario, setting up cluster_name via scenario infra init instead of scenario init. While at it, reduce redundancy by defining cluster_domain based on cluster_name via common infra init. JIRA: FUEL-310 Change-Id: I5e89c883853fa66cb1c1fc69ce5766ee136ac477 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2017-12-04Rename reclass models to add "-ha" or "-noha"Alexandru Avadanii7-0/+244
Parse all reclass j2 templates, not only common + current scenario (useful when adding new scenarios later). JIRA: FUEL-310 Change-Id: I8e87af702f83c42cb8f766bf6f121449aa5f2c26 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>