search

oscarhermoso / terraform-provider-binarylane

This is a Terraform provider for Binary Lane, for reliable & affordable Australian VPS hosting
https://registry.terraform.io/providers/oscarhermoso/binarylane/latest
MIT License
9 stars 0 forks source link

💹 Support updates for specific server resource properties #37

Open oscarhermoso opened 2 weeks ago

oscarhermoso commented 2 weeks ago

Ideally if server properties are changed, it can be done without disruption the the server, or at a minimum using the Rebuild action instead of relying on Terraform to recreate the server (which changes IP address, etc).

The unchecked boxes have work remaining.

oscarhermoso commented 1 week ago

From brendancosmanmammoth

Resize destructive things:

NB: This is a draft document, not an official BinaryLane knowledgebase article. It is intended for discussion and > feedback.

If you see something that isn't listed here that looks like it is destructive, it probably is. Let Brendan know.

"Destructive" meaning "cannot be reversed". If you change the server size so that it doesn't have enough memory to > boot you are going to have a bad time, but you can reverse it. Resize shouldn't let you reduce the disk space to > less than your currently used disk space etc.

We've done our best to be helpful, so if you submit a null as part of the resize we'll keep the server's current > options, which should always be non destructive.

Change OS:

  • How: submit change_image with a non-null valid image ID or slug.
  • Chance of accidentally occuring: extremely low, there is no need to submit this unless this is an intentional OS > change, which itself is a very rare thing. Most customers will simply cancel the server and create a new one, and > hopefully this is clearly dangerous enough that much double checking that the correct server is being changed before > the action is submitted.
  • Impact: Complete data loss, but can be restored from backup, including the temporary backup that should be made > before the resize using the pre_action_backup option.

Remove assigned IP addresses:

  • How: submit options with an ipv4_addresses value that is lower than the current value AND list the addresses to > remove in ipv4_addresses_to_remove.
  • Chance of accidentally occuring: extremely low, as ipv4_addresses_to_remove being mandatory is intended to be a > confirmation mechanism.
  • Impact: Assuming you aren't hard coding IP addresses directly this will be annoying until DNS updates.

Remove existing backups (including offsite if we are 'managing' the bucket)

  • How: submit options with a non null daily_backups, weekly_backups or monthly_backups option that is lower > than the current value.
  • Chance of accidentally occuring: low, there is no need to submit those values unless they are intentionally changing.
  • Impact: If you need a backup that you no longer have it could have a large impact, but that's hopefully a low > probability event even if you did remove it.

Change Licences:

  • How: sumbit change_licenses with a non null value (including an empty value)
  • Chance of accidentally occuring: low, there is no need to submit this unless this is an intentional change.
  • Impact: None? I'm not aware of any non-reversable impact of removing any licences, but I'm not 100% certain, so > including it here since technically the licence removal can't be reversed, only a replacement licence will be > obtained.

Pre Action Backup:

  • How: submit pre_action_backup with a non null value that overwrites a backup intended to be kept. You also need to > specify replacement_strategy.
  • Chance of accidentally occuring: extremely low, we provide the temporary backup slot for this reason.
  • Impact: If you need a backup that you no longer have it could have a large impact, but that's hopefully a low > probability event even if you did remove it.