Page MenuHomePhabricator

Allow to better customise RAM/CPU/Disk during virtual machine creation process
Closed, DeclinedPublic

Description

OpenStackManager proposes a list of VM profiles as "Instance type" during the VM creation process. I propose to allow to configure the VM more precisely.

We might allow to do this by adding 3 sliders to customise:

  • RAM
  • CPU
  • Mass storage

... and the previously "Instance type" list kept as presets.

This would allow more liberty (within the quota) for the users and a better fit between user needs and resource offer. As a consequence, this should also lead to a better resource allocation between VMs.

Event Timeline

Kelson created this task.Mar 9 2015, 2:55 PM
Kelson raised the priority of this task from to Needs Triage.
Kelson updated the task description. (Show Details)
Kelson added subscribers: Kelson, Andrew, yuvipanda.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 9 2015, 2:55 PM
Aklapper triaged this task as Low priority.Mar 23 2015, 5:05 PM
bd808 closed this task as Declined.Jan 6 2020, 5:07 PM
bd808 added a subscriber: bd808.

This would be some type of major re-write of how OpenStack manages instances or somehow creating, registering, and using a new image on the fly.

Kelson added a subscriber: BD2412.Jan 6 2020, 5:24 PM

@BD2412 Thank you for answering my request. I understand that we have to stick to OpenStack concepts. That said I have to emphasis that this approach IMO leads to a waste of HW resources. In addition, it sounds also a bit "outdated" to me, if I compare to other cloud solutions which provide a small(er) HW configuration granularity.

Aklapper removed a subscriber: BD2412.Jan 7 2020, 2:25 AM

(Removing mistake subscriber mention)

This would be some type of major re-write of how OpenStack manages instances or somehow creating, registering, and using a new image on the fly.

s/image/flavour/?

@BD2412 Thank you for answering my request. I understand that we have to stick to OpenStack concepts. That said I have to emphasis that this approach IMO leads to a waste of HW resources. In addition, it sounds also a bit "outdated" to me, if I compare to other cloud solutions which provide a small(er) HW configuration granularity.

Can you give some examples? AWS has pre-defined instance sizes.

Aklapper removed a subscriber: BD2412.Jan 7 2020, 3:04 AM
Kelson added a subscriber: BD2412.Jan 7 2020, 12:43 PM

This would be some type of major re-write of how OpenStack manages instances or somehow creating, registering, and using a new image on the fly.

s/image/flavour/?

@BD2412 Thank you for answering my request. I understand that we have to stick to OpenStack concepts. That said I have to emphasis that this approach IMO leads to a waste of HW resources. In addition, it sounds also a bit "outdated" to me, if I compare to other cloud solutions which provide a small(er) HW configuration granularity.

Can you give some examples? AWS has pre-defined instance sizes.

@Krenair Gandi.net and Sloppy.io allow to this kind of granularity. I'm not familiar with AWS, but still surprised you can not setup systems with custom cores/RAM/disk.

@Kelson, we hope to adopt 'Cinder' sometime in the next year or so, which will allow attachment of additional block devices. That will add quite a bit more flexibility when setting the storage ratio for a given VM. As for cpu/ram config... if you have a specific profile that you want for new VMs you can create a ticket requesting that I make a custom flavor, which is quite easy. Otherwise, I agree with the other posters that OpenStack doesn't support fully-user-defined flavor types.

@Andrew Thank you for your offer. In 2019 we have invested to improve the performance of our MWoffliner scraper. This effort is not over, there is 2-3 additional important things I want to get done before asking you guys to do more work ;) For the moment the overall VM setup we have (mwoffliner project) is pretty much OK and I'm so thankful you provide it. But of course improving performance of software changes the HW footprint and we will probably later have to rebuild/changes our VM landscape to be more efficient.