On Mon, Aug 29, 2016, at 07:25 AM, Jay Pipes wrote: > 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.
I'd like to clarify that there are two parts to the patches proposed. One part is about bdm overrides influencing the scheduler, and the other part is about proper resource tracking. I've attempted to punt on the resource tracking part in this thread because I agree that we have a proper solution on the way and the current proposals are workarounds. There is some value in the workarounds though as they could be backported to Mitaka. > > -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 __________________________________________________________________________ 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
