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