Page MenuHomePhabricator

Create a new labs flavor available to all project: largedisk
Closed, DeclinedPublic


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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I'm actually going to create s160.small, which has 160 G of storage but only a single CPU.

Proposed naming convention:


where X is number of CPU cores, Y is GB of RAM, Z is GB of Storage.


  1. Allows us to maintain a matrix of instance flavors that is consistently named and easy to understand
  2. Allows for better provisioning depth since projects can be more explicit / specific about what they want.


  1. 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'

But Horizon tells you how much RAM/CPU/storage that flavour gives the instance when you pick the flavour on there

Proposed naming convention:


where X is number of CPU cores, Y is GB of RAM, Z is GB of Storage.

Is there a limit to the length of the name, and can there be spaces in the name?
'1 VCPU, 2 GB RAM, 80GB storage' as flavor name would be awesome.

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:

NameCPURAM (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?

bd808 added a subscriber: bd808.

We will continue to handle these on a per-request basis for the foreseeable future. The cloud-services-team is currently not comfortable with creating a large proliferation of flavors which are generally available.