Open Stack

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.

-Sylvain


> -jay
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev