Changing deployment_template_id for Elastic instances Failing via code

[HMarvellNW]

Readiness Checklist

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed
• I am reporting the issue to the correct repository (for multi-repository projects)

Expected Behavior

The expected behaviour of changes via terraform should allow our deployments to change/upgrade deployment template versions without any manual intervention within EC.

Current Behavior

We are currently experiencing issues with template upgrades via code within the Hot-warm deployment template family (Hot-warm-v2 to Hot-warm-v4), our main issue is seen when version bumping from v2 to a later version of the template. Errors that we see are within the terraform apply step, calling api errors as the issue, please see screenshot. Our current work around for this is to manually change the deployment template within the EC and then we are able update our infrastructure as code to match these changes.

This is created when the following message is available within EC.

This error doesn't appear to present when changing from CPU-optimized-arm-v5 and the hot-warm templates, only within the hot-warm deployment templates.

## Terraform definition

resource "ec_deployment" "deployment" {
  name                   = lower(var.cluster_name)
  region                 = "aws-eu-west-2"
  version                = var.es_version
  deployment_template_id = var.deployment_template_id

Steps to Reproduce

1. Have cluster running hot-warm-v2 as code, with hot-warm-v2 hardware profile within elastic,
2. Upgrade hot-warm-v2 to hot-warm-v4 via code, without changes to the EC hardware profile,
3. Error should produce within terraform apply.

Context

The context of this issue is that we are currently trying to upgrade our deployment templates to the latest version to maintain parity across our deployments.

Your Environment

• Version used: Elastic/ec v0.3.0
• Running against Elastic Cloud SaaS or Elastic Cloud Enterprise and version: Elastic Cloud SaaS

[tobio]

@HMarvellNW we've made a bunch of changes to how this scenario is handled in more recent provider versions. Are you able to test this against 0.5.0 (there was a regression here in 0.6.0 which should be fixed in the next version, and using 0.5 shouldn't require any changes to your TF code)?

[RobsonSutton]

Hey @tobio - Quick question on this one: We have a large number of clusters here and I'm conscious there is the TypeMap issue on topologies on these versions that's fixed in 0.6.0 (#336). Do you think the zero size workaround (#472) will attempt to reorder our topology elements by adding the empty defaults (since we are currently only defining a subset of those we need), and potentially throw errors by trying to change node types / hardware profiles about?

If not then brill! I'm just conscious of having to unpick things manually since our number of clusters is currently around the 100 mark...

[tobio]

Do you think the zero size workaround (#472) will attempt to reorder our topology elements by adding the empty defaults

Without specifics, yea it probably will sorry. It sounds like you're facing two issues:

• Version 0.5 or lower of this provider has issues dealing with changing topology elements.
• 0.6 (also 0.4 or lower) has a bug where changes to deployment_template_id aren't handled nicely.

Just so it's clear, the change in #472 only impacts deployments with autoscaling enabled. Any deployments working with 0.3, where autoscaling is not enabled should be expected to continue to work without change in 0.5. Deployments with autoscaling enabled, would require zero sized topology elements where autoscaling_max > 0 to be added into the Terraform module. Whilst that's painful, IIRC it's not impacted by #336, i.e as long as those elements are present in alphabetical order then things continue to work.

But, I understand migrating a large number of deployments for 0.5 and then 0.7 is pretty horrible. I'll follow up on the remaining 0.7 tasks and see if we can get 0.7 out which fixes both this bug and the topology ordering issue so there's only a single migration.

[RobsonSutton]

Yeah all of our clusters have autoscaling configured currently so would need updating unfortunately. Yeah our current code will just generate a list containing the minimum elements unfortunately, so elements like zero sized cold nodes (alphabetically preceding existing nodes) would reorder things like hot-warm configs as it'll update the order 😢

@HMarvellNW - Sounds like we have 3 main options really then:

• Wait for 0.7.0 then update deployment templates via code (easiest)
• Migrate deployment template manually for each cluster and match up the code retrospectively (more laborious)
• Update codebase with zero sized elements (topology workaround), and as mentioned migrate to 0.5.0 to apply deployment template changes via code and then migrate to 0.7.0 containing the topology fix (as mentioned, pretty horrible!)

Thanks for helping advise on this one as always @tobio, very much appreciated! 👍

[tobio]

@RobsonSutton we were discussing the timelines here. I'll get a 0.7 version released sometime this week to close off this issue.