Open Stack

This reminds me again of the differences between Migrate and
Live-Migrate API calls.
I think having the ability, in both cases, to do scheduler hints makes
a lot of sense.

I am thinking about admins and maintinace rather than end-users.

So +1 to most of Alex's points.

John

On 16 February 2013 03:46, Michael Basnight <mbasnight at gmail.com> wrote:
>
> 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.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



-- 
John Garbutt MA (Cantab) MBCS
---------------------------------------------------------
13 Greenhaze Lane
Great Cambourne
Cambridge
CB23 5EF
---------------------------------------------------------
07903 211430
www.johngarbutt.com
---------------------------------------------------------