Open Stack

Hi,

We discussed this at the summit. I just wanted to follow up on list.

tl;dr
nova-api operations that work across multiple servers should be
avoided and implemented client side, maybe in python-novaclient, or
some extension thereof.

We were thinking about these kinds of operations, evacuate all servers
on a host:
https://review.openstack.org/#/c/25259/

There are two big use cases:
- current host has died, all data lost
- current host is dying or going into maintenance (e.g. hypervisor upgrade)

What you want to do:
- migrate the server so the user doesn't notice (so live-migrate)
- keep as much data as you can ('cold'-migrate)
- rebuild instance on new host, because you lost the data (evacuate or
'dead'-migrate)

Current the API only supports the above operations action on an
individual server, rather than all servers on a host.

What I think we decided was:
- keep these operations outside nova-api

Reason why:
- keep orchestration out of nova and nova-api
- let the user decide what to do when it goes wrong half way through
- its hard to communicate all the error details if we do all that in nova
- we need to draw a line on how big the API gets (should we do then do
this per aggregate...)

The next question, we didn't really answer:
- Where do we put these operations now, if not in nova-api? How to
share this effort?

My thinking is:
- keep code where we can collaborate and share effort
- easy to call in a similar way to all other commands
- this probably means python-novaclient
- but let's not endlessly grow python-novaclient, such that non-admin
users get confused

So, maybe we put them in python-novaclient, but we look to split out
all operator operations into a separate "plugin" repo that can be
installed by administrators. Long term, we might want the "nova help"
list be dynamic based on the user's token.

Apologies for the length; there is lots of background that I think is useful,
John