terraform-provider-kubernetes
terraform-provider-kubernetes copied to clipboard
kubernetes_manifest creates new resource instead of renaming existing
Terraform Version, Provider Version and Kubernetes Version
Terraform version: 1.0.3
Kubernetes provider version: 2.4.1
Kubernetes version: AWS EKS 1.21
Affected Resource(s)
- kubernetes_manifest
Terraform Configuration Files
resource "kubernetes_manifest" "strip_prefix" {
manifest = {
apiVersion = "traefik.containo.us/v1alpha1"
kind = "Middleware"
metadata = {
name = "${var.service_name}-stripprefix2"
namespace = var.kubernetes_namespace
}
spec = {
stripPrefix = {
prefixes = [var.app_path]
}
}
}
}
Debug Output
# module.app["test"].kubernetes_manifest.strip_prefix will be updated in-place
~ resource "kubernetes_manifest" "strip_prefix" {
~ manifest = {
~ metadata = {
~ name = "test-stripprefix" -> "test-stripprefix2"
# (1 unchanged element hidden)
}
# (3 unchanged elements hidden)
}
~ object = {
~ metadata = {
~ name = "test-stripprefix" -> "test-stripprefix2"
# (1 unchanged element hidden)
}
# (3 unchanged elements hidden)
}
}
module.app["test"].kubernetes_manifest.strip_prefix: Modifying...
module.app["test"].kubernetes_manifest.strip_prefix: Modifications complete after 1s
Releasing state lock. This may take a few moments...
Apply complete! Resources: 0 added, 2 changed, 0 destroyed.
Steps to Reproduce
terraform apply- Modify metadata.name for the resource
terraform apply
Expected Behavior
The resource should have been renamed, just like the plan said it would
Actual Behavior
I ended up with two resources, one with the old name, and one with the new
kubectl -n test get middlewares
NAME AGE
test-stripprefix 24m
test-stripprefix2 15m
Important Factoids
The configuration above is a minimal one, but I had several different manifests that all experienced the same problem
References
None that I've found
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Hi,
Thanks for sharing your issue with us. This is in fact expected behaviour. The reason behind it is that the CRDs from the Traefik project are lacking schema information. The maninfest resource relies on this schema information in CRDs to be able to correctly manage the state of the resource in Terraform. When its absent, the provider has to fall back to deleting and recreating the resource in order to ensure Terraform's state doesn't get corrupted.
AFAIK, the Traefik project are working on adding schema to their CRDs. Please check if you are using their latest available release and if that release comes with CRDs which include schema.
Thanks @alexsomesan but I'm actually using the CRDs with schemas, although from when they were just released. I'll compare with latest in case there's been some changes or upgrades to the schema/CRD version.
I grabbed the latest CRDs and there are only a few documentation changes since the ones I have, so it doesn't seem like this is the problem. Is there anything else I can do to try and diagnose what's happening?
Additionally, it did not delete the old resources, renaming or delete/create would both have been fair, but it left the resources behind with their old name in addition to creating new ones.
I can confirm this, changing the name of a custom resource (WITH schema) creates a second object. The problem isn't the schema as an object's metadata isn't part of the schema of a CRD, it is part of the core Kubernetes API. The problem is the provider sees a change in name as something that can be updated in-place and therefore does an update with the new fields, and since that name (presumably) doesn't exist it does a create with the new name instead of an update.
I tried reading the code base for the manifest resource, but it's a little to complicated for a cursory glance. But basically what is needed is that the schema needs ForceNew set to true for metadata.name (and, while I haven't tested it, presumably metadata.namespace as well)
I also have this problem. I think it's pretty safe to say that metadata.name and metadata.namespace are immutable for all resources. This means that setting ForceNew as suggested in https://github.com/hashicorp/terraform-provider-kubernetes/issues/1373#issuecomment-910391317 should not introduce any imcompatibilities.
Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!
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.