Open Stack

Dan Smith <dms at danplanet.com> wrote on 05/15/2013 01:23:09 PM:

> From: Dan Smith <dms at danplanet.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 05/15/2013 03:53 PM
> Subject: Re: [openstack-dev] Dynamic Flavors Support
>
> > 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.

Agree with this statement when cloud = IaaS, but not when viewing cloud as
more of a platform to build scalable applications to build on.  In a cloud
where end-user cost is based on resource allocation (e.g. virtually every
public cloud), the user is forced to go to a bigger VM because higher
allocation rations can be driven using cookie cutter sizes.  In an
installation measured on utilization, we do not want to force a user to
allocate an additional CPU it doesn't need.

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

As Russell stated in an earlier mail, flavors serve a valuable purpose; I
believe we must maintain the existing relationship between flavors and
instances where every instance has a flavor that accurately represents the
usage.

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

I disagree that the solution is overly-complex for a deployer or user of
the APIs (my primary focus).  The access to APIs would be consistent
whether you used a flavorRef or flavor and every instance would have a
flavor reference assigned that accurately represented resource usage
(something expected by virtually every application written to an IaaS API
today).

> --Dan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Michael

-------------------------------------------------
Michael Fork
Architect, OpenStack Development
IBM Systems & Technology Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/81009375/attachment.html>