Skip to content
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

Terraform does not respect ordering of firewall rules in an Openstack firewall's policy #7172

Closed
scrossan opened this issue Jun 15, 2016 · 4 comments · Fixed by #7194
Closed
Labels

Comments

@scrossan
Copy link

scrossan commented Jun 15, 2016

Hi Hashicorp,

I need to apply firewall rules in my Openstack firewall policy in a specific order in order to allow/deny certain things. However, Terraform does not seem to respect the order of the rules passed to the openstack_fw_policy_v1 resource and this is causing me problems because the firewall therefore does not behave as I expect it to.

Previously we explicitly ordered the rules by number depending on their position in a list. However, the result of this was that the firewall was ripped out and replaced on each apply (because the rules would be deleted/created if their position in the list changed), causing confusion in the diffs which did not give us the confidence to apply in production. Ideally, Terraform would use the array of rules to guide the positioning of new rules and insert before/after as necessary.

Please let me know if you need any further information from me and I will be happy to assist.

Terraform Version

Terraform v0.6.16

Affected Resource(s)

  • openstack_fw_policy_v1

Terraform Configuration Files

Please find an example in the following gist, which I have found to demonstrate the same behaviour we find with our own configuration files - which I am unable to share with you: https://gist.github.com/scrossan/e5d5ba1d154e313cd21887879810f8e9

Interestingly, what seems to be the case is that when the destination IP addresses are ordered (e.g. for each of the three rules, 2.2.2.1, 2.2.2.2 and 2.2.2.3) the rules are ordered the correct way in the policy. However, if I change the way the rules are ordered in the rules array in the openstack_fw_policy_v1 resource, leaving the ordered IPs the same, then Terraform will not detect this as a change.

In this example the destination IPs are all the same, resulting in mis-ordered rules in the policy: rule_2, rule_1 and rule_3 despite the ordering in the array of rules.

Debug Output

https://gist.github.com/scrossan/00659bd731e51db60f237f63f395529b

Expected Behavior

I expected Terraform to order the firewall rules in the policy according to the order I passed them to the policy in the array of rules.

Actual Behavior

Terraform re-ordered the rules and they are ordered differently in the firewall policy than the order given in the array of rules.

Steps to Reproduce

  1. terraform apply
  2. Observe mis-ordered rules in Openstack
  3. terraform destroy
  4. terraform apply
  5. Observe rules ordered differently than in 2, but still mis-ordered

Important Factoids

Our cloud provider is using Openstack Kilo.

@jen20
Copy link
Contributor

jen20 commented Jun 15, 2016

Hi @scrossan! Thanks for reporting the issue. I think the problem here is that the rules are defined in schema as a set, which does not provide any ordering semantics. Instead we should change this to a list, which does. Offhand I'm not sure if this will cause spurious diffs with state migration however.

cc @jtopjian, who often maintains the openstack provider!

            "rules": &schema.Schema{
                Type:     schema.TypeSet,
                Optional: true,
                Elem:     &schema.Schema{Type: schema.TypeString},
                Set:      schema.HashString,
            },

@jtopjian
Copy link
Contributor

👍

This is now on my radar. Thanks, guys!

@scrossan
Copy link
Author

@jen20 + @jtopjian, I appreciate that you guys may have been at Hashiconf EU recently so have submitted a PR to address this issue; please let me know if any further work is needed!

@ghost
Copy link

ghost commented Apr 24, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants