Open Stack

Le 29/08/2016 14:43, Andrew Laski a écrit :
>
> On Mon, Aug 29, 2016, at 08:20 AM, Jay Pipes wrote:
>> 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?
> That's the question here. There's a lot of desire to have the overrides
> be the values used in scheduling, since currently the flavor values are
> used, but making that change potentially impacts how flavors are packed
> onto hosts for some deployers. The main thing I want to get out of this
> thread is if that's okay.
>
> The sense I get so far is that it's okay to make the change to have bdm
> values be passed to the scheduler, via RequestSpec modifications, and
> deployers can rely upon CPU/RAM constraints to determine packing. So the
> main thing to do is have good release notes about the change.
>

Like I said just before, that could be an option but given we don't 
expose an instance-related RequestSpec, it means that litterally 
operators showing an instance would wonder why its disk sizes could be 
different from the related flavor.

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