Any plans for TF to support AWS RDS' point-in-time-restore functionality?

[shorn....@gmail.com]

TF recently added the aws_db_instance.snapshot_identifier argument, so now TF supports the ability create RDS instances from a snapshot.

Are there any plans to enable TF to support AWS' point-in-time-restore functionality?

As I understand it, if we mess up and need to do a PITR - then we'll have to manage our RDS instance by hand from then on, because TF can't start managing a resource that it didn't create in the first place, right?

It's really not that big a deal, just wondering if there were any plans.

[Paul Hinze]

If AWS has APIs for it, we have plans to support it!

Looks like the relevant action here is:

https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html

It'd be a little tricky to model declaratively. I suppose we could add an attribute like:

resource "aws_db_instance" "foo" {

  # ...

  restore_from_point_in_time = {{ timestamp or "latest_restorable" }}

}

Then if Terraform detects a change in that attribute it runs the above API action.

> As I understand it, if we mess up and need to do a PITR - then we'll have to manage our RDS instance by hand from then on, because TF can't start managing a resource that it didn't create in the first place, right?

If TF was already managing the instance and you do a PITR manually, I believe it should be fine to continue to manage that instance. PITR does not create a new instance does it?

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/b4e9c712-53c8-4492-807f-f4054d790294%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[shorn....@gmail.com]

If TF was already managing the instance and you do a PITR manually, I believe it should be fine to continue to manage that instance. PITR does not create a new instance does it?

Near as I can tell, point-in-time-restore works just like restore-from-snapshot - when I did them manually using the console, they both resulted in whole new RDS instances.  

I was a bit disappointed with that at first.  But I actually access RDS with a route53 domain name managed by TF, so this way it means I can do any verification of the new instance, then just swap the domain name using TF.  Minimal downtime and maximum flexibility that way and no rush to get the DB swapped over, so that's nice.

Documentation side-note:

Both mechanisms reset the RDS instance's security and parameter groups; restore-from-snapshot done from TF also ignores it (I guess AWS are ignoring it at the API level too).   It might be worth noting in the TF snapshot_identifier argument documentation that the user will need to "double apply" in order to get their parameter group and security group set properly (TF works fine the second time, I'm assuming it's just AWS ignoring the API values you're sending).  Might also be worth noting the second apply will put your RDS instance in "reboot needed" state too (although, at that point, you're actually documenting AWS behaviour rather than anything related to TF, might not wanna do that).

[Pavan K]

Hi Paul: I opened a feature request for point in time support for aws rds instance here https://github.com/terraform-providers/terraform-provider-aws/issues/5286

Do you have any update on this? From your comments below looks like you have a suggestion on how to support this. I am open to helping (though just started on the Go path myself).

-Pavan