Le 12/06/2015 15:27, Matt Van Winkle a écrit :
On 6/12/15 7:46 AM, "Andrew Laski" <and...@lascii.com> wrote:
On 06/11/15 at 06:54pm, Ian Wells wrote:
On 11 June 2015 at 12:37, Richard Raseley <rich...@raseley.com> wrote:
Andrew Laski wrote:
There are many reasons a deployer may want to live-migrate instances
around: capacity planning, security patching, noisy neighbors, host
maintenance, etc... and I just don't think the user needs to know or
care that it has taken place.
They might care, insofar as live migrations will often cause
performance
degradation from a users perspective.
Seconded. If your app manager is warned that you're going to be live
migrating it can do something about the capacity drop. I can imagine
cases
where a migrating VM would be brutally murdered [1] and replaced because
it's not delivering sufficient performance.
To be clear I see instance-action reporting more as a log of what has
previously happened to an instance, not a report of what's currently
happening. A live migration still has task_state changes to make it
visible to a user.
My view is that in a cloud environment it shouldn't matter which host
you're on, as long as it meets the scheduling constraints required, so a
no-downtime movement between them is not an important event for a user.
But that does ignore the performance drop-off that may be noticed by a
user, so there are reasons to expose that information. I'm just in
favor of making it optional, not hiding it in general.
Completely agree with all your points, Andrew. As someone who's starting
to live migrate more and more tenants, this is exactly the approach that
would be useful for me.
Well, since live-migrate is having RBAC, why not considering that
listing live migrations should also be something RBAC'd ?
I mean, if the policy allows the user to live-migrate, then the API
should provide the list of live migrations. If that's not the case, then
the API should just drop the related lines.
-Sylvain
Thanks!
Matt
--
Ian.
[1] See "nova help brutally-murder"
_________________________________________________________________________
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
