Open Stack

On Feb 15, 2013, at 9:35 PM, Michael J Fork wrote:

> Adding general and operators for additional feedback.
> 
> Michael J Fork/Rochester/IBM wrote on 02/15/2013 10:59:46 AM:
> 
> > From: Michael J Fork/Rochester/IBM
> > To: openstack-dev at lists.openstack.org, 
> > Date: 02/15/2013 10:59 AM
> > Subject: Optionally force instances to "stay put" on resize
> > 
> > The patch for the configurable-resize-placement blueprint (https://
> > blueprints.launchpad.net/nova/+spec/configurable-resize-placement) 
> > has generated a discussion on the review boards and needed to be 
> > brought to the mailing list for broader feedback.
> > 
> > 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. 
> > 
> > Blueprint  Description
> > 
> > > Currently OpenStack has a boolean "allow_resize_to_same_host" 
> > > config option that constrains
> > > placement during resize. When this value is false, the 
> > > ignore_hosts option is passed to the scheduler. 
> > > When this value is true, no options are passed to the scheduler 
> > > and the current host can be
> > > considered. In some use cases - e.g. PowerVM - a third option of 
> > > "require same host' is desirable.
> > >
> > > This blueprint will deprecate the "allow_resize_to_same_host" 
> > > config option and replace it with 
> > > "resize_to_same_host" that supports 3 values - allow, forbid, 
> > > require. Allow is equivalent to true in the
> > > current use case (i.e. not scheduler hint, current host is 
> > > considered), forbid to false in current use case 
> > > (i.e. the ignore_hosts scheduler hint is set), and require forces 
> > > the same host through the use of the
> > > force_hosts scheduler hint.
> > 
> > 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?
> > 
> > Comments from https://review.openstack.org/#/c/21139/:
> > 
> > > I still think this is a bad idea. The only reason the flag was 
> > > there in the first place was so we could 
> > > run tempest on devstack in the gate and test resize. Semantically 
> > > this changes the meaning of resize
> > > in a way that I don't think should be done.
> > 
> > > I understand what the patch does, and I even think it appears to 
> > > be functionally correct based on
> > > what the intention appears to be. However, I'm not convinced that 
> > > the option is a useful addition.
> > >
> > > First, it really just doesn't seem in the spirit of OpenStack or 
> > > "cloud" to care this much about where 
> > > the instance goes like this. The existing option was only a hack 
> > > for testing, not something expected 
> > > for admins to care about.
> > >
> > > If this really *is* something admins need to care about, I'd like 
> > > to better understand why. Further, if 
> > > 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 
> > > more sense to have this be API driven. I'd like to see some 
> > > thoughts from others on this point."
> > 
> > > "I completely agree with the "spirit of cloud" argument. I further
> > > think that exposing anything via the 
> > > API that would support this (i.e. giving the users control or even
> > > indication of where their instance lands) 
> > > is a dangerous precedent to set.
> > >
> > > I tend to think that this use case is so small and specialized, 
> > > that it belongs in some other sort of policy 
> > > implementation, and definitely not as yet-another-config-option to
> > > be exposed to the admins. That, or in 
> > > some other project entirely :)"
> > 
> > and my response to those concerns:
> > 
> > > I agree this is not an 80% use case, or probably even that popular
> > > in the other 20%, but resize today 
> > > is the only user facing API that can trigger the migration of a VM
> > > to a new machine. In some environments, 
> > > this network traffic is undesirable - especially 1GBe - and may 
> > > want to be explicitly controlled by an 
> > > Administrator. In this implementation, an Admin can still invoke a
> > > migration manually to allow the resize to 
> > > succeed. I would point to the Island work by Sina as an example, 
> > > they wrote an entire Cinder driver 
> > > designed to minimize network traffic.
> > >
> > > I agree with the point above that exposing this on an end-user API
> > > is not correct, users should not know 
> > > or care where this goes. However, as the cloud operator, I should 
> > > be able to have that level of control 
> > > and this puts it in their hands.
> > >
> > > Obviously this option would need documented to allow 
> > > administrators to decide if they need to change it,
> > > but it certainly wouldn't be default. Expectation is that it would
> > > of use in smaller installations or enterprise 
> > > uses cases more often than service providers.
> > >
> > > Additionally, it continues to honor the existing resize API contract.
> > 
> > An additional use case - beyond 1GbE - is if an environment uses 
> > large ephemeral disks.
> 
> > 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.
> > 
> > Thanks.
> > 
> > Michael
> > 
> > -------------------------------------------------
> > Michael Fork
> > OpenStack Architect, Cloud Solutions and OpenStack Development
> > IBM Systems & Technology Group
> 
Not that its in trunk right now, but openvz allows for online memory resizing, so resizing to the same host is optimal. Personally im not sure the 3 way switch, so to speak, is needed, but i would like to see allow_resize_on_same_host to persist for container based technologies. I cant say if lxc allows this, but maybe someone else can speak to that.