<html><body>
<p><font size="2" face="sans-serif">The patch for the configurable-resize-placement blueprint (</font><a href="https://blueprints.launchpad.net/nova/+spec/configurable-resize-placement"><font size="2" face="sans-serif">https://blueprints.launchpad.net/nova/+spec/configurable-resize-placement</font></a><font size="2" face="sans-serif">) has generated a discussion on the review boards and needed to be brought to the mailing list for broader feedback.</font><br>
<br>
<font size="2" face="sans-serif">tl;dr would others find useful the addition of a new config option "resize_to_same_host" with values "allow", "require", "forbid" that deprecates "allow_resize_to_same_host" (functionality equivalent to "allow" and "forbid" in "resize_to_same_host")? Existing use cases and default behaviors are retained unchanged. The new use case is "resize_to_same_host = require" retains the exact same external API sematics and would make it such that no user actions can cause a VM migration (and the network traffic with it). An administrator can still perform a manual migration that would allow a subsequent resize to succeed. This patch would be most useful in environments with 1GbE or with large ephemeral disks. </font><br>
<br>
<font size="2" face="sans-serif">Blueprint Description</font><br>
<br>
<font size="2" face="sans-serif">> Currently OpenStack has a boolean "allow_resize_to_same_host" config option that constrains</font><br>
<font size="2" face="sans-serif">> placement during resize. When this value is false, the ignore_hosts option is passed to the scheduler. </font><br>
<font size="2" face="sans-serif">> When this value is true, no options are passed to the scheduler and the current host can be</font><br>
<font size="2" face="sans-serif">> considered. In some use cases - e.g. PowerVM - a third option of "require same host' is desirable.</font><br>
<br>
<font size="2" face="sans-serif">> This blueprint will deprecate the "allow_resize_to_same_host" config option and replace it with </font><br>
<font size="2" face="sans-serif">> "resize_to_same_host" that supports 3 values - allow, forbid, require. Allow is equivalent to true in the</font><br>
<font size="2" face="sans-serif">> current use case (i.e. not scheduler hint, current host is considered), forbid to false in current use case </font><br>
<font size="2" face="sans-serif">> (i.e. the ignore_hosts scheduler hint is set), and require forces the same host through the use of the</font><br>
<font size="2" face="sans-serif">> force_hosts scheduler hint.</font><br>
<br>
<font size="2" face="sans-serif">To avoid incorrectly paraphrasing others, the review comments against the change are below in their entirety followed by my comments to those concerns. The question we are looking to answer - would others find this function useful and / or believe that OpenStack should have this option?</font><br>
<br>
<font size="2" face="sans-serif">Comments from </font><a href="https://review.openstack.org/#/c/21139/"><font size="2" face="sans-serif">https://review.openstack.org/#/c/21139/</font></a><font size="2" face="sans-serif">:</font><br>
<br>
<font size="2" face="sans-serif">> I still think this is a bad idea. The only reason the flag was there in the first place was so we could </font><br>
<font size="2" face="sans-serif">> run tempest on devstack in the gate and test resize. Semantically this changes the meaning of resize</font><br>
<font size="2" face="sans-serif">> in a way that I don't think should be done.</font><br>
<br>
<font size="2" face="sans-serif">> I understand what the patch does, and I even think it appears to be functionally correct based on</font><br>
<font size="2" face="sans-serif">> what the intention appears to be. However, I'm not convinced that the option is a useful addition.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> First, it really just doesn't seem in the spirit of OpenStack or "cloud" to care this much about where </font><br>
<font size="2" face="sans-serif">> the instance goes like this. The existing option was only a hack for testing, not something expected </font><br>
<font size="2" face="sans-serif">> for admins to care about.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> If this really *is* something admins need to care about, I'd like to better understand why. Further, if </font><br>
<font size="2" face="sans-serif">> that's the case, I'm not sure a global config option is the right way to go about it. I think it may make </font><br>
<font size="2" face="sans-serif">> more sense to have this be API driven. I'd like to see some thoughts from others on this point."</font><br>
<br>
<font size="2" face="sans-serif">> "I completely agree with the "spirit of cloud" argument. I further think that exposing anything via the </font><br>
<font size="2" face="sans-serif">> API that would support this (i.e. giving the users control or even indication of where their instance lands) </font><br>
<font size="2" face="sans-serif">> is a dangerous precedent to set.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> I tend to think that this use case is so small and specialized, that it belongs in some other sort of policy </font><br>
<font size="2" face="sans-serif">> implementation, and definitely not as yet-another-config-option to be exposed to the admins. That, or in </font><br>
<font size="2" face="sans-serif">> some other project entirely :)"</font><br>
<br>
<font size="2" face="sans-serif">and my response to those concerns:</font><br>
<br>
<font size="2" face="sans-serif">> I agree this is not an 80% use case, or probably even that popular in the other 20%, but resize today </font><br>
<font size="2" face="sans-serif">> is the only user facing API that can trigger the migration of a VM to a new machine. In some environments, </font><br>
<font size="2" face="sans-serif">> this network traffic is undesirable - especially 1GBe - and may want to be explicitly controlled by an </font><br>
<font size="2" face="sans-serif">> Administrator. In this implementation, an Admin can still invoke a migration manually to allow the resize to </font><br>
<font size="2" face="sans-serif">> succeed. I would point to the Island work by Sina as an example, they wrote an entire Cinder driver </font><br>
<font size="2" face="sans-serif">> designed to minimize network traffic.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> I agree with the point above that exposing this on an end-user API is not correct, users should not know </font><br>
<font size="2" face="sans-serif">> or care where this goes. However, as the cloud operator, I should be able to have that level of control </font><br>
<font size="2" face="sans-serif">> and this puts it in their hands.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> Obviously this option would need documented to allow administrators to decide if they need to change it,</font><br>
<font size="2" face="sans-serif">> but it certainly wouldn't be default. Expectation is that it would of use in smaller installations or enterprise </font><br>
<font size="2" face="sans-serif">> uses cases more often than service providers.</font><br>
<font size="2" face="sans-serif">></font><br>
<font size="2" face="sans-serif">> Additionally, it continues to honor the existing resize API contract.</font><br>
<br>
<font size="2" face="sans-serif">An additional use case - beyond 1GbE - is if an environment uses large ephemeral disks.<br>
</font><br>
<font size="2" face="sans-serif">Would others find this function useful and / or believe that OpenStack should have this option? Again, the API contract is unchanged and it gives a cloud operator an additional level of control over the movement of instances. It would not be the default behavior, but rather enabled by an administrator depending on their specific use cases and requirements and the environment they are in.</font><br>
<br>
<font size="2" face="sans-serif">Thanks.</font><br>
<font size="2" face="sans-serif"><br>
Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
OpenStack Architect, Cloud Solutions and OpenStack Development<br>
IBM Systems & Technology Group</font></body></html>