Open Stack

On 04/22/2013 12:50 PM, John Garbutt wrote:
> 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...)

Thanks for the writeup!  I think you captured this pretty well.  I do
agree that this is something that should be a consumer of the compute
APIs as opposed to something built-in to nova itself.

> 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.

Of the things that already exist, python-novaclient makes the most
sense.  I'm concerned with the significant scope increase, though.  This
takes novaclient from a fairly straight forward API wrapper library and
cmd line tool to something that orchestrates nova operational
activities.  Maybe that's ok, though.  I'd like to see some more in
depth exploration of how this might be structured so that it's only
exposed to admins and kept somewhat separate from the traditional stuff
in novaclient that is just wrapping the API.

-- 
Russell Bryant