Other flavors I heard of / used: gigantic (16 CPU, 16G RAM, 80G disk), moregigantic (16 CPU, 16G RAM, 160G disk), bigdisk (4? CPU, 24G RAM, 300G disk).

That's very interesting. I didn't know about gigantic, moregigantic, or bigdisk. Are they flavors we've discontinued? Or are they hidden by default? For what it's worth, bigram still shows up on my menu in Horizon even though I lack quota to use it.

Incidentally I've had this idea for some time to offer very high project quotas and very high performance VPS flavors to match. These would be special cases that would require approval and would be reserved for particular high-impact projects. Sort of like a grants program where you make a business case for your work.

• gigantic is in use by the video project for transcoding.
• moregigantic was used in the same project for a single transcoding instance with a larger disk space (T129581), but we found it unnecessary after we moved 'transcoded files' to NFS in T152899
• bigdisk is from T169133, but openstack-browser now reports it having UNKNOWN flavor. Another use I found is T178332, but it now shows justdisk

I don't know whether they are hidden or discontinued, as I do not manage any projects mentioned. (v2c is just the video project's biggest consumer :) )

There was, according to my history-digging a long time ago (because I got curious about flavors), and if I remember correctly, flavors with another prefix (like the m1 now).

Related tasks:

• T132194 (which just plainly proposes new flavors without recommending what those flavors might be)
• T95731 (which specifically requests a large-storage instance; I think the long term solution for that will be detachable block storage)
• T159930 (also a request for a large-storage instance)

In T188941#4025128, @Harej wrote:

Incidentally I've had this idea for some time to offer very high project quotas and very high performance VPS flavors to match. These would be special cases that would require approval and would be reserved for particular high-impact projects. Sort of like a grants program where you make a business case for your work.

We do that, but we do it on a one-off basis and don't advertise it. Everybody thinks their project should have all the resources. :)

Since the default disk allocation for all VMs is the same 20G used by the base image and additional disk is only used when provisioned via Puppet, there isn't a huge amount of utility in these more RAM + CPU & less disk types. Quota is done by RAM and CPU with disk utilization being incidentally capped just by the flavors that we offer. If projects have exotic needs I think it would generally be better for them to talk to the cloud-services-team in a project/quota request than to offer a wide array of self-service options.

In T188941#4025705, @bd808 wrote:

Since the default disk allocation for all VMs is the same 20G used by the base image and additional disk is only used when provisioned via Puppet

This is not apparent to the end-user. When I see a flavor with 80 GB of storage I expect that it will come with 80 GB of storage, not 20 GB with an additional 60 GB volume made available through /srv. I've had to assure people that we weren't cutting their disk quota, just that they needed to set up the extra storage. We should advertise each flavor as having the same storage capacity, with the option to define additional storage capacity.

This also doesn't address the inverse situation, where someone needs a lot of storage but not much computing power. In that case, they are forced to go with the flavor with more computing power than they need; they can't just not use the extra RAM/CPU.

In T188941#4025711, @Harej wrote:

In T188941#4025705, @bd808 wrote:

Since the default disk allocation for all VMs is the same 20G used by the base image and additional disk is only used when provisioned via Puppet

This is not apparent to the end-user. When I see a flavor with 80 GB of storage I expect that it will come with 80 GB of storage, not 20 GB with an additional 60 GB volume made available through /srv. I've had to assure people that we weren't cutting their disk quota, just that they needed to set up the extra storage. We should advertise each flavor as having the same storage capacity, with the option to define additional storage capacity.

The UX for this could be improved, but until we have quota'ed attachable block storage (FY19/20 at the earliest) the "option to define additional storage capacity" pretty much doesn't exist in the OpenStack infrastructure.

This also doesn't address the inverse situation, where someone needs a lot of storage but not much computing power. In that case, they are forced to go with the flavor with more computing power than they need; they can't just not use the extra RAM/CPU.

They are not forced, they can easily ask for and receive a custom image type. If it turns out that more than N projects have a real use for the image type then we could make the option more widely available. Again, I think the major deficiency here is documentation and communication rather than functionality. We are not aiming to be and AWS or Rackspace competitor. We really do want to know what folks are doing in the VMs and why so we can help them make the best use of the shared resource pool which will always be smaller than the global demand.

It's good that we don't have to "fix" this by tomorrow. We can wait for a better solution to come along; in this case, having storage that is separate from computation.

In the meantime, I do think the UI needs to make clearer that all instances start off with 20 GB of storage, and that extra storage is allocated as a separate step.

Just so this doesn't get lost: