Disallow deploying multiple units to the same container by default

Bug #1536480 reported by Stuart Bishop on 2016-01-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
High
Unassigned

Bug Description

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) wrote :

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

Changed in juju-core:
status: New → Triaged
importance: Undecided → Wishlist
milestone: none → 2.0-beta1
Curtis Hovey (sinzui) on 2016-02-19
Changed in juju-core:
milestone: 2.0-beta1 → 2.0-beta2
Curtis Hovey (sinzui) on 2016-03-10
Changed in juju-core:
importance: Wishlist → High
Curtis Hovey (sinzui) on 2016-03-10
Changed in juju-core:
milestone: 2.0-beta2 → 2.0-beta3
Curtis Hovey (sinzui) on 2016-03-25
Changed in juju-core:
milestone: 2.0-beta3 → 2.0-beta4
Cheryl Jennings (cherylj) wrote :

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.

Changed in juju-core:
milestone: 2.0-beta4 → 2.1.0
affects: juju-core → juju
Changed in juju:
milestone: 2.1.0 → none
milestone: none → 2.1.0
Anastasia (anastasia-macmood) wrote :

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

Changed in juju:
milestone: 2.1.0 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers