> The harder part is that we need to be able to specify > independent/orthogonal quota constraints on different flavors. It > would be really useful to be able to say basically, you can have 2TB > of memory from this flavor, and 4TB of memory from that flavor. This > would allow saying something like "you can have up to 3 1TB instances, > and independently have up to 3TB of small instances as well."
OK, so its the "as well" aspect that's problematic here. (If it were an either-or situation as opposed to a both, then obviously a combination of the instances and RAM quotas would get you part of the way at least). So just thinking aloud, we could potentially add new per-flavor quota resources so that for each existing instance-type, there was the potential to add a new quota limiting *only* that instance type (and maybe keep the existing instances quotas as an over-arching limit). For example, if the following quotas where set: instances: 100 instances-m1.xlarge: 10 instances-m1.large: 20 instances-m1.small: 50 instances-m1.tiny: 100 and a user requested an additional xlarge instance, we'd first check if we had headroom on the instances-m1.xlarge quota and then if we also had headroom on the over-arching instances quota (before going on to check the ram & cores if necessary). Whereas, if a medium instance was requested, we would only check the overarching limit, as there is no instances-medium quota defined. This would require some change to the quotas logic, to allow the set of resources that may be limited by quotas to be more dynamic (currently we have a fairly fixed set, whereas new instance types may be defined at any time). Would that address your requirement? Cheers, Eoghan _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp