Open Stack

Russell Bryant <rbryant at redhat.com> wrote on 05/16/2013 04:05:59 PM:
> On 05/16/2013 12:21 PM, Michael J Fork wrote:
> > Dan Smith <dms at danplanet.com> wrote on 05/15/2013 01:23:09 PM:
> >>
> >> 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 makes a good point about how the code works and I think his
> suggestion is very reasonable.  What's wrong with it?  You didn't really
> say, other than just standing firm to your original proposal ...
>

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.  To get at actual usage, you would need to ignore
the flavor information on the server response and directly use individual
values (vcpus, ram, disk, and exra_specs). If this is true, I consider this
a step backwards in user experience: having a flavor (or similar concept)
to represent allocation is a generally accepted practice used across most
infrastructure offerings. Retaining that user experience is what drove the
original design.

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.

> --
> Russell Bryant
>
> _______________________________________________
> 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/79c00990/attachment.html>