1. Doctor Host Maintenance
**DRAFT**
Doctor Host Maintenance
13 Mar 2016
Tomi Juvonen Nokia

2. Preface
This document proposes APIs needed in host maintenance by admin and VM owner. Document also proposes the needed flow.
This document does not describe the notifications details. Also document do not describe any admin actions done during maintenance. Also as use case concentrating on whole compute host maintenance.

3. OpenStack current state
Nova
Has maintenance flag and reason.
API to enable/disable (allow/disallow VM scheduling for a host)
Service status notification (Admin).
API for owner/admin to see host state VM specifically (owner ability needs policy change for default configuration in /etc/nova/policy.json). This will be documented in OPNFV Doctor.
As with host fault monitoring and actions, not expected more control over maintenance either. This means Inspector should play the main role and it is also the most natural place.

4. Host maintenance use cases
Admin cases.
Put host to maintenance.
Enable host after maintenance.
Remove host.
VM owner cases.
Owner wants to move VM to another host.
Owner wants to remove VM and add new.
Owner wants to keep VM on same host.
Note! As of host fault management it is expected predicted faults are caught by Admin, so he can put host to maintenance.

5. Doctor Maintenance enable (or host removal) flow
Conf.
Conf. 1. 2.
Admin
Inspector
Controller
Notifier
Owner 3. 4. 5. 6.
Maintenance enable for specific host.
Maintenance enable to controller and service status notification.
Notification to owner about maintenance enable for specific VMs. Might want to pass allowed actions for VMs configured?!
Owner ack/nack for maintenance enable with actions (Owner do not make actions to existing VMs on host to avoid actions done in two places and making flow more complex. Actions only done by the Inspector to get result directly. Owner can still make create new VM as he wants, as not directly part of maintenance).
Actions for VMs if needed. Disable maintenance if nack on 4. or if VM actions fail.
Ready for maintenance notification or cancel with reason if 4. or 5. nack.

6. Doctor Maintenance disable flow
Conf.
Conf. 1.
Inspector 2.
Admin
Controller
Notifier 3.
Owner 4.
Maintenance disable for specific host.
Maintenance disable to controller and service status notification.
if VMs were left on host during maintenance, send notification to owner about maintenance disabled and VMs coming back up.
Actions for VMs if needed (probably VMs configured to boot up automatically -> not needed step).

7. [Proposal] Doctor Inspector Maintenance Admin API
URI:
maintenance:
start_time  Maintenance start time (at least some minutes in future)
end_time  Maintenance expected end time
timeout  Timeout in seconds to get ack from VM owners that they are ready, or maintenance needs to be canceled.
action  Maintenance or host removal:
“MAINTENANCE”
“HOST_REMOVAL”
host  Host to put to maintenance
target_host  This is optional target where VMs are to be moved {
‘maintenance’: {
‘start_time’: ‘ T13:27: ’,
‘end_time’: ‘ T14:27: ’,
‘timeout’: 300
‘action’: ‘MAINTENANCE’,
‘host’: ‘compute-1’,
‘target_host’: ‘compute-2’, }

8. [Proposal] Doctor Inspector Maintenance VM owner API
URI:
maintenance_response:
project_id  owner
maintenance-id  ID gotten from maintenance notification to map response to Inspector internal maintenance session.
ready  true/false if owner ready for action requested
actions:  This contains optional allowed actions for VMs that translates to Nova API: /v2.1/​{tenant_id}​/servers/​{server_id}​/action This might be needed as Nova policy.json do not allow all actions for VM owner, but action should be run by Inspector using admin privileges. {
‘maintenance_response’: {
‘project_id’: ‘cf674c50-eb9d-…-1e82f7391c73’,
‘maintenance_id’: ‘b8b357f7….c922ef93’,
‘ready’: true,
‘actions’: {
‘vm1’ : [‘os-migrateLive’,’evacuate’],
‘vm2’ : [],
‘vm3’ : [remove,], }