[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coercing instance types

Hi Duncan,

Agree, this can be an issue for folk not specifying the explicit instance type - either it not working in newer regions, or it choosing a sub-optimal instance type.

It is tracked in:


Unfortunately it's not as simple as updating globally. Different regions support different instance types. Also, the closest match for minRam and minCores will be different in different regions, and will sometimes be an older instance type (e.g. there is no `m4.medium`, to replace the `m3.medium` - and the `t2` instances have different behaviour with their CPU credits).

Also, the algorithm for minRam / minCores makes it hard to choose the most price-effective instance. For example, m5.large has more CPU than m4.large, but is also cheaper. The metadata in jclouds doesn't take this into account.

But saying that, there may be some quick wins to make mismatches much less likely. And a way to improve jclouds so that the valid instances per region could be supplied/retrieved.


On 30/06/2018 19:16, Duncan Johnston-Watt wrote:
Apologies - context is AWS where it would be good to avoid matching
requirements to hardwareId[1] not available in a given region.




On Sat, Jun 30, 2018 at 7:09 PM, Duncan Johnston-Watt <
duncan@xxxxxxxxxxxxxxxx> wrote:

I appreciate that this is probably a jclouds question but the m3.xxxx
defaults don't work in London or Paris. Is it worth updating this globally?

Duncan Johnston-Watt
CEO, Blockchain Technology Partners <>

Twitter: @duncanjw <>
Mob: +44 777 190 2653 <+44%207771%20902653>