| 2013-04-18 15:01:34 |
Jean-Baptiste Lallement |
bug |
|
|
added bug |
| 2013-04-18 15:02:49 |
Jean-Baptiste Lallement |
description |
Currently UTAH propose the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs. So none of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next tests runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs. So none of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next tests runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
|
| 2013-04-18 15:03:48 |
Jean-Baptiste Lallement |
description |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs. So none of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next tests runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs on physical systems. None of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next tests runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
|
| 2013-04-18 15:04:20 |
Jean-Baptiste Lallement |
description |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs on physical systems. None of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next tests runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs on physical systems. None of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
|
| 2013-04-18 15:06:26 |
Jean-Baptiste Lallement |
description |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs on physical systems. None of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the state right after installation. |
Currently UTAH proposes the following options:
1. Run the tests on a fresh installation: it means between 20 and 30 minutes of provisioning before the test really starts.
2. Run the tests on an already provisioned system: this means the test environment is not a fresh installation any more after the first run if the test altered the state of the system.
In the context of autolanding, there are 14 stacks (a group of projects) that run autopilot tests against packages from PPAs on physical systems. None of the current options proposed by UTAH is satisfying.
In case 1, it spends 7hours a day to provision the same systems again and again which clearly doesn't scale.
In case 2, only the 1rst run uses a fresh installation, next runs will have packages from a PPA installed on the system.
We'd need the best of 1 and 2: reuse an existing installation reverted to the original state immediately after installation. |
|
| 2013-05-01 23:55:48 |
Andy Doan |
utah: importance |
Undecided |
High |
|
| 2013-05-01 23:56:00 |
Andy Doan |
utah: assignee |
|
Max Brustkern (nuclearbob) |
|
| 2013-05-03 00:46:45 |
Max Brustkern |
utah: status |
New |
In Progress |
|
| 2014-04-14 21:52:56 |
Max Brustkern |
utah: assignee |
Max Brustkern (nuclearbob) |
|
|
| 2014-04-14 21:53:02 |
Max Brustkern |
utah: status |
In Progress |
Confirmed |
|
