changed behavior of "firewall-cmd --permanent --get-target --zone public" in new versions

[azhurbilo]

Today I faced with idempotency issue.

if set target with % symbol

firewalld_zone { '***':
   ...
    target => '%%REJECT%%',
  }

firewall-cmd return value without %

#  firewalld version 4.3.2-8.1.el7_3
firewall-cmd --permanent --get-target --zone public
# REJECT

in previous version firewalld 3.9-14.el7
It returns correct value

firewall-cmd --permanent --get-target --zone public
%%REJECT%%

---

Now I use value without %

target => 'REJECT',

as in result it generate correct value

<?xml version="1.0" encoding="utf-8"?>
<zone target="%%REJECT%%">
  <short>Public</short>

but it looks like workaround.

Could you comment about this case?

[crayfishx]

Looks like firewalld have changed the responses in v4 :-( - As you say, your workaround does work but this requires people to change their code when moving from firewalld 3 -> 4, so we should probably make the module backwardly compatible and recognize both %%REJECT%% and REJECT as the same

[crayfishx]

Tracked this down to this change...

t-woerner/firewalld@7d7a7a9

From what I can see from the changelogs this was introduced between 0.3.11-2 and 0.3.12-1, I really wish changes like this would be part of a major release as it breaks any tool that relies on consistent output from the firewall-cmd CLI (like this module)

The motivation seems to be hidden in a RedHat bugzilla ticket (RHBZ#1058794) that doesn't seem to be accessable publicly.

@t-woerner I'm not sure what kind of versioning system that firewalld uses, but changing the CLI output can break a lot of automation tools, it would be nice if these were better communicated in a major version release rather than just snuck in.