model failing to tear down

Bug #1661930 reported by John A Meinel
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
High
Anastasia
2.1
Won't Fix
Undecided
Unassigned

Bug Description

I was testing deployment using the LXD provider. I probably was killing things as they were coming up. However, it currently says nothing exists in the model, yet the model refuses to tear down:

jameinel@nuc-1:~/jc (2.1-deploy-strict-bind-1661929)
$ juju status --format=yaml
model:
  name: default
  controller: test-lxd
  cloud: lxd
  version: 2.1-beta5
machines: {}
applications: {}

$ juju destroy-controller test-lxd --destroy-all-models
WARNING! This command will destroy the "test-lxd" controller.
This includes all machines, applications, data and other resources.

Continue? (y/N):y
Destroying controller
Waiting for hosted model resources to be reclaimed
Waiting on 1 model
.... (about 50x)
Waiting on 1 model

I have the feeling that one of the things I had tried to deploy, but then deleted before it actually was deployed left a reference count to the Model object which is preventing removal.

Changed in juju:
milestone: 2.1.0 → 2.2.0
milestone: 2.2.0 → 2.2.0-alpha1
Revision history for this message
Anastasia (anastasia-macmood) wrote :

@John,

Could you please re-try with 2.1-rc2?

Changed in juju:
status: Triaged → Incomplete
importance: High → Undecided
milestone: 2.2.0-alpha1 → none
Revision history for this message
John A Meinel (jameinel) wrote :

Reproduced today with juju-2.1-rc2

$ juju bootstrap aws jam-aws
$ juju switch controller
$ juju add-machine lxd:0
$ juju destroy-controller jam-aws
WARNING! This command will destroy the "jam-aws" controller.
This includes all machines, applications, data and other resources.

Continue? (y/N):y
Destroying controller
Waiting for hosted model resources to be reclaimed
Waiting on 0 model, 1 machine
Waiting on 0 model, 1 machine
Waiting on 0 model, 1 machine
...

$ juju status
Model Controller Cloud/Region Version
controller jam-aws aws/eu-west-1 2.1-rc2

App Version Status Scale Charm Store Rev OS Notes

Unit Workload Agent Machine Public address Ports Message

Machine State DNS Inst id Series AZ
0 started 54.154.46.119 i-0e957edfb68e4c7c9 xenial eu-west-1a
0/lxd/1 started 10.0.0.240 juju-744dac-0-lxd-1 xenial

Note that 0/lxd/1 is still perfectly happy and in 'started' state. It is not trying to die.
After waiting for 70 'waiting on machine' messages, I issued:

$ juju remove-machine 0/lxd/1

At which point it transitioned into 'stopped' and the 'destroy-controller' was able to progress to tearing down the controller machine.

Revision history for this message
John A Meinel (jameinel) wrote :

Still reproducible with 2.1rc2, so likely will be in the final 2.1 release. I don't know whether we'll want to address this in the 2.1 cycle, I think its more of a "we should fix destroy-controller so people don't run into this forever", but I don't know of anyone that *needs* it for 2.1.

Changed in juju:
importance: Undecided → High
milestone: none → 2.2.0
status: Incomplete → Triaged
Revision history for this message
John A Meinel (jameinel) wrote :

I realize my initial bug was not about a "stray machine not being told to shut down", which I think I did file a bug for.

*This* bug was more about being able to get a model into a wedged state. I'll see if I can reproduce it. I don't remember my exact reproduction steps.

Revision history for this message
Anastasia (anastasia-macmood) wrote :

I think this has the same underlying cause as bug # 1654603. If you agree, I'd mark it as duplicate.

Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.2-beta1 → 2.2-beta2
Revision history for this message
Anastasia (anastasia-macmood) wrote :

Marking as Won't Fix for 2.1 series as we are not planning another 2.1 release.

Changed in juju:
milestone: 2.2-beta2 → 2.2-beta3
Revision history for this message
Anastasia (anastasia-macmood) wrote :

@John,

We have encountered an issue where we could not destroy a model if it had applications with no units/machines. I wonder if your model fits this?...

If it does, this behavior has been recently fixed on develop. There was another oversight in the code that was responsible for model cleanup after destruction. The oversight was corrected as a drive-by fix by https://github.com/juju/juju/pull/7184/ - a PR against develop which is heading into 2.2-beta3.

Could you please re-try with latest develop?

If you are still seeing an issue, please clarify what steps you took to reproduce.

Changed in juju:
status: Triaged → Incomplete
milestone: 2.2-beta3 → none
Revision history for this message
Anastasia (anastasia-macmood) wrote :

Just saw another re-occurrence on model with an application that had no units/machines. Still looking...

Changed in juju:
status: Incomplete → In Progress
assignee: nobody → Anastasia (anastasia-macmood)
milestone: none → 2.2-beta3
Revision history for this message
Anastasia (anastasia-macmood) wrote :

I think what you have encountered is going to be fixed once PR against develop (2.2) https://github.com/juju/juju/pull/7218 lands.

If you have a reproduce scenario that isn't covered by QA steps in that PR nor functional tests, maybe we should create a functional test with it :D

Changed in juju:
status: In Progress → Fix Committed
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 1661930] Re: model failing to tear down

It sounded a lot like your one where you have an application with no units.
I don't think I have a simple reproduction case, but you did, which makes
me feel like this was fixed.

John
=:->

On Mon, Apr 10, 2017 at 1:08 PM, Anastasia <email address hidden>
wrote:

> ** Changed in: juju
> Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1661930
>
> Title:
> model failing to tear down
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1661930/+subscriptions
>

Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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