-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Firewall direct rules get stuck in permanent when subsequent exec reload get skipped #276
Comments
i'm working on a pull request ! |
isqo
added a commit
to isqo/puppet-firewalld
that referenced
this issue
Apr 1, 2020
- Check direct rules existence in both runtime and permanent - Put all provider direct rules unit tests in firewalld_direct_rule_spec.rb
isqo
added a commit
to isqo/puppet-firewalld
that referenced
this issue
Apr 1, 2020
- Check direct rules existence in both runtime and permanent
isqo
added a commit
to isqo/puppet-firewalld
that referenced
this issue
Apr 1, 2020
- Check direct rules existence in both runtime and permanent - fix wrong chain_args value in direct chain spec - put all direct passthrough provider unit tests in its corresponding file
isqo
added a commit
to isqo/puppet-firewalld
that referenced
this issue
Apr 3, 2020
- Check rich provider rules existence in both runtime and permanent - put all rich rule provider unit tests in provider spec file
isqo
added a commit
to isqo/puppet-firewalld
that referenced
this issue
Apr 3, 2020
- Check port's existence in both runtime and permanent
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce
1 - set a dependency between Exec[Firewalld::reload] and another puppet resource that fails in your manifest
2 - add a configuration of a direct rule in hiera or in you manifest
3 - sync your code and deploy
What are you seeing
The direct rule getting deployed in the permanent stage but the reload doesn't execute (skipped). Consequently, it stays inactive in the permanent area waiting for a subsequent reload to occur in the future to get deployed.
What behaviour did you expect instead
if the direct rule isn't present in the Runtime stage, it shouldn't be considered deployed
Any additional information you'd like to impart
is there any reason behind checking rules' existence with the permanent flag ?
i observed the same behavior occuring for the other rules
The text was updated successfully, but these errors were encountered: