Age | Commit message (Collapse) | Author | Files | Lines |
|
A few things differ between baremetal and virtual nodes:
- provisioning method;
- network setup;
Since now we support completely dynamic network config based on PDF +
IDF, as well as dynamic provisioning of VMs on jumpserver (as virtual
cluster nodes), respectively MaaS-driven baremetal provisioning, let's
drop the 'baremetal-' prefix from cluster model names and prepare for
unified scenarios.
Note that some limitations still apply, e.g. virtual nodes are spawned
only on jumpserver (localhost) for now.
JIRA: FUEL-310
Change-Id: If20077ac37c6f15961468abc58db7e16f2c29260
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
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>
|
|
Change-Id: I1df0228cb44bf9122aaf93dd25fc16a0d26a5240
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Introduce a simple mechanism that simulates an 'if-arch-then' cond
for reclass models:
- add new <all-mcp-ocata-common> class hierarchy;
- at runtime (via <salt.sh>) make 'all-mcp-ocata-common.arch' point
to 'all-mcp-ocata-common.$(uname -i)' dynamically;
- inherit new 'arch' class in all cluster models;
- factor out current x86_64 default for "salt_control_xenial_image";
- add AArch64 default for param "salt_control_xenial_image";
Change-Id: I3b239b28d0fd1cc2ced8579e2e93b764eb71ffc3
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|