juju doesn't honor bundle application constraints (2.1.2)

[Kevin W Monroe]

I've created a simple bundle with application constraints. However, post deployment, I see that the created machines are not honoring those constraints (they have 1.7g ram instead of the requested 3). This is happening on at least AWS and GCE:

$ juju version
2.1.2-xenial-amd64

$ cat test.yaml
services:
  u10:
    charm: cs:xenial/ubuntu
    constraints: "mem=3G"
    num_units: 1
    to:
      - 0
  u20:
    charm: cs:xenial/ubuntu
    constraints: "mem=3G root-disk=16G"
    num_units: 1
    to:
      - 1
machines:
  "0":
    series: "xenial"
  "1":
    series: "xenial"

$ juju deploy --debug test.yaml
17:55:45 INFO juju.cmd supercommand.go:63 running juju [2.1.2 gc go1.6.2]
17:55:45 DEBUG juju.cmd supercommand.go:64 args: []string{"juju", "deploy", "--debug", "test.yaml"}
17:55:45 INFO juju.juju api.go:72 connecting to API addresses: [104.198.111.212:17070 10.138.0.2:17070]
17:55:45 DEBUG juju.api apiclient.go:590 dialing "wss://104.198.111.212:17070/model/28d9b555-a880-4989-817b-cd322c438052/api"
17:55:45 DEBUG juju.api apiclient.go:590 dialing "wss://10.138.0.2:17070/model/28d9b555-a880-4989-817b-cd322c438052/api"
17:55:45 DEBUG juju.api apiclient.go:593 successfully dialed "wss://104.198.111.212:17070/model/28d9b555-a880-4989-817b-cd322c438052/api"
17:55:45 INFO juju.api apiclient.go:521 connection established to "wss://104.198.111.212:17070/model/28d9b555-a880-4989-817b-cd322c438052/api"
17:55:45 DEBUG juju.juju api.go:263 API hostnames unchanged - not resolving
17:55:46 DEBUG httpbakery client.go:244 client do GET https://api.jujucharms.com/charmstore/v5/xenial/ubuntu/meta/any?include=id&include=supported-series&include=published {
17:55:46 DEBUG httpbakery client.go:246 } -> error <nil>
17:55:47 DEBUG juju.cmd.juju.application bundle.go:281 added charm cs:ubuntu-10
17:55:47 INFO juju.cmd.juju.application series_selector.go:101 with the series "xenial" defined by the bundle
17:55:47 DEBUG juju.cmd.juju.application bundle.go:372 application u10 is deploying (charm cs:ubuntu-10)
17:55:47 INFO cmd cmd.go:129 Deploying charm "cs:ubuntu-10"
17:55:48 INFO juju.cmd.juju.application series_selector.go:101 with the series "xenial" defined by the bundle
17:55:48 DEBUG juju.cmd.juju.application bundle.go:372 application u20 is deploying (charm cs:ubuntu-10)
17:55:48 INFO cmd cmd.go:129 Deploying charm "cs:ubuntu-10"
17:55:48 DEBUG juju.cmd.juju.application bundle.go:497 created new machine 0 for holding u10 unit
17:55:48 DEBUG juju.cmd.juju.application bundle.go:497 created new machine 1 for holding u20 unit
17:55:48 DEBUG juju.cmd.juju.application bundle.go:572 added u10/0 unit to new machine
17:55:48 DEBUG juju.cmd.juju.application bundle.go:572 added u20/0 unit to new machine
17:55:49 INFO cmd cmd.go:129 Deploy of bundle completed.
17:55:49 DEBUG juju.api monitor.go:35 RPC connection died
17:55:49 INFO cmd supercommand.go:465 command finished

$ juju run --all 'free -h && df -h | grep sda'
- MachineId: "0"
  Stdout: |2
                  total used free shared buff/cache available
    Mem: 1.7G 125M 664M 2.8M 906M 1.4G
    Swap: 0B 0B 0B
    /dev/sda1 9.7G 1.6G 8.1G 17% /
- MachineId: "1"
  Stdout: |2
                  total used free shared buff/cache available
    Mem: 1.7G 119M 666M 2.8M 910M 1.4G
    Swap: 0B 0B 0B
    /dev/sda1 9.7G 1.6G 8.1G 17% /

[Kevin W Monroe (kwmonroe)]

I've updated my test.yaml to include machine constraints (note the app requests 7G, the machine specifies 3G). I get machines with 3G. So it seems like "machine" constraints are cool; app constraints not so much:

$ cat test.yaml
services:
  u10:
    charm: cs:xenial/ubuntu
    constraints: "mem=7G"
    num_units: 1
    to:
      - 0
  u20:
    charm: cs:xenial/ubuntu
    constraints: "mem=7G root-disk=16G"
    num_units: 1
    to:
      - 1
machines:
  "0":
    series: "xenial"
    constraints: "mem=3G"
  "1":
    series: "xenial"
    constraints: "mem=3G root-disk=32G"

$ juju run --all 'free -h && df -h | grep sda'
- MachineId: "0"
  Stdout: |2
                  total used free shared buff/cache available
    Mem: 3.5G 179M 2.4G 5.0M 913M 3.0G
    Swap: 0B 0B 0B
    /dev/sda1 9.7G 1.6G 8.1G 17% /
- MachineId: "1"
  Stdout: |2
                  total used free shared buff/cache available
    Mem: 3.5G 203M 2.4G 5.0M 885M 3.0G
    Swap: 0B 0B 0B
    /dev/sda1 31G 1.6G 30G 5% /

[Anastasia (anastasia-macmood)]

Indeed, from your observations, when machine constraints are specified, we try to add a machine to match. When application constraints are specified, I *think* that we add a machine first, potentially not taking constraints into consideration, and then try to deploy applications to it.

The workaround while we address this would be to specify your desired constraints in the machine specification section of bundle.

[Tim Penhey (thumper)]

This is probably more of a documentation issue. The machines are added before any units are assigned to them. Machine constraints are used to determine what type of machine are created. Constraints attached to an application will impact any "new" machines created to deploy units on, but not machines that are defined in the bundle.

If your bundle was like this:

services:
  u10:
    charm: cs:xenial/ubuntu
    constraints: "mem=3G"
    num_units: 1
  u20:
    charm: cs:xenial/ubuntu
    constraints: "mem=3G root-disk=16G"
    num_units: 1

You would find that the machines created should have the constraints specified.