Bug?: (Helm) unable to add rule to previously created (default) firewall
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- go, helm
- Domain
- infrastructure
Research direction
Start with helm/controller/templates/firewall.yaml and internal/controller/cloudfirewall_controller.go around the linked lines. Compare the Helm ownership metadata with the controller-created default CloudFirewall, then reproduce installing with default values followed by adding a rule. Done means that workflow no longer fails because Helm cannot adopt the existing firewall.
Written by the indexing model from the issue text.
Description
The helm template for the CloudFirewall has one big if statement around it:
This means that if you install the helm chart with default values, no (Helm managed) CloudFirewall will be created. However the Golang controller code will create a default firewall if no CloudFirewall exists:
Later on adding a rule via Helm however will now fail, because it will try to create a Helm managed CloudFirewall (see above) where the object already exists. Helm will fail with:
╷
│ Error: Unable to continue with update: CloudFirewall "primary" in namespace "kube-system" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "cloud-firewall-controller"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"
│
│ with helm_release.linode_firewall_controller,
│ on main.tf line 70, in resource "helm_release" "linode_firewall_controller":
│ 70: resource "helm_release" "linode_firewall_controller" {
│
╵
Note: the above is actually a failure of Helm wrapped in Terraform because I'm doing the helm install via Terraform, but that's besides the point. Helm is correct in the sense that because the original CloudFirewall was not created by Helm previously, it should not suddenly manage it and will therefor fail.
- Dominant language
- Go
- Stars
- 16
- Forks
- 9
- Avg merge
- 5m
- Merged PRs (30d)
- 1
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from linode/cloud-firewall-controller
-
Using to many rulesOpen
Difficulty 3/5 1-2 days Newbie friendliness 35/100
linode/cloud-firewall-controller#28 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
linode/cloud-firewall-controller#17 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
linode/cloud-firewall-controller#16 · 1 comment ·
-
cleanup of controller owned firewallsMay be free again @hcwagner claimed this 744 days ago, and no pull request is open. Openenhancement
linode/cloud-firewall-controller#2 · 1 comment · 1 reaction · 1 assignee ·
All issues in linode/cloud-firewall-controller
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
[E2E Scenario Tests] HTTP logs capture export requests from test framework, polluting golden filesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
GoogleCloudPlatform/k8s-config-connector#13675 ·
Maintainers usually reply within 1 day
-
ai-inspected
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day