container scoped relations between 2 subordinates broken in 1.20.12

Bug #1396625 reported by Simon Davy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core
Fix Released
High
Menno Finlay-Smits
1.20
Fix Released
Critical
Menno Finlay-Smits
1.21
Fix Released
Critical
Menno Finlay-Smits

Bug Description

The fix for https://bugs.launchpad.net/juju-core/+bug/1382751 was backported to 1.20.12, but it breaks a use case, I think unintentionally.

The use case is relating 2 subordinates together in scoped relation.

The specific use case we have is a subordinate charm (https://jujucharms.com/u/ubuntuone-hackers/conn-check/trusty/18) that has a relation to the nrpe-external-master subordinate charm via it's usual scoped relation. The conn-check nrpe-external-master relation is also scoped: containter, as it makes sense intuitively that way (to me, anyway).

We've beeing using this successfully on 1.18 and 1.20 for a while now.

#juju conversation with Kapil:

<bloodearnest> https://bugs.launchpad.net/juju-core/+bug/1382751
<mup> Bug #1382751: non subordinate container scoped relations broken <regression> <relations> <subordinate> <juju-core:Fix Committed by menno.smits> <juju-core 1.20:Fix Released by menno.smits> <juju-core 1.21:Fix Released by natefinch> <https://launchpad.net/bugs/1382751>
<bloodearnest> so, this is a breaking change
<bloodearnest> in a point release
<hazmat> bloodearnest, ugh
<hazmat> that looks like unintended fallout
<bloodearnest> seems so
<bloodearnest> relating 2 subordinates has been supported for ages, I've been using for a good while
<hazmat> bloodearnest, is it a container scoped relation between the two subordinates?
<bloodearnest> hazmat: yes
<bloodearnest> hmm, I guess one side could be non-scoped, since the placement has already been done by the scoped relation
<hazmat> bloodearnest, it looks like this line + if eps[0].Scope == charm.ScopeContainer && subordinateCount != 1 {
<hazmat> should be subordinateCount >= 1
<hazmat> bloodearnest, is this with public charms, i think its a worth a bug report
<bloodearnest> hazmat: public charm, but not yet promulgated. It's the charm for the new conn-check utility we announce recently, related to nrpe-external-master to surface the checks as nagios results
<bloodearnest> I will file a report

Kapil suggests this line should be >=1, not != 1:

https://github.com/juju/juju/pull/1075/files#diff-f6be34387a141f652301c16cf7a5e36cR1569

Revision history for this message
Kapil Thangavelu (hazmat) wrote :
tags: added: regression
Revision history for this message
Curtis Hovey (sinzui) wrote :

Can this be tested in juju 1.21-beta3?

Changed in juju-core:
status: New → Triaged
importance: Undecided → High
tags: added: subordinate
Changed in juju-core:
milestone: none → 1.22
Curtis Hovey (sinzui)
Changed in juju-core:
importance: High → Critical
Changed in juju-core:
assignee: nobody → Menno Smits (menno.smits)
status: Triaged → In Progress
Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

There have been various conversations between Will, Simon and me. Bascially, Juju was never supposed to support container scoped relations between subordinates but it was unintentionally allowed and it turns out that people are relying on this functionality (hence this ticket).

I will make the change as suggested by Kapil and get that merged to unblock CI but will then follow up with another (lower priority) ticket to cover looking for potential fallout of allowing subordinates to relate this way. It is possible that there's parts of Juju that will behave badly in some cases when such relations exist.

Changed in juju-core:
status: In Progress → Fix Committed
Curtis Hovey (sinzui)
Changed in juju-core:
importance: Critical → High
Curtis Hovey (sinzui)
Changed in juju-core:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.