non subordinate container scoped relations broken

Bug #1382751 reported by Kapil Thangavelu
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core
Fix Released
High
Menno Finlay-Smits
1.20
Fix Released
High
Menno Finlay-Smits
1.21
Fix Released
High
Nate Finch

Bug Description

on 1.21, i was trying out container scoped relations for non subordinate relations, it appears they are broken and trigger an infinite restart in the unit agent. i have a few use cases for these fwiw (units on the same host communicating to coordinate).

Curtis Hovey (sinzui)
Changed in juju-core:
status: New → Triaged
importance: Undecided → High
milestone: none → 1.21-alpha2
tags: added: relations subordinate
Curtis Hovey (sinzui)
tags: added: regression
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.21-alpha2 → 1.21-alpha3
Revision history for this message
Kapil Thangavelu (hazmat) wrote :

i was able to workaround in charm land, my only paying attention to the units with the same private ip address.

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

the bigger issue is just that this effectively sticks the uniter into an endless restart loop, so should be disallowed if its not supported.

Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.21-alpha3 → 1.21-beta1
Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

This could be related to the recent env UUID migrations for the relations or relationscopes collections so I'm going to investigate.

Kapil: do you have a minimal way to reproduce the problem?

Changed in juju-core:
assignee: nobody → Menno Smits (menno.smits)
Changed in juju-core:
status: Triaged → In Progress
Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

I've been looking at this today.

The problem isn't specific to 1.21. I can reproduce it on 1.20.11 and even 1.19.4. It looks like non-subordinate-charm container relations have been broken for some time.

no longer affects: juju-core/1.21
Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :
Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

To reproduce:

juju bootstrap
juju deploy --repository ~/path/to/repo local:container-scoped-relations-provider
juju deploy --repository ~/path/to/repo local:container-scoped-relations-requirer --to 1
juju add-relation juju add-relation container-scoped-relations-provider container-scoped-relations-requirer

At this point both the provider and requirer uniters continually die and restart, reporting "ModeAbide: service is not a subordinate".

As far as I can tell, when EnterScope() is called as the relation is joined, subordinateOps() decides to create a subordinate unit, which doesn't seem like the right thing to do in this case.

I'm a little unsure of the desired behaviour here. I'll try to catch Will later on.

Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

I've talked to Will and apparently it shouldn't be possible (and doesn't really make sense) to have container scoped relations where neither endpoint is a subordinate service. The fix is to add an extra check to State.AddRelation(). State.InferEndpoints() also needs to be tweaked to ensure it doesn't suggest inappropriate relations.

I'm working on this now.

Changed in juju-core:
milestone: 1.21-beta1 → 1.22
Revision history for this message
Kapil Thangavelu (hazmat) wrote : Re: [Bug 1382751] Re: non subordinate container scoped relations broken

re desired behavior, i'd imagine not going into restart loops would be
good, via explicitly support for the scenario (scope != subordinate) or
preventing the scenario by erroring during add-relation

On Fri, Nov 7, 2014 at 3:36 AM, Menno Smits <email address hidden>
wrote:

> To reproduce:
>
> juju bootstrap
> juju deploy --repository ~/path/to/repo
> local:container-scoped-relations-provider
> juju deploy --repository ~/path/to/repo
> local:container-scoped-relations-requirer --to 1
> juju add-relation juju add-relation container-scoped-relations-provider
> container-scoped-relations-requirer
>
> At this point both the provider and requirer uniters continually die and
> restart, reporting "ModeAbide: service is not a subordinate".
>
> As far as I can tell, when EnterScope() is called as the relation is
> joined, subordinateOps() decides to create a subordinate unit, which
> doesn't seem like the right thing to do in this case.
>
> I'm a little unsure of the desired behaviour here. I'll try to catch
> Will later on.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1382751
>
> Title:
> non subordinate container scoped relations broken
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1382751/+subscriptions
>

Revision history for this message
William Reade (fwereade) wrote :

yeah, the plan is to error on add-relation

Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :
Ian Booth (wallyworld)
Changed in juju-core:
status: In Progress → Fix Committed
Revision history for this message
Curtis Hovey (sinzui) wrote :

1.22 (master) is fixed with https://github.com/juju/juju/pull/1075

Revision history for this message
Menno Finlay-Smits (menno.smits) wrote :

Backported fix to 1.20 in https://github.com/juju/juju/pull/1159 (0817a0ba3b1b228423ccaf43833903b4c44b9a97)

Revision history for this message
Simon Davy (bloodearnest) wrote :

The fix for this seems to have unintentionally broken relating 2 subordinates via scoped relations.

Have filed a new bug: https://bugs.launchpad.net/juju-core/+bug/1396625

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.