| 2014-09-24 20:33:55 |
Curtis Hovey |
bug |
|
|
added bug |
| 2014-09-24 21:47:34 |
Curtis Hovey |
description |
The test that verifies that in the case of total catastrophe and the loose of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but they can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
The test that verifies that in the case of total catastrophe and the lose of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but they can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
|
| 2014-09-24 21:47:44 |
Curtis Hovey |
description |
The test that verifies that in the case of total catastrophe and the lose of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but they can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
The test that verifies that in the case of total catastrophe and the loss of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but they can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
|
| 2014-09-24 21:49:14 |
Curtis Hovey |
description |
The test that verifies that in the case of total catastrophe and the loss of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but they can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
The test that verifies that in the case of total catastrophe and the loss of all state-servers, enterprise customers can restore the state server then again call --ensure-ha is failing
http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/761/console
This test was written in conjunction with HA and illustrates what CTS recommends customers do, but the message we see implies restore will no longer attempt to restore when the env was in HA.
Starting restore.
Call of juju restore exited with an error
Restore failed:
2014-09-24 19:43:01 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha2-precise-amd64 gc]
error: cannot re-bootstrap environment: restore does not support HA juju configurations yet
2014-09-24 19:43:02 ERROR juju.cmd supercommand.go:323 subprocess encountered error code 1
The console log shows that the test verified juju wont do something stupid like restore to a working state-server, but a warning is shows that the instance_id isn't present in the explanation that the state-server is still up. Instead we see a message that the feature isn't supported. This is not an error because we expected juju to say no, but it foreshadows a problem.
After the test instruments a failure by deleting all three state-servers and ensuring they are down, the restore command exits quickly with the message "error: cannot re-bootstrap environment: restore does not support HA juju configurations yet"
We know that Juju cannot restore all the HA state-servers, but juju can restore the master state-server then run --ensure-HA again to regain control of their deployed services.
This test last passed in devel with commit 9ba34084. The first failure is commit 0fafcd98. The suspects are
0fafcd98 Merge pull request #826 from dimitern/state-openedportswatcher-no-global-keys
3cc1d04 Merge pull request #816 from axw/provider-common-providerstate
66f10b1 Merge pull request #799 from dimitern/firewaller-apiv1 |
|
| 2014-09-25 01:20:34 |
Tim Penhey |
juju-core: assignee |
|
Horacio Durán (hduran-8) |
|
| 2014-09-25 01:20:38 |
Tim Penhey |
juju-core: status |
Triaged |
In Progress |
|
| 2014-09-25 02:05:37 |
Tim Penhey |
juju-core: status |
In Progress |
Fix Committed |
|
| 2014-09-25 06:52:00 |
Andrew Wilkins |
juju-core: status |
Fix Committed |
Fix Released |
|
| 2014-09-25 06:52:04 |
Andrew Wilkins |
juju-core: status |
Fix Released |
Fix Committed |
|
| 2014-09-25 08:56:35 |
Abel Deuring |
juju-core: status |
Fix Committed |
Fix Released |
|
