Deployment of subordinate charms needs manual locking

Bug #1068624 reported by Liam Young
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
juju-core
High
Tim Penhey
pyjuju
High
Unassigned

Bug Description

Subordinate charm hooks need the charmer to write locking code because their hooks can end up firing concurrently with other hooks on a unit. I hit this recently when a hook failed due to it failing to get a lock on /var/lib/dpkg/lock during an apt install.

I think juju should ensure that hooks don't fire simultaneously on the same unit

Revision history for this message
Robert Ayres (robert-ayres) wrote :

Just discussing this with Liam on #juju, I guess there's a balance between parallel deployment and guaranteed safety between charms and subordinates. A middle ground could be allowing charm authors to specify a single metadata string under the name 'Conflicts', which if matched between two deploying charms ensures one runs after the other (otherwise we still get parallel deployment).

Haw Loeung (hloeung)
tags: added: canonical-webops-juju
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

There is heavy discussion about this in the development of the go port. The thought is that any one container should only have one hook executor, even with multiple unit agents, so as to keep charms simple.

Changed in juju:
status: New → Triaged
status: Triaged → Confirmed
importance: Undecided → High
Martin Packman (gz)
Changed in juju-core:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
William Reade (fwereade) wrote :

I am personally +1 on the single-hook-executor idea, but I'm not sure that consensus actually leans in that direction.

Revision history for this message
Kapil Thangavelu (hazmat) wrote :

fixed via serialized execution of hooks within a machine/container between primary and subordinate using a file lock (resistant to process death, etc)

Changed in juju:
status: Confirmed → Fix Released
milestone: none → 0.7
Revision history for this message
William Reade (fwereade) wrote :

Fixed by thumper shortly before 1.10 release in juju-core

Changed in juju-core:
assignee: nobody → Tim Penhey (thumper)
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers