placement initiatives for hulk-smash with specific unit offsets not working

[Drew Freiberger]

I have a deployer.yaml config that looks like:

placements:
  services:
    ceph-mon:
      to:
      - lxd:storage=1
      - lxd:storage=2
      - lxd:storage=3

services:
  inherits:
  - placements
  services:
    ceph-mon:
      charm: ceph-mon
      num_units: 3
      bindings:
        "": oam-space
        public: ceph-public-space
      options:
        expected-osd-count: 84
        monitor-count: 3
        source: distro
        customize-failure-domain: True

I receive the error:

2017-04-20 19:46:15 [ERROR] deployer.deploy: Invalid application placement ceph-mon to lxd:storage=1
2017-04-20 19:46:15 [ERROR] deployer.deploy: Invalid application placement ceph-mon to lxd:storage=2
2017-04-20 19:46:15 [ERROR] deployer.deploy: Invalid application placement ceph-mon to lxd:storage=3

My environment has the following units already deployed as ubuntu charms:

Unit
compute/0
compute/1*
compute/2
compute/3
compute/6
compute/8
compute/10
compute/11
compute/13
compute/14
compute/15
compute/21
compute/24
compute/26
gateway/0*
gateway/1
gateway/2
infra/1*
storage/3*
storage/5
storage/6
storage/7
storage/8

I'm using juju-deployer from within mojo, and it's the juju-deployer shipping with mojo 0.4.5 from the mojo-maintainers ppa.

This same error exhibits whether I use lxd:storage=1 or lxd:compute=0 or compute=0 or storage=0 formats. I can't target specifically deployed units as demonstrated in seranade: to: lxc:wordpress=2 in docs here: https://pythonhosted.org/juju-deployer/config.html#placement

juju-deployer 0.10.0~bzr208~60~ubuntu17.04.1~bzr210~61~ubuntu16.04.1
juju version
2.0.2-xenial-amd64
mojo --version
0.4.5

[Drew Freiberger (afreiberger)]

Workaround for now is that I have to convert lxd:storage=0 to lxd:X where X is the machine number where storage/3 (zero'eth storage unit) resides.

[Drew Freiberger (afreiberger)]

It appears that defining "services:" as a top-level bundle definition name ends up overriding the juju model services when running through yaml definition validate tests. It also changes yaml version parsing from V3 to V4 code.

Found that changing services: top level bundle header to openstack-services: resolved the placements issue and used the standard V3 bundle parser class.

it's not "invalid yaml" so it wouldn't get picked up by lint routines, but it should be caught as a different type of exception in juju-deployer as it is a very misleading error.

Perhaps searching for "services:" (or other reserved words like overrides: or version:) at top level in any conf files (not just the first -c conf.yaml file) should be called out as an error.