Open Stack

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 <andrew at 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