Age | Commit message (Collapse) | Author | Files | Lines |
|
Inheriting classes in the wrong order led to params being silently
overriden by defaults in the system reclass classes, leaving
some mismatched values between the controller nova config and the
compute conunterpart (e.g. metadata_password had different values).
Always inherit the common class first, so scenario-specific config
is applied on top.
NOTE: {dhcp,single}_nic are not used for mas|kvm|cmp nodes, but they
are referenced in inherited classes, so keep them for now.
Change-Id: I6cb90d5c832ffc8ab731bd9e3cd38ede858dba5c
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
(cherry picked from commit 92530f89c061b0070766e431f839feb368e2e4ac)
|
|
While at it, compact 'set' into bash shebang where possible and
add `make patches-copyright` target to simplify adding patch
license headers.
Change-Id: I0c841de72e5709e5eef915a52c5ec4a7fc0f7c37
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit 644e5fdfa2f49b988a5150e2a4eefc12daecd845)
|
|
While at it, add .yamllint file (copied from releng repo).
Change-Id: I39630c0043fe2fd601510969c401e6cc9efbf69a
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit a75af3d4c30af050dd15c0f875142f6328874fe4)
|
|
-Fix interface order for reclass config node
-Interface types regruped on 3 sets for each cpu arch
-Foundation VM interface names
-VCP VM interface names
-Baremetal node interface names
Change-Id: I1ae522d775ee538b35b0f043914c80c3993232fc
Signed-off-by: Guillermo Herrero <guillermo.herrero@enea.com>
(cherry picked from commit c8d0c5b687f5eec9db62171fdf53053f5ffeef28)
|
|
Salt's virtualization model for virt:nic:default does not use real
interface names that are present on the node, but instead it defaults
to using "ethX" notation, that name being only a convention inside
Salt internals.
Moreover, the 'salt.control.virt' reclass class (located in
/srv/salt/reclass/classes/system/salt/control) already provides a
defalt maping between "eth{0,1}" and "br{0,1}". Using anything
different than "eth{0,1}" will lead to 2 extra (broken) mappings.
Reverting the changes in "virt:nic" reclass fixes both the python
exception recently introduced, as well as the broken defaults.
Change-Id: I5c90e3d2bc181c1ad3d87af64440439e6a41fb28
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit db2144a7f6ed8586bbab39fdb5ea15b171388e85)
|
|
Change-Id: I94d40529261f7753ec47a0c6a8c67ecc0fb15951
Signed-off-by: Guillermo Herrero <guillermo.herrero@enea.com>
(cherry picked from commit 5ab45d25c8fd3e5528c411e09b105699c745457f)
|
|
- minor refactor of runtime templates parsing to allow var expansion;
- parse <pod_config.yml> into shell vars, match dynamically networks
from PDF to IP addresses on bridges of current jumphost;
- keep old '-B' parameter in <ci/deploy.sh>, use it for providing
fallback values in case there's no bridge name specified via IDF
and no IP on the jumphost for one or more of the PDF networks;
- re-enable dry-run to ease testing of the above;
- add sample 'idf-pod1.yaml' to <mcp/config/labs/local>;
The new behavior will try to determine the jump host bridge names:
1. Based on IDF mapping, if available
2. Based on PDF network matching with IP addrs on jumphost;
3. Fallback to values passed via '-B';
4. Fallback to default values hardcoded in the deploy script;
Later, we will drop MaaS network env vars in favor of PDF vars,
once the PDF template is generating them.
Change-Id: If9cd65d310c02965b2e2bfa06a0d7e0f97f1dd48
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit 8ec927497b7ee0fd3b7346e957878173b080ef6a)
|
|
Change-Id: If7cb8473f5c290d1d5f22fce5567f7b8da24fd9f
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
(cherry picked from commit 0c00f813d709fd1b65e5dd52abcf16fd81b3d0e1)
|
|
Upstream change [1] made the inclusion of service.maas.cluster.single
mandatory by using some default reclass definitions which we don't
override explicitly.
[1] https://github.com/salt-formulas/salt-formula-maas/commit/
ce118a238bae4bcf19d2f10bca591a40405f7c3c
Change-Id: I5746b6906b341a7257e0cd2b4b0bed8ea25840f4
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit 4b2dfa552656def5f56a48229705e79c5c7bcfca)
|
|
Change-Id: Iface28ab770beee00374afb902ef4f9c983538f5
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit 597e4b55f57001ead8e90f30e2e3211c7d705ca8)
|
|
MaaS node does not need to be exposed to the public network; instead
the management IP should be enough to access the MaaS dashboard.
So, drop 'infra_maas_node01_external_address' reclass param, together
with its OPNFV PDF param, 'opnfv_infra_maas_node01_external_address'.
This allows us to move compute public IPs back to .{2,3} instead of
.{101,102}, where we moved them during 'pod_config.yml' addition.
While at it, fix a minor duplicate 'name' param for 'br-mgmt' bridge
on kvm nodes.
Change-Id: Ie9fcf5924d7aa37b666f42c968687d73b51a8278
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit ee4d89f2803085bdd4a7f3b365e40ec9366c25a9)
|
|
|
|
* [baremetal] add memory to contollers & salt master
* tune up sysctl vm.dirty* for compute nodes
* upgrade packages to get the latest versions
(https://bugs.launchpad.net/cinder/+bug/1641312)
Change-Id: I9ad22206f2f3f11e1da3f93c7a0931c592adf1cf
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
(cherry picked from commit 87310fb8edfe49b9621fe4410ae52d989072e3c5)
|
|
Implementation for baremetal-mcp-ocata-ovs-ha scenario
JIRA: FUEL-275
Change-Id: Id6ab5697f993ac9faa019c3c10ba4ed4b7b6db01
Signed-off-by: Guillermo Herrero <guillermo.herrero@enea.com>
(cherry picked from commit 5c0a09fbd0f377df56bfcfe94b262225a34f98ff)
|
|
Live-migration feature requires shared storage on compute nodes,
so configure glusterfs volume for nova instances.
Change-Id: Id6b9b5aad89f5b4aefbef71e4ba7247a441873b0
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
mcpcontrol virsh network, as well as MaaS PXE network are installer
specific, and not POD specific.
Therefore, these should be easily parametrized without the PDF,
using only installer inputs (e.g. env vars passed via Jenkins).
- add new <all-mcp-ocata-common.opnfv.runtime> reclass class;
- parametrize at runtime new reclass class based on global vars;
- factor out MaaS deploy address / config using new mechanism;
- parametrize at runtime virsh network definitions based on template;
- add new "maas.pxe_route" sls for configuring routing on cfg01;
- replace env vars with the new sls in "maas" state;
NOTE: baremetal parametrization will be handled later.
Change-Id: Ifd61143d818fb088b3f4395388ba769bbc49156e
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
Use INSTALLER_IP Jenkins param instead of SALT_MASTER_IP, allowing
us to drop SALT_MASTER_IP completely from releng.
mcpcontrol IP changes:
- 192.168.10.100 becomes 10.20.0.2 (align with legacy Fuel master);
- 192.168.10.3 becomes 10.20.0.3 (baremetal MaaS address);
JIRA: FUEL-285
Change-Id: I6e2d44c3a8b43846196bd64191735214167a76ce
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.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>
|
|
Change-Id: I34706afbdbcbdaace0b0ae6c2c2e8cb932812d4e
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Change-Id: I8937f4f676a48c852bece0680da0b559df7c2e7c
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Virtual node based on cloud ubuntu image
won't register as a minion on salt master.
Change-Id: Ia32eae01a5633042189cdebebcba8043cae61503
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
JIRA: FUEL-274
Change-Id: I2c8161b24cb18a0d1f9dc6fd509ce18af7ea8cf5
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
* add user of "ubuntu" so that functest gets cluster credentials
* reduce cpu resources for vcp nodes in nofeature scenario
* tune salt targets for maas state
* specify ntp servers
Change-Id: I433a1de1cd2c69c6747c62c3359f5485dee3bfa4
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Change-Id: I01744bd5728d6fc4c8cd3792aee9759434d18645
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Change-Id: I4baa9940ae14ef6e084fda7169ec43be7cf3f449
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
* shift vcp nodes interfaces since names started from ens2
* add extra salt sync before vcp start up
* run rabbitmq state on 1st node beforehand then the rest
Change-Id: Ic2c174c288a5e89f2f28c0d9aa573340190a61d3
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
In order to connect to right underlay
bridge, swap interfaces.
Change-Id: I0ae1f50e8d1f3485404bd7e6eea772cab555b313
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
Previously, we hardcoded the fabric name for our 3rd interface
(which serves PXE/DHCP for the target nodes) to "fabric-2",
relying on predictable index numbers to be provided by MaaS based
on the interfaces defined in /etc/network/interfaces.
However, the fabric IDs/names generated by MaaS are not predictable,
and therefore cannot be hardcoded in our reclass model / scripts.
Work around this by:
- adding support for fabric ID deduction based on CIDR matching
during subnet create/update operation in MaaS py module;
- adding support for VLAN DHCP enablement to MaaS py module,
which was previously handled via shell MaaS API operations
from maas/region.sls;
While at it, revert previous commit that disabled network discovery
("MaaS: Disable network discovery"), since it turns out that network
discovery was not the culprit for subnet creation failure, but wrong
fabric numbering.
This reverts commit 8cdf22d1a1bae4694a373873cab4feb6251069b7.
Change-Id: I15fa059004356cb4aaabb38999ea378dd3c0e0bb
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
In case nodes are already powered on and have an IP in the same
range as the new MaaS DHCP one (e.g. from a previous deploy),
MaaS API will reject the subnet creation due to overlapping
addresses. Try to work around this by disabling network discovery.
Change-Id: I70a33c552bf38a7ccbc1bb7e90c21f424f082bc5
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
Without the 'type' parameter set to 'dynamic', MaaS was configured
to reserve the IP range instead of allocating it dynamically.
This led to IP exhaustion warnings in MaaS dashboard, as well as
wrongful IP allocation.
Change-Id: I1f2b90bf4cd2393cfab6d4bc17771cef009701c0
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
Explicitly configure dhcp_interface for mas01, in order to allow
the interface name to be parametrized via "dhcp_interface" _param.
Change-Id: I6a2750adc1941c0aa1f94ac9b39133b5bd2388c6
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|
|
* re-assign ip from interface to bridge
- install bridge utils
- make a reboot straight away after network config
* change image source for vcp
Change-Id: I34506ee161337b5d3a4088cfdf3c082d99ccb695
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
|
|
- ci/deploy.sh: fail if default scenario file is missing;
- start by copying reclass/classes/cluster/virtual-mcp-ocata-ovs as
classes/cluster/baremetal-mcp-ocata-ovs;
- add new state (maas) that will handle MaaS configuration;
- Split PXE network in two for baremetal:
* rename old "pxe" virtual network to "mcpcontrol", make it
non-configurable and identical for baremetal/virtual deploys;
* new "pxebr" bridge is dedicated for MaaS fabric network, which
comes with its own DHCP, TFTP etc.;
- Drop hardcoded PXE gateway & static IP for MaaS node, since
"mcpcontrol" remains a NAT-ed virtual network, with its own DHCP;
- Keep internet access available on first interfaces for cfg01/mas01;
- Align MaaS IP addrs (all x.y.z.3), add public IP for easy debug
via MaaS dashboard;
- Add static IP in new network segment (192.168.11.3/24) on MaaS
node's PXE interface;
- Set MaaS PXE interface MTU 1500 (weird network errors with jumbo);
- MaaS node: Add NAT iptables traffic forward from "mcpcontrol" to
"pxebr" interfaces;
- MaaS: Add harcoded lf-pod2 machine info (fixed identation in v6);
- Switch our targeted scenario to HA;
* scenario: s/os-nosdn-nofeature-noha/os-nosdn-nofeature-ha/
- maas region: Use mcp.rsa.pub from ~ubuntu/.ssh/authorized_keys;
- add route for 192.168.11.0/24 via mas01 on cfg01;
- fix race condition on kvm nodes network setup:
* add "noifupdown" support in salt formula for linux.network;
* keep primary eth/br-mgmt unconfigured till reboot;
TODO:
- Read all this info from PDF (Pod Descriptor File) later;
- investigate leftover references to eno2, eth3;
- add public network interfaces config, IPs;
- improve wait conditions for MaaS commision/deploy;
- report upstream breakage in system.single;
Change-Id: Ie8dd584b140991d2bd992acdfe47f5644bf51409
Signed-off-by: Michael Polenchuk <mpolenchuk@mirantis.com>
Signed-off-by: Guillermo Herrero <Guillermo.Herrero@enea.com>
Signed-off-by: Charalampos Kominos <Charalampos.Kominos@enea.com>
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
|