Bug 2269219

Hey, so the firewall rules should be the same for each deployment regardless of whether it's the first or fifteenth deployment. Because we set all of them based on this fact:
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/tripleo_firewall/tasks/main.yml#L77-L88

Then we apply the rules from the fact {{ firewall_rules_sorted }}:
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/tripleo_firewall/tasks/main.yml#L116


So I'm just trying to clarify what you mean here: "pre-existing iptables rules and appended rules will not follow relative order in rule numbers"

What are we referring to as "pre-existing iptables rules"?

Hi Brendan.

Thank you for taking a look. Indeed, this part works fine: ordered list of rules is passed to tripleo_iptables, which then parses them [1] and applies one by one via built-in iptables module [2]. This part works fine and rules are passed in correct order. The problem is that when built-in iptables module applies a rule that already exists, then it completes with no-op; while new rules are either inserted or appended. As a result, when someone tries to add new rules via ExtraFirewallRules in existing deployment, new rules will be either inserted or appended on top of existing ones and related order between existing ones and new ones will not be preserved. Example outcome is provided in 0010-firewall.yaml and 0020-iptables.txt attached to case 03759681; 0060-overcloud-deploy2.tar.gz has ansible debug logs + sosreports from controller nodes explaining the points I have mentioned.

[1]
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/ansible_plugins/action/tripleo_iptables.py#L169-L289

[2]
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/ansible_plugins/action/tripleo_iptables.py#L329-L333

It looks like a similar issue has been raised here actually, James appears to have spent some time on it there with the verdict being that the easiest way to clean it up is to remove the existing rules:
https://bugzilla.redhat.com/show_bug.cgi?id=2242069#c3

The other options I thought of were flushing the rules before applying, or writing all of the rules out to the iptables-save location and then reloading from those rules. But those options are problematic because of Neutron's dynamic iptables rules, so we can't go that route.

James' solution proposed there is probably the path of least resistance at the moment.


We could probably look into providing support for inserting at line numbers, but that would still be a mess unless each and every rule we create has an explicit line number.

And we can't really change the underlying iptables module in Ansible without forking it at this point. We would need to avoid doing that though.

Hi Brendan. Thank you for taking detailed look. I also tried to evaluate some options you proposed and indeed they don't look like a perfect solution to me. Adding an option to insert rules to specific line number may be useful to certain extend: operators may use it to put a new rule to specific place and then remove line number from specification. But overall whole concept is very fragile and error prone.

I am wondering if we can consider an option to return puppets? They more or less worked for us and had less problems.

UPD. Recommendations from James didn't work in customer's deployment. I investigated this a bit and it looks like they are not going to work with current state of tripleo_iptables lib. More information: https://bugzilla.redhat.com/show_bug.cgi?id=2242069#c4

We have a few bugs going for the same thing it seems. There is more context on the other BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=2242069

Do we agree that we're talking about the same problem on both of these bz's? Because if so, we should consolidate the conversation over there to avoid confusing threads of similar information.

Hi Brendan.

From my perspective all bugs report slightly different problems:
- this bug is about idempotency of rules applied by tripleo_iptables: it doesn't related to FFU procedure and is solely about applying different sets of rules in the same overcloud consistently. 
- bug #2242069 is about pre-existing RHOSP 16 rules and ability of tripleo_iptables to manage them. This is related to FFU procedure and has little to do with previous point because the root cause seem to be https://bugzilla.redhat.com/show_bug.cgi?id=2242069#c4
- bug #2269002 may be related to this bug, but only to certain extent: solution for this bug may solve bug #2269002 as well, but it also may not. So it depends on engineering.

Best Regards, Alex.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: RHOSP 17.1.4 (openstack-tripleo-heat-templates) security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:9978