openstack team mailing list archive

[Michael J Fork <mjfork@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx,
> 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