juju-core

Cannot deploy charms in jes envs

Bug #1516144 reported by Curtis Hovey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core
Fix Released
Critical
Menno Finlay-Smits
juju-core 1.26-alpha2

Bug Description

This bug is like bug 1513552, but is limited to deployments with the jes feature flag set. Li

As seen in
    http://reports.vapour.ws/releases/3307/job/functional-jes/attempt/262

Charms are in error.
       cannot assign unit "dummy-sink/0" to machine: cannot assign unit "dummy-sink/0"
        to new machine or container: cannot assign unit "dummy-sink/0" to new machine:
        unit is already assigned to a machine

This job tests juju by bootstrapping with the jes feature flag, then deploys two trivial stacks to two different environments. The error happens during the deployment of unctional-jes-env1. The test never get to deploy unctional-jes-env2.

Curtis Hovey (sinzui)
Changed in juju-core:
assignee: nobody → Nate Finch (natefinch)
Revision history for this message
Nate Finch (natefinch) wrote :

The real error appears to be

2015-11-13 19:01:10 INFO juju.worker runner.go:275 stopped "unitassigner", err: "4873074d-7936-4e66-89dd-4ffb6e4d7f3b:dummy-source/0" is not a valid unit id

I think this is a difference with how tags and unit ids are converted with jes enabled.

Revision history for this message
Tim Penhey (thumper) wrote :

The ids are not changed at all with the flag on or off.

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

The problem is that the collectionwatcher is used without filtering by environment. The unitassigners for each environment are seeing unit ids for the other environments.

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

Fix is here: https://github.com/juju/juju/pull/3737

Menno Finlay-Smits (menno.smits)
Changed in juju-core:
status: In Progress → Fix Committed
Revision history for this message
Nate Finch (natefinch) wrote :

Trying to reproduce the problem, but struggling a lot with getting CI happy so it can run locally. Manual attempts to reproduce the bug were unsuccessful.

Revision history for this message
Andrew Wilkins (axwalk) wrote :

I'm not sure if this is *the* problem, but I can see *a* problem with the current unit assigner code in state.

Unit.assignToMachineOps calls the removeStagedAssignmentOp method to get an op that removes the unit-assignment doc. Unit.assignToNewMachine does not do that. The unit assigner changes have changed the behaviour of unit-to-machine assignment, which has uncovered another issue with the assignToNewMachine method -- it doesn't add storage attachments to the new machine.

I'm not entirely sure how this would have triggered, but if the machine agent restarts it's going to see old unit assignment docs in the collection still, and try to assign them again.

Revision history for this message
Andrew Wilkins (axwalk) wrote :

https://github.com/juju/juju/pull/3768

If someone could review and land (if it's good), that'd be good. I have to go out now.

Revision history for this message
Dimiter Naydenov (dimitern) wrote :

I've reviewed axw's PR and since it looks reasonable, I've set it to land.

Revision history for this message
Canonical Juju QA Bot (juju-qa-bot) wrote : Fix Released in juju-core master

Juju-CI verified that this issue is Fix Released in juju-core master:
    http://reports.vapour.ws/releases/3325

Changed in juju-core:
status: Fix Committed → Fix Released
Revision history for this message
Nate Finch (natefinch) wrote :

I reviewed Andrew's commit post-submit, and I also think it looks good. Thanks for finding that!

Cheryl Jennings (cherylj)
tags: added: 2.0-count
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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