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

Bug #1685043 reported by Drew Freiberger
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-deployer
New
Undecided
Unassigned

Bug Description

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

Revision history for this message
Drew Freiberger (afreiberger) wrote :

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.

tags: added: bootstack
tags: added: canonical-bootstack
removed: bootstack
Revision history for this message
Drew Freiberger (afreiberger) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.