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

google_sql_database_instance.settings.backup_configuration.binary_log_enabled is not changing #6121

Closed
syedrakib opened this issue Apr 15, 2020 · 14 comments · Fixed by GoogleCloudPlatform/magic-modules#3397, #6163 or hashicorp/terraform-provider-google-beta#1973
Assignees
Labels

Comments

@syedrakib
Copy link

syedrakib commented Apr 15, 2020

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
  • Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.
  • If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

0.12.24

Affected Resource(s)

  • google_sql_database_instance

Synopsis

I spinned up ClousSQLMysQL with settings.backup_configuration.binary_log_enabled set to true. Now i am trying to set it to false with this

        backup_configuration = {
          enabled            = false
          binary_log_enabled = false
          start_time         = "00:05"
        }

The terraform plan said:

        backup_configuration {
          ~ binary_log_enabled = true -> false
            enabled            = false
            start_time         = "00:05"
        }

The terraform apply was successful saying

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The Issue

However, when i plan and apply again, it is again saying the same things as if the previous changes were not performed.

Verification

I also looked into the TFState file and it shows the following even though the plan-apply steps said it changed backup_configuration.binary_log_enabled to false successfully

"backup_configuration": [
    {
        "binary_log_enabled": true,
        "enabled": false,
        "location": "",
        "start_time": "00:05"
    }
],
@ghost ghost added the bug label Apr 15, 2020
@venkykuberan venkykuberan self-assigned this Apr 15, 2020
@syedrakib
Copy link
Author

syedrakib commented Apr 15, 2020

When i tried changing "Enable point-in-time recovery" (of CloudSQL MySQL) from true to false using the GCP console, it showed a confirmation pop-up that CloudSQL requires a restart for the changes to take effect.

I don't think we are invoking that restart when we change settings.backup_configuration.binary_log_enabled from true to false via Terraform - the "Modifying..." state changes to "Modifications complete" almost immediately.

@syedrakib
Copy link
Author

syedrakib commented Apr 15, 2020

At the same time, when we do change settings.backup_configuration.binary_log_enabled from true to false using Terraform, and then we do a terraform refresh -target=resource, the state of the resource is not actually correctly refreshed - the refreshed value for settings.backup_configuration.binary_log_enabled still stays at true

@venkykuberan
Copy link
Contributor

@syedrakib if backup_configuration block is enabled then API sets the binary_log_enabled to true although you set it to false in your config. Terraform updates the state file based on the response from API. If you want binary_log_enabled to be false don't use that block in your config API sets it to false.

doc - https://www.terraform.io/docs/providers/google/r/sql_database_instance.html

binary_log_enabled - (Optional) True if binary logging is enabled. If settings.backup_configuration.enabled is false, this must be as well.

Let me know if i can close this issue if it fix your problem

@syedrakib
Copy link
Author

syedrakib commented Apr 15, 2020

I don't quite understand what is meant by "API sets the binary_log_enabled to true although you set it to false". I mean, defeats the purpose of having an argument for it then, right?

:/

@ghost ghost removed the waiting-response label Apr 15, 2020
@syedrakib
Copy link
Author

syedrakib commented Apr 15, 2020

According to the referred doc, if settings.backup_configuration.enabled is false then settings.backup_configuration.binary_log_enabled must also be false.

Here is what i have in my backup_configuration:

backup_configuration = {
  enabled            = false
  binary_log_enabled = false
  start_time         = "00:05"
}

That complies with the doc, right?

The expectation here is, backup will be disabled and binary_log will be disabled. Thus, it should set the value to false and the API response should return false. It should not return true.

@venkykuberan
Copy link
Contributor

venkykuberan commented Apr 15, 2020

When backup is disabled, binary_log should also be disabled, API accepts it. If backup is disabled and binary_log is enable API throws

Error: Error, failed to create instance test-sql6: googleapi: Error 400: Invalid request: Binary log must be disabled when backup is disabled.., invalid

The following state is invalid, i am not sure how apply command worked for you.

"backup_configuration": [
    {
        "binary_log_enabled": true,
        "enabled": false,
        "location": "",
        "start_time": "00:05"
    }
]

can you share your provider version ?

@syedrakib
Copy link
Author

Hi @venkykuberan . Thanks for the reply. Yes that's exactly the bug i guess how come it worked on the first place.

I am using these provider versions:

terraform {
  required_version = "0.12.24"
}

provider "google" {
  version = "3.13.0"
}

provider "google-beta" {
  version = "3.13.0"
}

@ghost ghost removed the waiting-response label Apr 16, 2020
@syedrakib
Copy link
Author

syedrakib commented Apr 16, 2020

Just now i have manually changed the value of backup_configuration . binary_log_enabled from true -> false inside the TFState file.

My main.tf file still says backup_configuration . binary_log_enabled = false

Then i tried terraform plan & terraform apply and the value of backup_configuration . binary_log_enabled inside the TFState file changed to true again.

I check the CloudSQL in GCP. Both the values for "Automated Backups" & "Enable point-in-time recovery" are both unchecked (false).

Why is terraform seeing it true then?

@venkykuberan
Copy link
Contributor

Just now i have manually changed the value of backup_configuration . binary_log_enabled from true -> false inside the TFState file.
Terraform state file shouldn't edited manually. The flow is

  • Change the desired state in config file (.tf)
  • run terraform plan => checks syntactical errors and run other internal funcs (No API call is made yet)
  • run terraform apply => API call is made and the request is success, terraform state file is updated with the API response.

Please follow the above steps, for what ever changes you want to make in config and verify your change is accepted.

@syedrakib
Copy link
Author

Ok. Ignore that. That was me just sharing that even when i explicitly change the value in the sate file myself, it reverts back to what it was.

@ghost ghost removed the waiting-response label Apr 17, 2020
@syedrakib
Copy link
Author

syedrakib commented Apr 17, 2020

The bottom-line of the problem is.....

in GCP CloudSQL MySQL instance:

  • the auto-backup feature is checked off
  • the point in time recover featue is checked off
  • which implies the binary_log feature is also turned off

Then why is it that the google_sql_database_instance resource is "refreshing" and then setting the value of settings.backup_configuration.binary_log_enabled in the tfstate file to "true"?

Mentioning the versions here again for reference:

Terraform v0.12.24
+ provider.google v3.13.0
+ provider.google-beta v3.13.0

@syedrakib
Copy link
Author

Hi... just following up on the issue with this one..... could we identify the bug with this?

@chrisst
Copy link
Contributor

chrisst commented Apr 21, 2020

Fix will be going out in 3.19.0

@ghost
Copy link

ghost commented May 22, 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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked and limited conversation to collaborators May 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.