juju 2.1.2 assumes deep pockets with mem=7g on gce

[Kevin W Monroe]

$ juju version
2.1.2-xenial-amd64

$ juju deploy ubuntu --constraints mem=7G u1
$ juju deploy ubuntu --constraints "mem=7G cores=1" u2

Both u1 and u2 end up on a machine with 8g ram and 8 cores:

$ juju run --all 'grep proc /proc/cpuinfo'
- MachineId: "0"
  Stdout: "processor\t: 0\nprocessor\t: 1\nprocessor\t: 2\nprocessor\t: 3\nprocessor\t:
    4\nprocessor\t: 5\nprocessor\t: 6\nprocessor\t: 7\n"
- MachineId: "1"
  Stdout: "processor\t: 0\nprocessor\t: 1\nprocessor\t: 2\nprocessor\t: 3\nprocessor\t:
    4\nprocessor\t: 5\nprocessor\t: 6\nprocessor\t: 7\n"

It seems n1-highcpu-8 was selected as the instance type to satisfy the "mem=7g" constraint, regardless of the core constraint. This is expensive. I think juju should have selected the n1-standard-2 type instead.

[Robert C Jennings (rcj)]

Anastasia, with this issue ff you want 7g ram and juju selects n1-highcpu-8 that means a customer pays $145 a month just on the VM w/o storage whereas if it would select n1-standard-2 it would be only $49 a month. I would think this is higher than an medium priority.

[John A Meinel (jameinel)]

If you *really* want n1-standard-2 you can do "juju deploy --constraints instance-type=n1-standard-2"

Looking here: https://cloud.google.com/compute/docs/machine-types

I think the issue is that n1-highcpu-8 has 7.2GB of memory, which is 'less' than n1-standard-2's 7.5GB of memory.

When we have pricing information, we use that to sort between instance types that otherwise would fulfill the criteria. When we don't, I believe we use 'total memory' as the ultimate sorting criteria.

We should try to get pricing information from GCE. Is there an official location that they publish 'current' pricing that is appropriate for automated consumption?

[John A Meinel (jameinel)]

It would be possible to try and use some other metric, like N-CPU * Memory, or some sort of Weighted CPU cost + Memory Cost, etc, but all of them are likely to have weird failure modes if we aren't using real pricing info.

[Anastasia (anastasia-macmood)]

As there is a workaround of asking for specific instance type, I'll re-triage it back as Medium.

[Kevin W Monroe (kwmonroe)]

The stinker here is that our big data bundles use a least-common-denom for constraints across all clouds. This means mem and cores instead of instance-type. Here's where it hurts:

I set the mem constraint to 7g for Azure. If I go higher, my default instances on Azure will come with 14g ram and double the cost. If I don't go to at least mem=7.3 (if floats are even allowed), GCE will come up with a highcpu instance for the reason that jam noted in comment #2.

So i'm a huge +1 on some kind of weighted calculation to give me the cheapest instance given generic constraints. I agree this requires some reliable automated pricing info that juju can access across clouds.

[Kevin W Monroe (kwmonroe)]

This is getting really expensive. Any update on a smarter cost/constraint algorithm? This doesn't just affect "mem=7G" as initially reported. It also affects plain 'ol bootstrap.

By default, bootstrapping a GCE instance puts the controller on an n1-highcpu-4. It's the same reason as mentioned in comment #2 -- the 'highcpu' instances have lower mem (3.6GB) than 'standard' instances (3.75GB). I'm now paying 3x more for a GCE controller ($0.14/hr vs $0.047/hr).

That's $100/mo for the controller. If we are not close to fixing this, I think we should at least warn users in the docs that they should specify a bootstrap constraint to force this on a 'n1-standard-1'.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.