master cannot deploy charms

Bug #1513552 reported by Curtis Hovey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core
Fix Released
Critical
Nate Finch

Bug Description

As seen in
     http://reports.vapour.ws/releases/3265
commit 9462c5d cannot deploy charms The error looks like a generic deployment error seen occasionally, but this us systemic.

The suspect commits are
    https://github.com/juju/juju/commit/26f6cac73ef314f523626a394e1298d18c0d5cec
    https://github.com/juju/juju/commit/9462c5d4da9d2152545719e9f786285448af56d8

The full scope of the issue can be seen at
    http://reports.vapour.ws/releases/issue/563b902c749a563ed218b6cf

See bug 1516144 for the details about the functional-jes failures.

Revision history for this message
Curtis Hovey (sinzui) wrote :

The errors looks like this

services:
  dummy-sink:
    charm: local:trusty/dummy-sink-0
    exposed: true
    service-status:
      current: error
      message: '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'
      since: 05 Nov 2015 06:43:14Z
    relations:
      source:
      - dummy-source
    units:
      dummy-sink/0:
        workload-status:
          current: error
          message: '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'
          since: 05 Nov 2015 06:43:14Z
        agent-status:
          current: lost
          message: agent is not communicating with the server
          since: 05 Nov 2015 06:43:14Z
        agent-state: error
        agent-state-info: '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'
        machine: "2"
        public-address: 54.254.252.81
  dummy-source:
    charm: local:trusty/dummy-source-0
    exposed: false
    service-status:
      current: error
      message: 'cannot assign unit "dummy-source/0" to machine: cannot assign unit
        "dummy-source/0" to new machine or container: cannot assign unit "dummy-source/0"
        to new machine: unit is already assigned to a machine'
      since: 05 Nov 2015 06:43:14Z
    relations:
      sink:
      - dummy-sink
    units:
      dummy-source/0:
        workload-status:
          current: error
          message: 'cannot assign unit "dummy-source/0" to machine: cannot assign
            unit "dummy-source/0" to new machine or container: cannot assign unit
            "dummy-source/0" to new machine: unit is already assigned to a machine'
          since: 05 Nov 2015 06:43:14Z
        agent-status:
          current: lost
          message: agent is not communicating with the server
          since: 05 Nov 2015 06:43:14Z
          version: 1.26-alpha2
        agent-state: error
        agent-state-info: 'cannot assign unit "dummy-source/0" to machine: cannot
          assign unit "dummy-source/0" to new machine or container: cannot assign
          unit "dummy-source/0" to new machine: unit is already assigned to a machine'
        agent-version: 1.26-alpha2
        machine: "1"
        public-address: 54.254.229.81

description: updated
Curtis Hovey (sinzui)
description: updated
Revision history for this message
Nate Finch (natefinch) wrote :

So, this appears to be a race condition where doing an expose and/or add-relation immediately after deploy causes the error. This is likely due to those commands being issued while the unit exists but before it is assigned to a machine.

If you just juju deploy a charm, it deploys just fine.

Note that the charms actually are deployed just fine (you can see the unit logs running without error in the CI results). They also appear exposed and related as expected. If you wait for a while, the errors actually go away, and everything appears fine.

Obviously, we shouldn't get into this error state in the first place, even if we do eventually get out of it.

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

I've submitted a revert of the merge that caused this issue, though I'm still not exactly clear on why it's happening, but at least the code is out of master for now.

Revision history for this message
Nate Finch (natefinch) wrote :
Changed in juju-core:
status: Triaged → Fix Committed
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/3278

Changed in juju-core:
status: Fix Committed → Fix Released
Curtis Hovey (sinzui)
description: updated
tags: added: 2.0-count
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.