| 2012-11-20 18:39:25 |
Scott Moser |
bug |
|
|
added bug |
| 2012-11-20 18:53:02 |
Scott Moser |
summary |
maas provider terminates all unused systems |
maas provider unallocates all nodes it did not allocate [does not play well with others] |
|
| 2012-11-20 18:53:19 |
Scott Moser |
summary |
maas provider unallocates all nodes it did not allocate [does not play well with others] |
maas provider releases all nodes it did not allocate [does not play well with others] |
|
| 2012-11-20 19:04:09 |
Scott Moser |
bug task added |
|
maas |
|
| 2012-11-20 21:34:10 |
Julian Edwards |
maas: status |
New |
Invalid |
|
| 2012-11-30 22:00:59 |
Kapil Thangavelu |
juju: importance |
Undecided |
Medium |
|
| 2012-12-06 15:43:09 |
Scott Moser |
juju: importance |
Medium |
Low |
|
| 2012-12-06 16:29:35 |
Scott Moser |
juju: importance |
Low |
Wishlist |
|
| 2013-10-09 19:45:41 |
Scott Moser |
description |
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'. |
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'.
Related bugs:
* bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju |
|
| 2013-10-10 14:49:26 |
Kapil Thangavelu |
bug task added |
|
juju-core |
|
| 2013-10-12 03:38:06 |
Curtis Hovey |
juju: status |
New |
Triaged |
|
| 2013-10-12 04:03:21 |
Curtis Hovey |
tags |
|
maas |
|
| 2013-10-12 04:04:20 |
Curtis Hovey |
juju-core: status |
New |
Triaged |
|
| 2013-10-12 04:04:23 |
Curtis Hovey |
juju-core: importance |
Undecided |
Low |
|
| 2013-10-15 17:25:30 |
Scott Moser |
description |
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'.
Related bugs:
* bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju |
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'.
Related bugs:
* bug 1237398: "You'll need a separate MAAS key for each Juju environment" is wrong.
* bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju
* bug 1239488: Juju api client cannot distinguish between environments |
|
| 2013-10-16 05:30:17 |
Julian Edwards |
branch linked |
|
lp:~allenap/juju-core/maas-environment-uuid-use |
|
| 2013-10-16 05:31:09 |
Julian Edwards |
branch linked |
|
lp:~julian-edwards/juju-core/maas-uuid-file-prefix |
|
| 2013-10-16 05:31:27 |
Julian Edwards |
juju-core: assignee |
|
Julian Edwards (julian-edwards) |
|
| 2013-10-16 05:31:30 |
Julian Edwards |
juju-core: status |
Triaged |
In Progress |
|
| 2013-10-17 14:16:06 |
Curtis Hovey |
nominated for series |
|
juju-core/1.16 |
|
| 2013-10-17 14:16:06 |
Curtis Hovey |
bug task added |
|
juju-core/1.16 |
|
| 2013-10-17 14:16:14 |
Curtis Hovey |
juju-core/1.16: status |
New |
In Progress |
|
| 2013-10-17 14:16:22 |
Curtis Hovey |
juju-core/1.16: importance |
Undecided |
High |
|
| 2013-10-17 14:16:44 |
Curtis Hovey |
juju-core/1.16: assignee |
|
Roger Peppe (rogpeppe) |
|
| 2013-10-17 14:16:56 |
Curtis Hovey |
juju-core/1.16: milestone |
|
1.16.1 |
|
| 2013-10-17 14:16:59 |
Curtis Hovey |
juju-core: milestone |
|
1.17.0 |
|
| 2013-10-17 15:46:19 |
Curtis Hovey |
juju-core/1.16: status |
In Progress |
Fix Committed |
|
| 2013-10-17 15:46:22 |
Curtis Hovey |
juju-core: status |
In Progress |
Fix Committed |
|
| 2013-10-24 23:24:40 |
Curtis Hovey |
tags |
maas |
maas-provider |
|
| 2013-10-29 23:23:40 |
Julian Edwards |
juju: status |
Triaged |
Invalid |
|
| 2013-10-31 01:49:51 |
Curtis Hovey |
juju-core/1.16: status |
Fix Committed |
Fix Released |
|
| 2013-10-31 18:26:09 |
Curtis Hovey |
juju-core/1.16: milestone |
1.16.1 |
1.16.2 |
|
| 2013-10-31 21:16:27 |
James Page |
bug task added |
|
juju-core (Ubuntu) |
|
| 2013-10-31 21:16:37 |
James Page |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-10-31 21:16:37 |
James Page |
bug task added |
|
juju-core (Ubuntu Saucy) |
|
| 2013-10-31 21:16:37 |
James Page |
nominated for series |
|
Ubuntu Trusty |
|
| 2013-10-31 21:16:37 |
James Page |
bug task added |
|
juju-core (Ubuntu Trusty) |
|
| 2013-10-31 21:43:27 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/trusty/juju-core/trusty-proposed |
|
| 2013-10-31 22:23:39 |
Launchpad Janitor |
juju-core (Ubuntu Trusty): status |
New |
Fix Released |
|
| 2013-11-21 10:13:12 |
James Page |
description |
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'.
Related bugs:
* bug 1237398: "You'll need a separate MAAS key for each Juju environment" is wrong.
* bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju
* bug 1239488: Juju api client cannot distinguish between environments |
[Impact]
juju destroy-environment destroys all machines allocated to the MAAS user being used in the environment, not just the ones owned by Juju.
[Test Case]
Allocate machines using maas-cli
juju bootstrap
juju destroy-environment
(all machines are terminated and powered off)
[Regression Potential]
The fix is limited to the MAAS provider in the codebase; so regression potential is limited in scope of provider.
[Original Bug Report]
juju/agents/provision.py process_machines says:
| """Ensure the currently running machines correspond to state.
|
| At the end of each process_machines execution, verify that all
| running machines within the provider correspond to machine_ids within
| the topology. If they don't then shut them down.
|
| Utilizes concurrent execution guard, to ensure that this is only being
| executed at most once per process
...
| # Terminate all unused juju machines running within the cluster.
This logic/description is clearly fundamentally flawed and means that a given maas user cannot have more than one juju environment on the same maas cluster.
It also means that if a user is using juju, then they cannot deploy a node in *any* other way, or juju bootstrap node will kill it for them.
I did not explicitly check, but I would suspect/hope that this behavior is not the same as the EC2 provider. Ie, I do not expect that juju kills all my running EC2 instances if I choose to type 'juju bootstrap'.
Related bugs:
* bug 1237398: "You'll need a separate MAAS key for each Juju environment" is wrong.
* bug 1229275: juju destroy-environment also destroys nodes that are not controlled by juju
* bug 1239488: Juju api client cannot distinguish between environments |
|
| 2013-11-21 10:13:25 |
James Page |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-11-21 10:32:39 |
James Page |
juju-core (Ubuntu Saucy): importance |
Undecided |
High |
|
| 2013-11-21 21:41:30 |
Brian Murray |
juju-core (Ubuntu Saucy): status |
New |
Fix Committed |
|
| 2013-11-21 21:41:35 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2013-11-21 21:41:45 |
Brian Murray |
tags |
maas-provider |
maas-provider verification-needed |
|
| 2013-11-21 21:48:13 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/saucy-proposed/juju-core |
|
| 2013-11-22 11:18:09 |
James Page |
tags |
maas-provider verification-needed |
maas-provider verification-done |
|
| 2013-12-02 15:54:45 |
Launchpad Janitor |
juju-core (Ubuntu Saucy): status |
Fix Committed |
Fix Released |
|
| 2013-12-02 15:55:17 |
Stéphane Graber |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-12-20 17:44:28 |
Curtis Hovey |
juju-core: status |
Fix Committed |
Fix Released |
|
| 2014-05-16 10:47:47 |
ary |
bug |
|
|
added subscriber ary |
