Comment 8 for bug 1567169

The rough plan here is to allow a bundle to define placement in terms of logical machine names. This is the same concept as logical network space names (ie want all of these endpoints bound to the same logical group of subnets etc). But what's in the bundle for machine and space names are logical names, whatever makes sense to think about for the bundle. eg there could be a machine inside the bundle called "dbserver". And you cloud use a placement directive to deploy a charm --to dbserver or even --to lxd:dbserver.

At deploy time, you'd use a separate mapping to map the logical names in the bundle to physical machines. So you'd get to do the special setup on Juju machine 3 because that's going to be the dbserver, and then you'd deploy the bundle (warning, not official syntax, just for illustration):

$ juju deploy mybundle.yaml --machines dbserver=3,appserver=4 --spaces public=default

This approach keeps the bundles nice and reusable and provides the flexibility to deploy according to specific requirements. It's a similar approach to what we use for charm storage - eg the charm defines logically that it wants a file system for "logs", and at deploy time you use the --storage directive to map that to a physical storage instance on the machine or cloud.