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:
* https://issues.apache.org/jira/browse/BROOKLYN-582
* https://issues.apache.org/jira/browse/JCLOUDS-1379
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.
Aled
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.
[1]
https://brooklyn.apache.org/v/latest/locations/index.html#common-configuration-options
Best
Duncan
On Sat, Jun 30, 2018 at 7:09 PM, Duncan Johnston-Watt <
dun...@blockchaintp.com> 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?
Best
--
Duncan Johnston-Watt
CEO, Blockchain Technology Partners <http://blockchaintp.com/>
Twitter: @duncanjw <https://twitter.com/duncanjw>
Mob: +44 777 190 2653 <+44%207771%20902653>
LinkedIn: https://linkedin.com/in/duncanjohnstonwatt
