Disallow deploying multiple units to the same container by default

[Stuart Bishop]

Juju does exactly what you ask when you 'juju deploy --to=20 foo'. If there is already a charm deployed in machine #20, in most cases both units will fail horribly. Sometimes charms are known to work in the same container, and this is the rare case.

I think 'juju deploy' should fail if you attempt to deploy to a container already in use, unless you provide a --force argument. This will protect people deploying a large number of manually provisioned units. Like me, who just narrowly avoided disaster.

[Cheryl Jennings (cherylj)]

I will add this to the list of things we are tracking that would break current behavior that we should consider for 2.0.

[Cheryl Jennings (cherylj)]

Discussions today led to the suggestion that we can issue an warning if deploying to a machine already containing a service which users can bypass by specifying -y.

Will need to be targeted to a later release.

[Anastasia (anastasia-macmood)]

Removing 2.1 milestone as we will not be addressing this issue in 2.1.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.