[openstack-dev] [Nova] Reconciling flavors and block device mappings

Andrew Laski andrew at lascii.com
Mon Aug 29 12:53:21 UTC 2016



On Mon, Aug 29, 2016, at 08:42 AM, Sylvain Bauza wrote:
> 
> 
> Le 29/08/2016 14:20, Jay Pipes a écrit :
> > 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?
> >
> I'm very sad to see this possible. FWIW, I think that the flavor should 
> always be the source of truth for knowing the asked disk size (if no, 
> imagine all the conditionals in code...) and we should somehow reconcile 
> what the flavor provided and what the user explicitly asked for.

At the heart of all of this is the fact that we've allowed people to
believe two different things: flavors are the source of truth, bdms can
be used to override flavors. But bdms only half override flavors because
they don't affect scheduling so people who believe the latter are
understandably trying to fix that. But we can't have it both ways, so we
need to have consensus about what we're supporting and then make it work
fully.

Personally I believe the cat is out of the bag on bdms overriding
flavors and we should just commit to that path and make it work well.
And for deployers who rely on flavors being the source of truth maybe we
provide them a policy check or some other mechanism to control
acceptable bdm values so that they can rely on flavor packing.


> 
> Having a possibility to trample the flavor size seems to be a very bad 
> UX (I guess most of the operators don't think about that when 
> understanding why this instance could have a different size from the 
> related flavor) hence me thinking we should rather discuss on a possible 
> new microversion for returning a 400 when both sizes are not identical.
> 
> The other option I could see could be to have the nested flavor in the 
> RequestSpec be reconciling those two objects being different from the 
> user-provided flavor (eg. say a flavor with swap=10G and a BDM with 
> swap=1G, then RequestSpec.flavor would have swap=1G) but given we don't 
> expose the RequestSpec objects on the API level, that still leaves 
> operators possibly confused.
> 
> -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



More information about the OpenStack-dev mailing list