<tt><font size=2>> If so, I can write up a blueprint and discussion
for the design summit.<br>
</font></tt>
<br><font size=2 face="sans-serif">+1</font>
<br><font size=2 face="sans-serif">There are few related operations which
have been recently discussed, namely 'migrate' without specifying the target
host (to be used in host maintenance scenario), and 'evacuate' (to be used
in HA scenario).</font>
<br><font size=2 face="sans-serif">Orchestration of such higher level scenarios
is probably another good candidate for a design summit topic.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Alex Glikson</font>
<br><font size=2 face="sans-serif">IBM Research</font>
<br>
<br><tt><font size=2>Jay Pipes <jaypipes@gmail.com> wrote on 18/02/2013
05:58:16 PM:<br>
<br>
> From: Jay Pipes <jaypipes@gmail.com></font></tt>
<br><tt><font size=2>> To: openstack-dev@lists.openstack.org, </font></tt>
<br><tt><font size=2>> Date: 18/02/2013 06:01 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [Openstack] Optionally
force instances <br>
> to "stay put" on resize</font></tt>
<br><tt><font size=2>> <br>
> A while ago, I remember a discussion about the semantics around<br>
> migration and I think I recommended moving towards a model where we
just<br>
> have a single migrate API call instead of the existing live and non-live<br>
> migration calls -- that very much tend to confuse users.<br>
> <br>
> Is there still interest in consolidating the calls so that the eventual<br>
> novaclient CLI call would just be:<br>
> <br>
> nova migrate [--live] [--hints=...] [--disk-over-commit]<br>
> <br>
> If so, I can write up a blueprint and discussion for the design summit.<br>
> <br>
> Best,<br>
> -jay<br>
> <br>
> On 02/18/2013 07:44 AM, John Garbutt wrote:<br>
> > This reminds me again of the differences between Migrate and<br>
> > Live-Migrate API calls.<br>
> > I think having the ability, in both cases, to do scheduler hints
makes<br>
> > a lot of sense.<br>
> > <br>
> > I am thinking about admins and maintinace rather than end-users.<br>
> > <br>
> > So +1 to most of Alex's points.<br>
> > <br>
> > John<br>
> > <br>
> > On 16 February 2013 03:46, Michael Basnight <mbasnight@gmail.com>
wrote:<br>
> >><br>
> >> On Feb 15, 2013, at 9:35 PM, Michael J Fork wrote:<br>
> >><br>
> >>> Adding general and operators for additional feedback.<br>
> >>><br>
> >>> Michael J Fork/Rochester/IBM wrote on 02/15/2013 10:59:46
AM:<br>
> >>><br>
> >>>> From: Michael J Fork/Rochester/IBM<br>
> >>>> To: openstack-dev@lists.openstack.org,<br>
> >>>> Date: 02/15/2013 10:59 AM<br>
> >>>> Subject: Optionally force instances to "stay
put" on resize<br>
> >>>><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.<br>
> >>>><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.<br>
> >>>><br>
> >>>> Blueprint  Description<br>
> >>>><br>
> >>>>> Currently OpenStack has a boolean "allow_resize_to_same_host"<br>
> >>>>> config option that constrains<br>
> >>>>> placement during resize. When this value is false,
the<br>
> >>>>> ignore_hosts option is passed to the scheduler.<br>
> >>>>> When this value is true, no options are passed
to the scheduler<br>
> >>>>> and the current host can be<br>
> >>>>> considered. In some use cases - e.g. PowerVM
- a third option of<br>
> >>>>> "require same host' is desirable.<br>
> >>>>><br>
> >>>>> This blueprint will deprecate the "allow_resize_to_same_host"<br>
> >>>>> config option and replace it with<br>
> >>>>> "resize_to_same_host" that supports
3 values - allow, forbid,<br>
> >>>>> require. Allow is equivalent to true in the<br>
> >>>>> current use case (i.e. not scheduler hint, current
host is<br>
> >>>>> considered), forbid to false in current use case<br>
> >>>>> (i.e. the ignore_hosts scheduler hint is set),
and require forces<br>
> >>>>> the same host through the use of the<br>
> >>>>> force_hosts scheduler hint.<br>
> >>>><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?<br>
> >>>><br>
> >>>> Comments from </font></tt><a href=https://review.openstack.org/#/c/21139/:><tt><font size=2>https://review.openstack.org/#/c/21139/:</font></tt></a><tt><font size=2><br>
> >>>><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<br>
> >>>>> run tempest on devstack in the gate and test
resize. Semantically<br>
> >>>>> this changes the meaning of resize<br>
> >>>>> in a way that I don't think should be done.<br>
> >>>><br>
> >>>>> I understand what the patch does, and I even
think it appears to<br>
> >>>>> be functionally correct based on<br>
> >>>>> what the intention appears to be. However, I'm
not convinced that<br>
> >>>>> the option is a useful addition.<br>
> >>>>><br>
> >>>>> First, it really just doesn't seem in the spirit
of OpenStack or<br>
> >>>>> "cloud" to care this much about where<br>
> >>>>> the instance goes like this. The existing option
was only a hack<br>
> >>>>> 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<br>
> >>>>> to better understand why. Further, if<br>
> >>>>> 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<br>
> >>>>> more sense to have this be API driven. I'd like
to see some<br>
> >>>>> thoughts from others on this point."<br>
> >>>><br>
> >>>>> "I completely agree with the "spirit
of cloud" argument. I further<br>
> >>>>> think that exposing anything via the<br>
> >>>>> API that would support this (i.e. giving the
users control or even<br>
> >>>>> 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,<br>
> >>>>> that it belongs in some other sort of policy<br>
> >>>>> implementation, and definitely not as yet-another-config-option
to<br>
> >>>>> be exposed to the admins. That, or in<br>
> >>>>> some other project entirely :)"<br>
> >>>><br>
> >>>> and my response to those concerns:<br>
> >>>><br>
> >>>>> I agree this is not an 80% use case, or probably
even that popular<br>
> >>>>> in the other 20%, but resize today<br>
> >>>>> is the only user facing API that can trigger
the migration of a VM<br>
> >>>>> to a new machine. In some environments,<br>
> >>>>> this network traffic is undesirable - especially
1GBe - and may<br>
> >>>>> want to be explicitly controlled by an<br>
> >>>>> Administrator. In this implementation, an Admin
can still invoke a<br>
> >>>>> migration manually to allow the resize to<br>
> >>>>> succeed. I would point to the Island work by
Sina as an example,<br>
> >>>>> 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<br>
> >>>>> is not correct, users should not know<br>
> >>>>> or care where this goes. However, as the cloud
operator, I should<br>
> >>>>> 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<br>
> >>>>> administrators to decide if they need to change
it,<br>
> >>>>> but it certainly wouldn't be default. Expectation
is that it would<br>
> >>>>> 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.<br>
> >>>><br>
> >>>> An additional use case - beyond 1GbE - is if an environment
uses<br>
> >>>> large ephemeral disks.<br>
> >>><br>
> >>>> 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.<br>
> >>>><br>
> >>>> Thanks.<br>
> >>>><br>
> >>>> Michael<br>
> >>>><br>
> >>>> -------------------------------------------------<br>
> >>>> Michael Fork<br>
> >>>> OpenStack Architect, Cloud Solutions and OpenStack
Development<br>
> >>>> IBM Systems & Technology Group<br>
> >>><br>
> >> Not that its in trunk right now, but openvz allows for online
<br>
> memory resizing, so resizing to the same host is optimal. Personally<br>
> im not sure the 3 way switch, so to speak, is needed, but i would
<br>
> like to see allow_resize_on_same_host to persist for container based<br>
> technologies. I cant say if lxc allows this, but maybe someone else
<br>
> can speak to that.<br>
> >> _______________________________________________<br>
> >> Mailing list: </font></tt><a href=https://launchpad.net/~openstack><tt><font size=2>https://launchpad.net/~openstack</font></tt></a><tt><font size=2><br>
> >> Post to     : openstack@lists.launchpad.net<br>
> >> Unsubscribe : </font></tt><a href=https://launchpad.net/~openstack><tt><font size=2>https://launchpad.net/~openstack</font></tt></a><tt><font size=2><br>
> >> More help   : </font></tt><a href=https://help.launchpad.net/ListHelp><tt><font size=2>https://help.launchpad.net/ListHelp</font></tt></a><tt><font size=2><br>
> > <br>
> > <br>
> > <br>
> <br>
> _______________________________________________<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>
> <br>
</font></tt>