Move away from flavors to more dynamic instance specifications
Flavors present a somewhat administratively intensive approach to specifying an instance's technical specifications. I'd like to propose an alternative approach which no longer uses flavors and instead uses a predefined set of increments of each specification. In other words, instead of a list of options the user selects the specific vcpu, ram and storage amounts. In Horizon this can be presented on a sliding scale or as a set of drop-downs (one for vcpu's, one for ram amount, one for disk space). In the command-line the user can simply specify how much ram, disk and how many vcpu's are required. Instead of flavors the administrator then simply sets limits.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
I think this proposal needs a documented design (wiki page would be good) and then discussed on the openstack-dev mailing list. Thanks! --russellb
I created patches for nova and novaclient to overwrite vcpus, memory_mb, root_gb and ephemeral_gb of the flavors for an instance. (yosshy)
---jesse pretorius start---
At this stage it's simply an idea which hasn't gone through to any full documentation or code yet.
Our view to do this without breaking the existing model is to simply do it in the web interface. We'd achieve this as follows:
1) Build an array of the increments, something like:
cpu options = {1,2,4,6,8,10}
ram options = {1,2,4,
disk options = {5,10,15,
2) Make a loop in our build setup flavors with the combinations of these increments.
3) Make Horizon use the arrays to display drop-downs or sliding scale options for cpu, ram and disk. This would then make it appear to the end-user that they're choosing more dynamically, even though they're actually choosing from a list of flavors in a different way.
Our ideal is for flavors to go away and to simply build a server based on your own choice of cpu, ram and disk... but that would involve changing too much plumbing for us to commit to.
---jesse pretorius end---
---yosshy start---
My design is below:
* API has validators for min/max of vcpus, memory_mb, disk_gb and
ephemeral_gb. No arrays for them because we need APIs to get/manage arrays
for Horizon and nova command, and we can handle resource usage with quota
and ceilometer.
* Flavors remain. Of course, flavors can be removed but more changes are
necessary to do so. IMO, "flavor" as a template of VM spec isn't a bad idea
and template-style will remain if flavors are gone. Additionally, it's
easier to remove flavors after my patch is applied.
---yosshy end---
Mailing list discussion: http://
(yosshy) Thank you for a url above. Can we continue to discuss it on the thread?I think this proposal needs a documented design (wiki page would be good) and then discussed on the openstack-dev mailing list. Thanks! --russellb
I created patches for nova and novaclient to overwrite vcpus, memory_mb, root_gb and ephemeral_gb of the flavors for an instance. (yosshy)
---jesse pretorius start---
At this stage it's simply an idea which hasn't gone through to any full documentation or code yet.
Our view to do this without breaking the existing model is to simply do it in the web interface. We'd achieve this as follows:
1) Build an array of the increments, something like:
cpu options = {1,2,4,6,8,10}
ram options = {1,2,4,
disk options = {5,10,15,
2) Make a loop in our build setup flavors with the combinations of these increments.
3) Make Horizon use the arrays to display drop-downs or sliding scale options for cpu, ram and disk. This would then make it appear to the end-user that they're choosing more dynamically, even though they're actually choosing from a list of flavors in a different way.
Our ideal is for flavors to go away and to simply build a server based on your own choice of cpu, ram and disk... but that would involve changing too much plumbing for us to commit to.
---jesse pretorius end---
---yosshy start---
My design is below:
* API has validators for min/max of vcpus, memory_mb, disk_gb and
ephemeral_gb. No arrays for them because we need APIs to get/manage arrays
for Horizon and nova command, and we can handle resource usage with quota
and ceilometer.
* Flavors remain. Of course, flavors can be removed but more changes are
necessary to do so. IMO, "flavor" as a template of VM spec isn't a bad idea
and template-style will remain if flavors are gone. Additionally, it's
easier to remove flavors after my patch is applied.
---yosshy end---
Mailing list discussion: http://
(yosshy) Thank you for a url above. Can we continue to discuss it on the thread?
Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)
