We're seeing when the shell command fails (for whatever reason) and since
it's failed_when: false, the subsequent tasks actually fail. We can
check if stdout is not defined as a failure condition because that means
the module itself failed and we should not continue to process the
next tasks since they depend on stdout being defined.. Additionally we
can add some retries to try again if possible.
Change-Id: Iabc1619009220c6f1c91b84f81d5262c4d9d8430
Related-Bug: #1885697
Ansible 2.9 does not accept the "installed" state so we need to update
occurences of that to "present".
Change-Id: I13c95794efc63697c2418334ded7c6912bd7b59f
We continue to see the odd task rc of -13 when running iptables-save to
store persistent set of firewall rules. Switch to shell to give us a bit
more debugging freedom if necessary (and to rule out the command
module).
Change-Id: I0c0208101cad985d4113de6b636c3816613b778c
In openSUSE Tumbleweed, the SuSEfirewall2 package was removed in favor
of firewalld[1]. This commit updates the iptables persistance tasks to
avoid using SuSEfirewall2 and instead use rc.local to restore saved
rules upon restart, and undefines the iptables_service variable for SUSE
since there is no service to restart any more. See the related change
for image builds[2].
[1] https://lists.opensuse.org/opensuse-factory/2019-01/msg00490.html
[2] https://review.opendev.org/683236
Change-Id: I0f8d74dd00df192c20b96a9368b964839c306171
iptables-services might not be installed and is required if we're
expecting to be able to start a service called "iptables".
Installing that package is what provides the 'iptables' systemd unit
file.
Change-Id: Ic4ccbc3a0fb531d3d3b7924d22ed0b993a689622
We configured iptables rules but did not persist them.
This meant that rules would be flushed when restarting iptables or
the instance.
Change-Id: I9d90f55323a33d6a0f0dda1f7ab25d10984fa6cb
Sorin Sbarnea