Enhancement: add nova-manage instance_type alter
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Wishlist
|
Unassigned |
Bug Description
Per my question (https:/
Right now you have two options:
1) Delete an instance type and create it with the new configuration (not bad but a little clunky)
2) Hack the DB table directly (really not user friendly)
This is not a major enhancement by any means, but would make managing instance types a bit more clear. If I could get a bit of feedback and direction, I think this would be a great chance for me to get more familiar with the code and make a contribution back to OpenStack. What do you think?
Cheers,
Graham
tags: | added: feature-request |
Changed in nova: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
Graham:
Don't take this as "don't do this", but more as "be careful how you handle this" ...
I intentionally left the "U" out the CRUD actions for instance_ types/flavors due to the implications for billing and instance= >instance_ type foreign key lookups. As instances can be quite long lived (many EC2 instances have been running for 1+ years), maintaining the integrity of the "launched instance_type" to current instance's instance_type mapping is pretty important. While it is a pain (to do the delete --purge and then create), it saves from some potentially tricky logical problems down the road ...
Perhaps as a compromise, could your update look like the "nova-manage instance_type update x1.large xxx xxx ..." and behind the covers it simply marks the current x1.large deleted and creates a new x1.large ? Not sure if this works for flavors (might be unique keys) ... but it would preserve the logic.
You can read more on the original blueprint for the feature (with use cases) wiki.openstack. org/ConfigureIn stanceTypesDyna mically
http://
or my blog post: ken.pepple. info/openstack/ 2011/03/ 03/Configurable -Instance- Types-For- OpenStack- Nova/
http://