Migrate (cold/live) all instances from host marked for maintenance

Summary
=======

Particular scope of this BP is to provide an action button named “Migrate instances” to Hypervisors Table in Horizon, that migrates all instances from host marked for maintenance. Host marked for maintenance has disabled nova-compute service so scheduler won’t distribute instances on that host. After disabling nova-compute service administrator should have ability to migrate all vm’s from host marked for maintenance and make this host empty (ready for maintenance actions). This approach should provide migration the same way as in CLI using python-novaclient via Horizon. After clicking on this button, there should be displayed modal window containing form with possibilities to select different options for migration. After migrating instances in Horizon, there should be displayed new page containing table with results. This page should have appropriate statuses for each instance tried to be moved on another host. This action should be only available to users with the Admin role. This blueprint should also provide unit tests which will be covering added functionality.

Motivation
========

This feature in Horizon is desirable because it will simply allow administrator to migrate all instances from host marked for maintenance via Horizon. This functionality is already provided in command line, but not in Horizon. Creating “Migrate instances” button should allow administrator to use simpler way of preparing host for maintenance actions in Horizon.

Migrating instances from host is a part of more complex functionality ‘marking host as be ready for maintenance’ so administrator can perform updates or other maintenance actions on it. This functionality needs possibility to enable/disable nova-compute service on host marked for maintenance because it is not desirable behavior of scheduler to distribute new VM’s on that host.

In background this feature should be done in following way:

1. Disable nova-compute service so no new VM’s are going to be scheduled to that node (there are already implemented solution to this in Horizon using specified ‘Disable service’ button)
2. Migrate all instances from host marked for maintenance (using modal window form with possible migratation options – the same options are possible to use via CLI)
3. Do maintenance actions on host
4. Enable nova-compute service on host

This way of putting host on maintenance mode is also mentioned here:
http://docs.openstack.org/openstack-ops/content/maintenance.html

Why this way ?
Because actually there aren’t any other ways to mark host on maintenance mode and then migrate all instances from that host via Horizon. This feature in Horizon should allow administrator to migrate instances from Host with disabled nova-compute service, in a way that administrator considers as appropriate (live or cold migration).

Description
=========
This blueprint is about enabling possibility of cold/live migration of instances on host with disable nova-compute service.

Differences between migration (cold migration) and live-migration:

Cold migration - move an instance from one host to another, reboots across the move, destination is picked by scheduler. This type of migration should be used when administrator did not select live_migrate option in modal window form in Horizon or migrated instance is not running.

Live migration - move an instance (with “Power state” = “active”) from one host to another, instance doesn't appear to reboot, destination is optional (it could be defined by administrator or picked by scheduler). This type of migration should be used when administrator selected live_migrate option in modal window form in Horizon and migrated instance is still running.

This feature is related to Hypervisors table in Horizon, especially to “Compute Host” tab. There should be add a dedicated action button (located in “Actions” section) which allow users to open a modal window containing form with possibilities to select options needed for appropriate migration of instances from specified host. Only users with Admin role should have been available to use this feature. In the background, functionality of cold/live migration in Horizon are going to be implemented using python-novaclient. When administrator selected live_migrate option in modal window form, instances with “Power state” = “active” should be migrated using “Live migration” with zero downtime. Other instances should be cold migrated. This blueprint should also provide unit tests which will be covering added functionality in positive and negative cases.

As a difference between actual implementation and currently planned approach there can be mentioned way of using cold/live migration. In juno release in python-novaclient appeared two new CLI commands:

a) $nova host-evacuate-live - Live migrate all instances of the specified host to other available hosts.
b) $nova host-servers-migrate - Migrate all instances of the specified host to other available hosts.

Using this commands instead of direct using “nova migrate” and “nova live-migrate” seems to be better approach because logic of migrating all instances has been already implemented in this commands and they only needs to be used.

Other observed issue is how we understand migrating instances with power state as for example “paused”. They cannot be migrated. Neither “nova migrate” nor “nova live-migrate” can move “paused” vm to another host. In command line there appears relevant error message in that case. General approach suggests, that this error messages should be placed in results page table, after trying to migrate all instances. But maybe someone have a better idea of moving “paused” instances to another hosts ?

UX
===

UX implementation of this blueprint is rather simple. It requires only one single new action button in Compute Host Tab in Hypervisors Table in Horizon. This button after being clicked should display modal window containing form with options for migration of instances. After migrating of instances, host marked for maintenance should be empty and scheduler shouldn’t distribute any new instances on that host. Results of migrating each instance should be displayed in specified table in the new page.

Testing
======

Functionality of migrating instances from host marked for maintenance service in Horizon should be covered by unit tests. Each of this implemented method should be covered in positive and negative context.

Positive context means that tested method should return expected value, success message, appropriate response code, template and redirect.

In negative context, tested method should return error message, appropriate response code and redirect.

Preparing tests requires stubbed hosts with different states.

Outside Dependencies
==================

This blueprint will be using python-novaclient to cold/live migrate instances on host marked for maintenance.

Beside that dependency tree is available in Work Items section.

Requirements Update Required
========================

There are no changes to openstack/requirements in openstack that will need to land before this change can merge into Horizon.

Doc Impact
=========

There are no changes to Horizon documentation that are required.