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.
>

Fair point. To some degree the background that led me to put the initial
blueprint down came from exposure to feature requests from private cloud
deployments. That said, perhaps my initial take on getting rid of flavors
altogether was a little radical and my discussion with Michael and this
discussion is proving valuable to temper that radicality into practicality.


> > 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.
>

Happy with that view. What I'm hoping for is that we can stimulate thought
on two things:

1) Can we facilitate, perhaps with a little smoke and mirrors as suggested
by me on the whiteboard of the Blueprint, a way that through Horizon the
selection appears to be more dynamic... even if it isn't actually dynamic?
This, of course, would be an alternative blueprint for the Horizon project
and wouldn't need any changes in nova.
Perhaps it's worth clarifying that the problem we specifically are trying
to get away from here is something we're finding in our private cloud
deployments - the flavor list is getting impractically large for Horizon's
drop-down box selection.

2) Can we, with Michael's suggested approach, facilitate changes in
instance specifications in a relatively simple manner? We know that typical
cloud instances should be throw-away servers with automated software
deployment and configuration. However, as Openstack gets used more and more
in Private Cloud implementations and other typically IaaS deployments, the
need for instance specification changes will become more and more important.


> 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.
>

Quite right. Often it'll be a change of one element.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/cc4e7ae8/attachment.html>