Comment 37 for bug 1469179

Re: "This has been fixed in newer versions with the resource providers"

After disabling the RamFilter and DiskFilter, and instead relying on the Placement API for scheduling, most of the "scheduling" aspect of this problem has been addressed. I was able to drop a local patch to handle this root_gb!=0 for EBS volumes, and for most real-life use cases it is working. The placement API is not recording disk allocations for EBS volumes.

I found that we now have the opposite problem. I checked our database for exceptions and found that the EBS volumes case is now ok, but a few instances created in Mitaka, before upgrading to Ocata, that still exist, have incorrect placement API data. Their flavor has root_gb=0, but they have local disks, and the placement API shows them as having 0 GB of disk in the allocations table which is not true. I'll have to track this one down as a separate issue.

I tend to think that instance.root_gb should either be eliminated, or it should be kept correct. However, if the placement API makes it irrelevant from a scheduling perspective, perhaps this correction can be deferred until an opportunistic time?