Automatic deployment sizing conversion in kbn-alert-load tool

[mikecote]

When building the kbn-alert-load tool, we've continuously had to change the RAM options when changing Cloud environments (see here). It would be nice to have this automated.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

I started looking into how to do this, so this is from memory.

One of listStacks() or listTemplates() can be used to list all the available options that can be used when generating the json we send to create the deployment, including available RAM sizes. The createDeployment() function first passes the args you want to ecctl deployment create with the --generatePayload option, which will return the complete json payload given the args provided - it doesn't actually create the deployment, it's more like --dry-run (show me what you would do).

Those functions are here: https://github.com/pmuellr/kbn-alert-load/blob/main/lib/ec-commands.js

So, my thinking was:

• get the list of templates (or stacks or whatever)
• do the createDeployment() as we currently do, where we generate the payload for it
• figure out which stack/template it selected
• look up that stack/template in the list we got from step 1, to figure out what RAM sizes it supports
• calculate the "closest" RAM support to the size of RAM requested, and override that in the payload that createDeployment() builds

The RAM sizes seem to diverge at 15/16GB - I think I've only seen two unique patterns:

• 16GB / 32GB / 64GB
• 15GB / 31GB / 58GB

For that case, we'd want to have 64GB as the deployment ram setting for the tool, but it would end up using the 58GB value when the deployment is actually created.

[mikecote]

@EricDavisX have you experienced issues communicating to Cloud APIs the deployment sizes when running tests? Trying to see if this issue is still relevant or not.

[EricDavisX]

I have not seen it. @mikecote
That may be because we don't try many different configurations (sizes). ...In the baseline test we setup and which is run in the MLR QA Jenkins, we have a fairly modest stack setup and it isn't changing. The Jenkins job is the only consume that the QA group uses of kbn-alert-load (we don't do much ad-hoc manual setup of tests). I might guess it was still a problem, but I question if we want to spend time as it isn't bugging us currently.

[mikecote]

@EricDavisX fair enough, thanks! I will close the issue for now.