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

cloudflare_ruleset can't be independent of its rules #3226

Closed
2 tasks done
mooseracerPT opened this issue Apr 4, 2024 · 4 comments
Closed
2 tasks done

cloudflare_ruleset can't be independent of its rules #3226

mooseracerPT opened this issue Apr 4, 2024 · 4 comments
Labels
triage/duplicate Indicates an issue is a duplicate of other open issue.

Comments

@mooseracerPT
Copy link

Confirmation

  • My issue isn't already found on the issue tracker.
  • I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.7.4
on linux_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.35.0

Affected resource(s)

cloudflare_ruleset

Terraform configuration files

resource "cloudflare_ruleset" "magic_transit_example" {
  account_id  = "f037e56e89293a057740de681ac9abbe"
  name        = "account magic transit"
  description = "example magic transit ruleset description"
  kind        = "root"
  phase       = "magic_transit"

  rules {
    action      = "allow"
    expression  = "tcp.dstport in { 32768..65535 }"
    description = "Allow TCP Ephemeral Ports"
  }
}

Link to debug output

n/a

Panic output

No response

Expected output

This is a suggestion to create a new optional resource cloudflare_ruleset_rule that you could attach to an existing cloudflare_ruleset, say via a data lookup. My use case is that I want to have multiple terraform workspaces (environments) each handling their own rule for the ruleset. With this pattern I could create an empty ruleset for the phase, and then control individual rules from their respective environment's workspace.

Actual output

With the current implementation of cloudflare_ruleset I'm forced to handle all possible rules on a phase at the same time. This means the code for it needs to live outside my existing workspaces, and needs to lookup all the values it needs to construct the rules.

Steps to reproduce

This is a design issue.

Additional factoids

No response

References

No response

@mooseracerPT mooseracerPT added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 4, 2024
Copy link
Contributor

github-actions bot commented Apr 4, 2024

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

Copy link
Contributor

github-actions bot commented Apr 4, 2024

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

@github-actions github-actions bot added triage/needs-information Indicates an issue needs more information in order to work on it. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 4, 2024
@jacobbednarz jacobbednarz closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2024
@jacobbednarz
Copy link
Member

jacobbednarz commented Apr 4, 2024

duplicate of #3210, #2907, #2423 and #2688

@jacobbednarz jacobbednarz added triage/duplicate Indicates an issue is a duplicate of other open issue. and removed kind/bug Categorizes issue or PR as related to a bug. triage/needs-information Indicates an issue needs more information in order to work on it. labels Apr 4, 2024
@petero-dk
Copy link

I added a workaround using multiple repositories here: #3027 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/duplicate Indicates an issue is a duplicate of other open issue.
Projects
None yet
Development

No branches or pull requests

3 participants