Open Stack

> My understanding of Dan's proposal is that the flavor would represent
> the starting point and, after any fine-grained resize, it would no
> longer represent actual usage. 

Correct.

> having a flavor (or similar concept) to represent allocation is a
> generally accepted practice used across most infrastructure
> offerings.

But if we provide knobs for each of those fine-grained resource
amounts, flavors become (IMHO) much less useful as a description of
usage. If the ratio of flavors to instances becomes large (as it could
in your proposed change) I think the usefulness breaks down quickly.

> As part of retaining the experience, auto-created flavors would be
> marked as private and therefore not shown to users when listing
> flavors.  However, if an API user references one directly by ID in a
> create server/resize/show request it would be permissible - e.g. they
> are duplicating an existing server, query the flavor, then use in the
> subsequent create server.

I think that the general consensus is that the notion of dynamic
flavors is an unfavorable approach. Since we happen to be having this
discussion while an API redesign is happening, I'd say the more
productive path forward is to figure out how we want per-instance usage
to be exposed which makes sense both with and without fine-grained
resource tweaks. Perhaps a flavorRef is the wrong way.

Right now, if you create an instance from flavor 1, then change the
parameters of flavor 1, the flavorRef will be wrong anyway. Before I
moved instance_type information to system_metadata, doing that would
even cause billing stuff to be incorrect. Lets figure out how to
represent the actual instance parameters in APIv3, which I think will
serve everyone's needs.

--Dan