[ISSUE-112] Add total_shards_per_node setting to allocate in ILM

[RobsonSutton]

• Fix small typo on variable name (housekeeping)
• Add total_shards_per_node setting (identified as missing: https://github.com/elastic/terraform-provider-elasticstack/issues/112)

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[RobsonSutton]

@Kushmaro / @olksdr - Hi both 👋 Please can you review and provide some feedback on this one when you get a chance?

P.S. New to Go so apologies if anything has been missed...!

[tobio]

jenkins test this

[tobio]

jenkins test this

[tobio]

@RobsonSutton the CI test suite is run against a range of ES versions (you can see the pipeline definition here).

I think we'll want to only define this property in the acceptance tests when they're being run against a supported ES version.

[RobsonSutton]

@tobio - Apologies for the delay! Yeah I didn't have time the other day to figure this one out but hopefully I should get some time later today to try figure out the best way to skip these for specific versions within the tests 👍

[tobio]

jenkins test this

[tobio]

jenkins test this

[othmane399]

Hello, did you need some help on this ?

[tobio]

@othmane399 definitely happy to get some help to get this one across the line.

Bit of a brain dump below, but totally happy if you wanted to take another approach.

I was trying to have the provider only specify total_shards_per_node when it's in module definition, but that's difficult to do without dropping into the raw config objects which I'd rather avoid.

I was going to instead validate the ES version the provider was running against and error out if the property is not supported and not the default.

[RobsonSutton]

@tobio - Apologies, have been a bit MIA recently with this one, i'll take another look at this but it may be a bit out of my comfort zone since I'm still picking up the basics currently!

[othmane399]

Hello @tobio, after thinking a bit on this, I think IMO testing pipelines should only run tests files that are version compatible with. In a draft, let's say as there's a major change on ILM since v7.16, we should have 2 test_ilm.go files, one like test_ilm_before_7.16 and another one test_ilm_after_7.16. and the run choose the corresponding test file related to the ES tested version. This approach will maybe duplicate testing code at some points but will facilitate the resolution of this kind of issues for all incoming features on this or another resources. I'm not a go expert so I cannot say If this is easy to implement or not, so this is just an idea :)