Should have the same RAM / CPU characteristics of large, but the Disk characteristics of xlarge. This is what most xlarge instances need anyway. For example, the logging aggregator for tools is an xlarge, while it could/should totally be just this flavor.
Proposed naming convention:
where X is number of CPU cores, Y is GB of RAM, Z is GB of Storage.
- Allows us to maintain a matrix of instance flavors that is consistently named and easy to understand
- Allows for better provisioning depth since projects can be more explicit / specific about what they want.
- Harder to remember than 'small' 'medium' etc (although this is perhaps a good thing, since it makes how much resources you are using a conscious choice - '2G of RAM' sounds better than 'small'
We could use a flavor with larger disk and low ram/cpu, for example for a Docker registry and a Swift cluster.
m1.small has 20G disk, the partitioning scheme makes / use almost all of it with the extended disk space being solely 500MB or so.
For the beta cluster we had the following flavor created:
|Name||CPU||RAM (GB)||Disk (GB)|
Can we create a flavor c1.m2.s100 with 1 cpu, 2G of RAM, and 100 G of disk (== 80G of extended disk space)?
I think I oppose this being available by default to all projects as we cannot quota disk space usage effectively. I have no problem with it being available as part of a quota increase request.
What happens now is that people needing extra disk space ends up creating an m1.xlarge which also consumes 16GB of RAM/8cpu. Though that goes against their RAM/CPu quota so would somehow prevent exhausting disk space.
I am fine having per project tasks filled instead, so I guess we can decline this?