Open Stack

> I'm also skeptical with the assertion in the blueprint that managing
> flavors is administratively intensive.

I think that is probably true for Nova being applied to non-cloudy
deployment scenarios. However, that only points (IMHO) to why that
shouldn't be done in the first place.

> Right now I'm -1 on this feature.  I'm open to being convinced,
> though, if others think it's useful and would like to argue their
> points.

I definitely don't like the approach of creating actual flavors
dynamically, as is currently being proposed.

If I recall correctly, part of the reason we (I) made the move to
storing flavor information in system_metadata was so that we could have
fine-grained resizes, if desired. Assuming a deployer wanted to sell
small upgrades, like buying more memory without needing more disk
space, etc.

In my opinion, it would be completely reasonable to support that via an
API extension which would modify the instance's private flavor
information and then trigger a resize (which should do the right thing
today, as far as I know). I also believe that billing would be handled
correctly, assuming the instance usage stuff takes the flavor
information from the instance's private copy (which I think it does).

That gives us the flexibility do what Michael wants (I think), without
needing to expose it via the (overly-complex) dynamically-created
flavors approach.

--Dan