On 08/29/2016 05:11 AM, Sylvain Bauza wrote:
Le 29/08/2016 13:25, Jay Pipes a écrit :
On 08/26/2016 09:20 AM, Ed Leafe wrote:
On Aug 25, 2016, at 3:19 PM, Andrew Laski <and...@lascii.com> wrote:
One other thing to note is that while a flavor constrains how much
local
disk is used it does not constrain volume size at all. So a user can
specify an ephemeral/swap disk <= to what the flavor provides but can
have an arbitrary sized root disk if it's a remote volume.
This kind of goes to the heart of the argument against flavors being
the sole source of truth for a request. As cloud evolves, we keep
packing more and more stuff into a concept that was originally meant
to only divide up resources that came bundled together (CPU, RAM, and
local disk). This hasn’t been a good solution for years, and the
sooner we start accepting that a request can be much more complex
than a flavor can adequately express, the better.
If we have decided that remote volumes are a good thing (I don’t
think there’s any argument there), then we should treat that part of
the request as being as fundamental as a flavor. We need to make the
scheduler smarter so that it doesn’t rely on flavor as being the only
source of truth.
The first step to improving Nova is admitting we have a problem. :)
FWIW, I agree with you on the above. The issue I had with the proposed
patches was that they would essentially be a hack for a short period
of time until the resource providers work standardized the way that
DISK_GB resources were tracked -- including for providers of shared
disk storage.
I've long felt that flavors as a concept should be, as Chris so
adeptly wrote, "UI furniture" and should be decomposed into their
requisite lists of resource amounts, required traits and preferred
traits and that those decomposed parts are what should be passed to
the Compute API, not a flavor ID.
But again, we're actively changing all this code in the resource
providers and qualitative traits patches so I warned about adding more
code that was essentially just a short-lived hack. I'd be OK adding
the hack code if there were some big bright WARNINGs placed in there
that likely the code would be removed in Ocata.
While :
#1 the first change about setting root_gb equals 0 in RequestSpec for
making sure BFV instances are correctly using the DiskFilter is fine by
me having it merged with a TODO/FIXME saying that the code would be
expired once the scheduler uses the resource providers,
#2, then the second patch about trying to look at the BDMs for
DiskFilter is very wrong by me, because the Compute API shouldn't accept
IMHO to ask for a flavor *and* a BDM with a related disk size different
from the flavor. AFAIT, we should return a 40x (probably 409 or 400) for
that instead of accepting it silently.
Well, a flavor is always required when launching an instance. I wasn't
aware until recently that one could "override" the root GB (or eph/swap)
sizes in the API. Apparently, the API allows it, though, even though the
code ignores whatever was passed as the override value. If the API
supports it, I think the code should probably be changed to override the
size values to whatever the user entered, no?
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
