Comment 4 for bug 1567169

I disagree with the logic which originally wont-fixed this bug.

Disallowing a procedure on the basis that it might not be directly applicable to all piles of metal is invalid in my opinion.

Disallowing the use of a bundle on the basis that it might actually be specific to a particular pile of metal, is also invalid in my opinion.

I can see where one might apply that filter logic to curated bundles in the charm store, but Juju as a tool should not prevent it.

Bundles, in all of Juju history prior to Juju native deploy, have done this quite well.

With juju-deployer, we can take a pre-existing set of machines, lay a bundle on top, with applications mapped to specific machines, and it just works.

Later, we can update that bundle and re-apply (redeploy) it on top of the existing model, and it just works, applying any changed configuration, and deploying any new applications or units, whether placed on new or existing machines, whether in containers or not.

Until juju native deploy accommodates this and similarly well-established use cases, the juju-deployer tool will likely be a thing.

### One use case:
Deploy a complex set of applications (OpenStack), using a bundle, against numerous manual-provider machines (s390x LPARs).