aboutsummaryrefslogtreecommitdiffstats
path: root/mcp/config/scenario/os-nosdn-ovs-ha.yaml
AgeCommit message (Collapse)AuthorFilesLines
2019-04-08[virtual] Parameterize scenarios based on PDF/IDFAlexandru Avadanii1-0/+2
NOTE: only os-nosdn-nofeature-noha is parameterized for now. - move config drive & disk creation from prepare_vms to create_vms; - make default disk size(s) configurable based on scenario defaults and vPDF; * compute nodes require 2 disks to be defined in vPDF, since the pillar reclass model assumes /dev/vdb is reserved for cinder; * if multiple disks are defined in vPDF, they are created and attached accordinly (only ctl01 and cmp nodes are parameterized in this change; only for the os-nosdn-nofeature-noha scenario); - vCPU specifications are deduced based on vPDF (sockets, cores); * threads/core is hard set to 2 since vPDF does not have a key for it; * NUMA resources are distributed evenly based on the number of sockets configured in PDF; * no less than the mininum requirement for a scenario is allocated (e.g. if PDF specifies 2 cores, but the scenario requires at least 4 cores, the larger value will be used); - RAM is deduced based on PDF (but no less than the mininum req is allocated, e.g. if PDF specifies 2GB RAM for computes, but the scenario requires at least 8GB, the larger value will be used); Change-Id: I97188aa2a1006865b8429eb6483e10c76795f7d2 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2019-04-02[dpdk] Enable per port memory modelMichael Polenchuk1-1/+0
The per port memory model provides a more transparent memory usage model and avoids pool exhaustion due to competing memory requirements for interfaces. (http://docs.openvswitch.org/en/latest/topics/dpdk/memory/) Change-Id: I5add0f49cdcdf2fc3d24affee10a275abe3ca46a Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
2019-01-27[ovs] Start ovs services before networkingAlexandru Avadanii1-2/+2
Fix broken systemd service unit dependecies: - OVS should start before networking service; - OVS ports & bridges should not be automatically ifup-ed by networking service to avoid races, so drop 'auto' for both (OVS ports are automatically handled when part of an OVS bridge); - explicitly ifup OVS bridges as part of networking service, but after all Linux interfaces have been handled; - use 'allow-ovs br-prv' to let OVS handle br-prv and avoid another race condition; While at it, fix some other related issues: - make OVS service start after DPDK service (if present); - bump OVS-DPDK compute VMs RAM since since switching from MTU 1500 to jumbo frames for virtual PODs a while ago failed to do so [1]; - avoid creating conflicting reclass linux.network.interfaces entries for OVS ports by using their name (drop 'ovs_port_' prefix): * for untagged networks they will override existing common defs; * for tagged networks, they will create separate entries; - DPDK scenarios: make gtw01 br-prv members OVS ports to avoid race conditions after node reboot by letting OVS handle them; [1] https://developers.redhat.com/blog/2018/03/16/\ ovs-dpdk-hugepage-memory/ Change-Id: I0266ba67f3849b6f7e331a758146b331730bae55 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-09-02[scenario] Factor out common nodes, statesAlexandru Avadanii1-0/+43
Make the bulk of scenario files static again by shifting out all common virtual nodes (mas01) and states (virtual_init, maas etc.) to default.yaml(.j2). This allows us to parse scenario-specific data during first j2 expansion, preparing for the new Pharos installer adapter that relies on `conf.virtual.nodes.control` length to construct the proper list of MaaS node definitions (kvm{01,02,03} vs {ctl01,gtw01}). Change-Id: I666ab5bd6bb2a42f98646af51950f6b9fffa0e8b Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-03-07[novcp] Add deploy argument `-N` (experimental)Alexandru Avadanii1-27/+0
Instead of duplicating scenarios for NOVCP, allow it to be specified using a new deploy argument, `-N`. Things are getting convoluted, so instead of creating dedicated '*_pdf.yml.j2' files for each group of similar features, apply the templating in-place and rename all affected files to ".yml.j2". This breaks .gitignore assumption of hiding only "*_pdf.yml" files, so extend (manually) the <mcp/reclass/classes/cluster/.gitignore> with `git ls-files --exclude-standard -o` after an expansion. - ha: move nfv.cpu_pinning to j2, conditioned by 'baremetal'; - ha: add cmp00* vnode definitions (hugepages need more RAM); - labs/local: enable hugepage params for non-dpdk noha; - salt.sh: add route_wrapper to all non-infra VMs; This change extends novcp support to all HA scenarios. Change-Id: I7a80415ac33367ab227ececb4ffb1bc026546d36 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-02-25[ovs/dpdk] Add opnfv.route_wrapper slsAlexandru Avadanii1-2/+1
- fix `route-br-ex` if-up.d script failing when route already exists by adding a wrapper around distro's '/sbin/route' binary in '/usr/local/sbin/route', exploiting default order in Ubuntu PATH; - fix 'br-prv' duplicate entry in 'interfaces.d/ifcfg-br-prv' and 'interfaces' caused by upstream bug [1]; - add barrier waiting for all baremetal nodes online before attempting reboot, trying to catch rare failures which are undetectable in logs as both a succesful reboot and a disconneted minion report 'n/c'; With the above in place, networking service should no longer fail to start on cmp nodes w/ DPDK. [1] https://github.com/saltstack/salt/issues/40262 Change-Id: I6d4895376ce323c14c997e6c9af2ea3eeeee0184 Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
2018-02-06[hybrid] Merge config/scenario/{baremetal,virtual}Alexandru Avadanii1-0/+28
Instead of classifying scenarios by underlying machine type, switch to HA/NOHA differentiantion only. This allows us to add support for hybrid scenarios (with some virtual and some baremetal nodes in the same cluster). To facilitate this, we will template the scenario files, which is a small step towards SDF (Scenario Descriptor File) definition and adoption later. JIRA: FUEL-338 Change-Id: If5787991869a3105d82c27ffa0a86ac79b4b08ba Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>