-
Notifications
You must be signed in to change notification settings - Fork 63
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
no updates when modifying the code #240
Comments
Hi! |
Yeah, creating from beginning isn't the best option. It's literally the opposite of the essence of terraform. Strange because I must admit that I had the same scenario when using Ansible in the same case. |
I will be able to get to the test lab only tomorrow. If you have a desire, try to create a resource using REST API (change the connection string) and see if MT behavior changes. |
The key question is what version I'm using and my fault I didn't provide you with this info. The last version of v6 => |
Please do not disconnect your working Microtik, there is no urgency, I will check a little later on the docker container.
|
Ok I get. So please test and check if this is a v6 problem and on v7 using REST API the problem disappears. I was referring to documentation of your provider and I saw info that this was tested on v6 also and works that's why I was confused when it appears that it doesn't. |
Ok, after testing I'll come back with feedback. Could you please tell me where the 6.x version is mentioned? This is, I think, an artifact and needs to be fixed. |
Got it, thanks! I'll make an addition to avoid any ambiguity. |
The problem was actually caused by my mistake. Please test the provider after the release and give feedback. |
🎉 This issue has been resolved in version 1.13.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Checked
After:
Also adding a dhcp-option for further tests
Worked
Now |
I saw a typo in the word "code" but never fixed it and it automatically went into the release. 🤦 |
I wonder why no one saw that and request an issue. Was it only a problem with v6 ? Does it means most of the users are using v7? |
The problem was for both version 6 and 7 when using the old API. You are right, people are probably using version 7 and the REST API. |
Describe the bug
It's strange but when changing attribute value no changes are made. I tried with many options but I will focus on related with dhcp server leases and disabled option to show the essence of problem
To Reproduce
provider.tf
main.tf
variables.tf
dhcp.auto.tfvars
Expected behavior
When running for the first time everything goes well
$ tf plan
Apply works as expected
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
When changing adding attribute
disabled = true
it shouldchange the item to be disabled on MikroTik
But instead it does update-in-place and does nothing on MikroTik. Element is still enabled
apply gives
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
Stack Trace
When first element created and apply finished successfully
When disabled set to true and run apply
Strange because it shows that request finished successfully
response body: !done
but it seems it's a fake informationAdditional context
This is just an example when doing additional change on existing resource. The Terraform should work declaratively but right now it looks like this provider can't handle any updates because it requires removing whole resources and then by adding additional feature or like in the example above disabling , changing existing one.
The text was updated successfully, but these errors were encountered: