<font size=2 face="sans-serif">IMO, the desired behavior of 'resize' is:</font>
<br><font size=2 face="sans-serif">- user should be able to influence the
expected 'downtime', i.e., whether it should be done dynamically on the
same host (zero downtime), using 'live' migration (close to zero downtime),
or non-live. Ideally, there should be also an API to determine which modes
are supported.</font>
<br><font size=2 face="sans-serif">- user should be able to influence the
placement, similarly to instance provisioning, meaning that either scheduler
hints should be persisted and used during 'resize', or the user should
be able to specify scheduler hints when applying resize (or both). In particular,
it might make sense to have a dedicated weight function preferring to keep
the instance on the same host, if possible.</font>
<br><font size=2 face="sans-serif">- optionally, it might make sense to
have a filter (to be specified by the admin) that would prevent migration
of instances with certain characteristics (which would apply during resize)</font>
<br>
<br><font size=2 face="sans-serif">The combination of the above would determine
whether it can or will be on the same host (transparently to the user).</font>
<br>
<br><font size=2 face="sans-serif">Having said that, as a short-term measure,
making "resize_to_same_host" more flexible certainly sounds like
a step in the right direction.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Michael J Fork <mjfork@us.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">15/02/2013 06:08 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[openstack-dev]
Optionally force instances to "stay put" on resize</font>
<br>
<hr noshade>
<br>
<br>
<br><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 color=blue face="sans-serif"><u>https://blueprints.launchpad.net/nova/+spec/configurable-resize-placement</u></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><font size=3><br>
</font><font size=2 face="sans-serif"><br>
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><font size=3><br>
</font><font size=2 face="sans-serif"><br>
Blueprint Description</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> Currently OpenStack has a boolean "allow_resize_to_same_host"
config option that constrains<br>
> placement during resize. When this value is false, the ignore_hosts
option is passed to the scheduler. <br>
> When this value is true, no options are passed to the scheduler and
the current host can be<br>
> considered. In some use cases - e.g. PowerVM - a third option of "require
same host' is desirable.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> This blueprint will deprecate the "allow_resize_to_same_host"
config option and replace it with <br>
> "resize_to_same_host" that supports 3 values - allow, forbid,
require. Allow is equivalent to true in the<br>
> current use case (i.e. not scheduler hint, current host is considered),
forbid to false in current use case <br>
> (i.e. the ignore_hosts scheduler hint is set), and require forces
the same host through the use of the<br>
> force_hosts scheduler hint.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
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><font size=3><br>
</font><font size=2 face="sans-serif"><br>
Comments from </font><a href=https://review.openstack.org/#/c/21139/><font size=2 color=blue face="sans-serif"><u>https://review.openstack.org/#/c/21139/</u></font></a><font size=2 face="sans-serif">:</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> I still think this is a bad idea. The only reason the flag was there
in the first place was so we could <br>
> run tempest on devstack in the gate and test resize. Semantically
this changes the meaning of resize<br>
> in a way that I don't think should be done.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> I understand what the patch does, and I even think it appears to be
functionally correct based on<br>
> what the intention appears to be. However, I'm not convinced that
the option is a useful addition.<br>
><br>
> First, it really just doesn't seem in the spirit of OpenStack or "cloud"
to care this much about where <br>
> the instance goes like this. The existing option was only a hack for
testing, not something expected <br>
> for admins to care about.<br>
><br>
> If this really *is* something admins need to care about, I'd like
to better understand why. Further, if <br>
> 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 <br>
> more sense to have this be API driven. I'd like to see some thoughts
from others on this point."</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> "I completely agree with the "spirit of cloud" argument.
I further think that exposing anything via the <br>
> API that would support this (i.e. giving the users control or even
indication of where their instance lands) <br>
> is a dangerous precedent to set.<br>
><br>
> I tend to think that this use case is so small and specialized, that
it belongs in some other sort of policy <br>
> implementation, and definitely not as yet-another-config-option to
be exposed to the admins. That, or in <br>
> some other project entirely :)"</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
and my response to those concerns:</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
> I agree this is not an 80% use case, or probably even that popular
in the other 20%, but resize today <br>
> is the only user facing API that can trigger the migration of a VM
to a new machine. In some environments, <br>
> this network traffic is undesirable - especially 1GBe - and may want
to be explicitly controlled by an <br>
> Administrator. In this implementation, an Admin can still invoke a
migration manually to allow the resize to <br>
> succeed. I would point to the Island work by Sina as an example, they
wrote an entire Cinder driver <br>
> designed to minimize network traffic.<br>
><br>
> I agree with the point above that exposing this on an end-user API
is not correct, users should not know <br>
> or care where this goes. However, as the cloud operator, I should
be able to have that level of control <br>
> and this puts it in their hands.<br>
><br>
> Obviously this option would need documented to allow administrators
to decide if they need to change it,<br>
> but it certainly wouldn't be default. Expectation is that it would
of use in smaller installations or enterprise <br>
> uses cases more often than service providers.<br>
><br>
> Additionally, it continues to honor the existing resize API contract.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
An additional use case - beyond 1GbE - is if an environment uses large
ephemeral disks.</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
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><font size=3><br>
</font><font size=2 face="sans-serif"><br>
Thanks.<br>
<br>
Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
OpenStack Architect, Cloud Solutions and OpenStack Development<br>
IBM Systems & Technology Group</font><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>