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:
... 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.
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.
@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.
@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.