| Summary: | unable to delete a deployment, shutdown instance due to ec2 key | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> |
| Component: | deltacloud-core | Assignee: | Michal Fojtik <mfojtik> |
| Status: | CLOSED ERRATA | QA Contact: | Ronelle Landy <rlandy> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | hbrock, jrd, lutter, rananda, whayutin |
| Target Milestone: | beta6 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 3e46de11d6f51e279ca2293565c8f2eef83a20ec | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-15 20:32:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
wes hayutin
2012-02-01 12:58:46 UTC
Just to make sure I understand: the DC bug here is that DC doesn't return a 404. Whether the key should be there or not depends on what happened before aeolus crashed. Wes, answers to the above? so.. I *think* the key is actually in ec2.. or was shortly before this happened. It may be a race condition. recreate is as follows.. 1. create a ec2 deployable 2. ssh in 3. destroy the deployable (application) If by chance ruby segfaults... deltacloud will return the key not found error as well... not sure if the call to delete the key happens before the rest of the code runs or what... this bug may be a result of the segfault and thus a dupe... but not 100% sure It's not really related to the segfault - besides the issue of a misleading status code from DC (502 instead of 404), there seems to be an issue with the transactionality of deleting deployables in Aeolus. If the Aeolus server fails (e.g., by an unexpected shutdown) at the wrong point in time, it leaves a partially finished task behind. Depending on how the Aeolus code in question is written, switching to a 404 might be enough for Aeolus to work properly.; I am assuming here that Aeolus' goal is to ultimately delete the key, and it should be satisfied if the key it wants to delete has been deleted already. I talked this over with morazi. He asserts that this is sufficiently high prio that we should get a new rpm with a fix before 2/8 if at all possible. DL and MF, please see about nailing this one down first thing monday, eh? Setting dev-ack+ and blocker+ for beta commit 3e46de11d6f51e279ca2293565c8f2eef83a20ec
Author: Michal Fojtik <mfojtik>
Date: Wed Feb 1 14:38:38 2012 +0100
Core: Return 404 instead of exception when accessing non-existing driver in drivers collection
commit f66b594398bf92b142b1a35dd0754ef48ff22762
Author: Michal Fojtik <mfojtik>
Date: Wed Feb 1 14:37:45 2012 +0100
EC2: We should return 404 instead of 502 or 500 in case when resource is not available
===========================================================
Package: deltacloud-core-0.5.0-2.el6
Tag: ce-rhel-6-candidate
Status: complete
Built by: mfojtik
ID: 197630
Started: Tue, 07 Feb 2012 06:15:14 EST
Finished: Tue, 07 Feb 2012 06:18:17 EST
Changelog:
* Tue Feb 07 2012 Michal Fojtik <mfojtik> - 0.5.0-2
- Applied patches for BZ #786437
Verified that Deltacloud now returns 404 when a resources is not available Accessing available drivers: 10.11.9.71 - - [07/Feb/2012 10:32:46] "GET /api/drivers/ec2?format=xml HTTP/1.1" 200 2229 0.0186 10.11.9.71 - - [07/Feb/2012 10:32:56] "GET /api/drivers/rhevm?format=xml HTTP/1.1" 200 126 0.0147 Accessing a driver that does not exist: 10.11.9.71 - - [07/Feb/2012 10:33:42] "GET /api/drivers/google?format=xml HTTP/1.1" 404 - 0.0064 rpm -qa | grep deltacloud deltacloud-core-vsphere-0.5.0-4.el6.noarch deltacloud-core-rhevm-0.5.0-4.el6.noarch deltacloud-core-ec2-0.5.0-4.el6.noarch deltacloud-core-0.5.0-4.el6.noarch rubygem-deltacloud-client-0.5.0-2.el6.noarch rpm -qa | grep aeolus aeolus-all-0.8.0-21.el6.noarch aeolus-conductor-0.8.0-21.el6.noarch rubygem-aeolus-cli-0.3.0-7.el6.noarch aeolus-configure-2.5.0-11.el6.noarch aeolus-conductor-daemons-0.8.0-21.el6.noarch aeolus-conductor-doc-0.8.0-21.el6.noarch rubygem-aeolus-image-0.3.0-7.el6.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0587.html |