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

Kekane, Abhishek Abhishek.Kekane at nttdata.com
Mon Aug 29 05:57:15 UTC 2016

From: John Griffith [mailto:john.griffith8 at gmail.com]
Sent: Friday, August 26, 2016 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

On Fri, Aug 26, 2016 at 10:20 AM, Ed Leafe <ed at leafe.com<mailto:ed at leafe.com>> wrote:
On Aug 25, 2016, at 3:19 PM, Andrew Laski <andrew at lascii.com<mailto: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.
​> +1

We have done extensive testing with patch [1] and ensured that it’s not breaking anything. IMO this patch should be the best solution till now and there should not be any issues in accepting the same. Please review the patch and provide your opinions so that we can take appropriate actions to get this resolved.

[1] https://review.openstack.org/#/c/200870/

Thank you,

Abhishek Kekane

The first step to improving Nova is admitting we have a problem. :)

-- Ed Leafe

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>

Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160829/85f58db2/attachment.html>

More information about the OpenStack-dev mailing list