Linux bridges are automatically set UP when
any parent interface is UP.
But for OVS bridges it doesn't work.
For dpdk and non-dpdk bridges, always create a
config file in /etc/network/interfaces.u/ and
bring the bridge interface up after it is configured,
even if it doesn't have IP address.
Change-Id: I92888ce0d373e412dfb7ed2e2398c0d4d008e301
Closes-Bug: https://mirantis.jira.com/browse/PROD-24343
Issue description:
PXE interfaces, which are used by salt should not be restarted
during salt calls, otherwise communication between salt master and
salt minion would be interrupted.
Therefore it is possible to specify "noifupdown: True" in pillars
for this interface or group of interfaces, which are used for PXE
network.
This pillar structure will remain until one removes it manualy.
It is not possible to remove it during deploy and enforce network
state without touching the model.
It is possible to override pillars from CLI like:
# salt ctl01* state.apply linux.network.interface \
pillar='{"linux":{"network":{"interface":{"ens3":{"noifupdown":True}}}}}'
However it is not easy/possible to predict all interfaces for PXE
network.
Solution:
Provide global noifupdown pillar value check.
If it exists, noifupdown will take effect and not otherwise.
So our deployment would have next steps:
- Execute: linux.network.interface pillar='{"linux":{"network":{"noifupdown":True}}}'
- Reboot node to enable kernel params like hugepages etc.
- Execute: linux.network.interface with no params to ensure PXE.
Pipelines may pass this parameter to control noifupdown behavior.
Change-Id: I8863f972c7805e4bf4f9e104d6c0ddf055c39cb1
The patch makes IP address flush for external network
interface where IP address is assigned automatically
however an IP address from the same IP range is hardcoded in
the model.
Change-Id: I4220a635a96a031ad74dca1034c917e7d87d4b11
Related-PROD: PROD-19504
Issue: First time you configure dpdk ovs switch it would stuck on
answering salt-minion because kernel options, such as
intel_iommu,iommu,isolcpus, are not set and ovs would
exhaust all hugepages and fail to apply options on the fly.
Fix: Configure ovs switch without waiting for an answer and
reboot the node afterall as we do this all the time before
starting automated pipeline.
Change-Id: Ica27a6cc47312bcc0762cddde049a0abf771f9fb
Previously there were no dependency and as result we tried to add port to
non existent bridge.
Change-Id: I69ad6a6faecf399185a72650e8dbeb019b6fbc05
Related-Prod: PROD-18112
Previously, setting up routes did not allow passing 'require_reboot',
so each route change would lead to a networking service restart,
rendering interface configuration options like 'noifupdown' useless.
Allow disabling network restart per-interface using the existing
'noifupdown' option.
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
Fixed:
* The udev-rules template is not tested
* Wrong unicode character in the template leads to udev ignoring
the rule completely
* The template is unable to be rendered due to absent import
* udev is not retrigerred with new rules
Change-Id: I134b5e49b883afcc5e34feaaa561d7ca70192796
Closes-Bug: PROD-16649
This workaround is required until salt with the patch [1] is not
used.
- use 'ifenslave' tool to enslave necessary interfaces only if bond
interface has been changed
- install package that provides 'ifenslave' tool
[1] https://github.com/saltstack/salt/pull/39912
Change-Id: I65b607f26cf7319efb60f154951855d1334e1640
Non-destructive patch, won't affect anything because this
option is not used in any model yet.
Official guide for network.managed state provides an example:
bond0:
network.managed:
- type: bond
- slaves: eth2 eth3
- require:
- network: eth2
- network: eth3
...
without parameter: '- use:'
* add a new option 'require_interfaces' that allows to set
'- require:' not only for 'bridge' interfaces
* using 'require_interfaces' allows to fix the order for states
that create bonds (do not try to create bond0 before slave
interfaces are configured!)
* using 'require_interfaces' allows to fix the order for states
that create VLANs (do not try to create tagged interfaces before
parent interface is created, it locks the parent interface
creation!), example: bond0.2516 created before bond0
* using 'require_interfaces' allows to fix the order for states
that depend on OVS interfaces
Change-Id: Id4539a7e24f2c55fb62afe5d47e485effc9a882b
Interface name was hardcoded when checking if peer is set for
ovs interface.
This patch unhardcode interface name.
Change-Id: Id465d5f84751b5516aebc9d80716d21d14e56abc
This patch adds dependency for ovs_port_up_{{ interface_name }} on
linux_interfaces_final_include. This is needed to avoid errors like
"Unknown interface XXX"
Change-Id: I763ff8ae32a170df3802a65a547c6e76959a0137
Change of mtu is not handled by reclass. Example interface:
```
br_ctl:
enabled: true
type: bridge
proto: static
mtu: 1450
address: ${_param:single_address}
gateway: ${_param:ctl_gateway}
netmask: ${_param:control_network_netmask}
use_interfaces:
- ${_param:primary_first_nic}
```
We need to save our manualy managed interfaces to different directory to
workaround salt bug that causes interface deconfiguration in
/etc/network/interfaces for interfaces manualy configured in
/etc/network/interfaces.d
Upstream-Bug: https://github.com/saltstack/salt/issues/40262
Config:
linux:
network:
tap_custom_txqueuelen: 10000
in case of configuration parameter defined will create file:
/etc/udev/rules.d/60-net-txqueue.rules
with content:
KERNEL==”tap[0-9a-z\-]*", RUN+="/sbin/ip link set %k txqueuelen 10000"
Introduce dpdk support for linux OVS configuration.
It configures dpdk interface bind, ovs dpdk ports, bonding,
parameters for dpdk cpu pmd and set multique queues for specific
ovs dpdk interfaces.
Change-Id: I3f38660bab8db0c2b38f03ed8c94eb10b6b3beb9
Epic: PROD-8957
Epic: PROD-8958
"names" makes a separate call to the package management frontend to
install each package, whereas "pkgs" makes just a single call so that it
improves performance.