Deployment of subordinate charms needs manual locking

[Liam Young]

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

[Robert Ayres (robert-ayres)]

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).

[Clint Byrum (clint-fewbar)]

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.

[William Reade (fwereade)]

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

[Kapil Thangavelu (hazmat)]

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

[William Reade (fwereade)]

Fixed by thumper shortly before 1.10 release in juju-core