Let's say you have a bundle:
base:
charm: cs:ubuntu
to:
- 0
- 1
foo:
charm: cs:ubuntu
to:
- lxd:0
- lxd:1
bar:
charm: cs:ubuntu
to:
- foo/0
- foo/1
You'd result in a model that had "base" on metals 1 and 2, and foo and bar smooshed into 0/lxd/0 and 1/lxd/0 together.
Now imagine you juju remove-application foo and then re-deploy, you actually end up with foo creating 0/lxd/1 and 1/lxd/1. That's somewhat expected and as advertised, but not the intention of the bundle author.
now remove both applications foo and bar, leaving base.
re-deployment of this bundle with --map-machines=existing gives you "base" on 0 and 1, "bar" smooshed onto 0 and 1 with "base", and "foo" is on 0/lxd/2 (as foo/3) and 1/lxd/2 (as foo/4) all on it's lonesome.
So, is the failure of the second to put memcached into containers with foo/3 and foo/4 because the placement directive is pointing at foo/0 and foo/1 as specific unit numbers and not the "honorary" units 0 and 1 in the "list of available foo units"?
juju version 2.4.7-bionic-amd64