Default 'tiny' instance_type has wrong root_gb

[Rick Harris]

The current `tiny` instance_type currently has a `root_gb` setting of '0'.

There are two problems with this:

1) It doesn't follow the power of 2 pattern:

m1.tiny root_gb=0 <= this should be 10
m1.small root_gb=20
m1.medium root_gb=40

2) More importantly, a 0 root_gb means we can build an instance with it using xenserver because any the _check_vdi_size call will return false since any image will be greater than 0 bytes!

The proposed solution is to just fix this going forward by updating the folsom migration. This won't affect, for better or worse, those who've already the migration, and presumably customized the instance types to meet their needs.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/27991

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/27991
Committed: http://github.com/openstack/nova/commit/5613818b1d7c702dc3c44bb1f063af2f6b708466
Submitter: Jenkins
Branch: master

commit 5613818b1d7c702dc3c44bb1f063af2f6b708466
Author: Rick Harris <email address hidden>
Date: Wed May 1 23:13:30 2013 +0000

    'm1.tiny' now has root_gb=1

    `root_gb=0` indicates that a disk-resize shouldn't occur which is not
    something that a default flavor should have enabled. This is
    especially true of one named 'tiny' since the unresized image could
    potentially be very large, leading to the unexpected result of a
    'tiny' instance consuming a massive amount of disk.

    The no-resize behavior is still supported, so if it's being relied on
    for testing, additional, non-default flavors can still be created that
    enable it.

    DocImpact
    Fixes bug 1175383

    Change-Id: Ifa5827c7f87dae95214bc4a585adce5735a05d83

[egon (egon-p)]

The arguments for why root_gb should be 1, and what root_gb=0 means are conflicting. Which is correct?