Looking at the linked firewall module, it would definitely be worth investigating it's use (since we state in the Enterprise docs that we don't support the use of lokkit), it also appears to support all the use cases that we would need.

The one catch would be that we would need to make sure that we do not clobber over the dynamically added rules if puppet is re-run.

As a user of puppetlabs-firewall, I'd welcome this as well.

What really needs to happen here is to follow the pattern of other puppetlabs modules in that they have a manage_firewall Boolean parameter to any classes that would make changes to iptables.

Leaving this as true by default allows users to quickly setup a testing environment without issues. Having the option to disable firewall configuration also allows advanced users to work with the tool of their choice for managing iptables.

Adding that option is a good idea, though not a solution to the actual problem. OpenShift should either directly use the Firewall module or specify the iptables package using ensure_resource, which would not cause an error when the resource is added twice.
Disabling firewall handling should not be the only way past this conflict, since you shouldn't have to manually add the same firewall rules that are already in the OpenShift module.

@invliD I can imagine that using 2 different firewall modules (lokkit and puppetlabs-firewall) will give conflicts anyway.

We are avoiding further usage of ensure_resource.

When using ensure_resource you are unable to enforce predictable ordering around that resource.

Since part of the OpenShift firewall configuration requires adding a chain that is used by the openshift-iptables-port-proxy, just having a flag to toggle the firewall configuration is not overly reliable. That said the openshift-iptables-port-proxy service will create/insert the chain if it is missing, however it will not be persisted in the firewall config, so restarting the firewall service after the openshift-iptables-port-proxy service will cause the port proxy to fail until it is restarted.

The best path forward (imho) is to migrate to using the more standard firewall module and possibly offer a flag to disable the firewall configuration with an associated warning telling the user that it is a really BAD idea.