Feature #1157
Support deletion of Flavors, support servers referring to inexistent (deleted) Flavors
Status: | Closed | Start date: | 09/16/2011 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | Kostas Papadimitriou | % Done: | 0% |
|
Category: | Cyclades UI | Spent time: | - | |
Target version: | v0.7 |
Description
The UI should handle the case when flavors get removed from the GET /flavors
response of the API but are still referenced by existing servers in GET /servers
, as happened with Images.
This is the last piece to allow arbitrary changes to the offered flavors.
Related issues
History
#1 Updated by Kostas Papadimitriou over 12 years ago
- Status changed from Assigned to Feedback
- Target version changed from 67 to v0.7
Fixed in ui-refactor branch. A solution similar to DELETED state images (#823) handling has been followed.
#2 Updated by Kostas Papadimitriou over 12 years ago
UI handles the vm flavor fetching as follows
- Check if vm has flavorRef id property
- Check if flavor instance with id equal to flavorRef exists in storage.flavors, a collection that contains all the available flavors and gets populated when application starts
- If no flavor found, make a synchronous call to the flavors/<flavorRef> url
- If request fails, append a dummy flavor object with id equal to flavorRef (cpu,ram, disk, name set to empty strings and status to DELETED) and add it in storage.flavors collection.
- If request succeeds, create a flavor object based on the data retrieved from request (and status set to DELETED) and add it in storage.flavors collection.
- Check again for flavour existance (step 2)
#3 Updated by Vangelis Koukis over 12 years ago
- Status changed from Feedback to Closed
Thanks for the documentation, seems to be a pretty robust approach.
Closing ticket.