Open Stack

On 7/26/2017 11:23 AM, Matt Riedemann wrote:
> 
> Given this, what else do you need? Please be clear about what your use 
> case is and how it is not solved using the 2.53 microversion. There may 
> need to be changes to the CLI but let's separate that concern from the 
> REST API changes.

I think your issue might be with these commands which use the 
hypervisors.search python API binding in novaclient:

1. nova host-meta # Set or Delete metadata on all instances of a host.
2. nova host-evacuate # Evacuate all instances from failed host
3. nova host-evacuate-live # Live migrate all instances of the specified 
host (we should really rename this command since it doesn't 'evacuate' 
it live migrates)
4. nova host-servers-migrate # Cold migrate all instances off the 
specified host

The risk with any of these is on the hostname match hitting more 
hypervisors than you wanted or expected. So if I have 10 computes in a 
London region in data center 1 named something like 
london.dc1.compute1.foo.bar, london.dc1.compute2.foo.bar, etc, and I do:

nova host-evacuate london.dc1

It's going to match all of those and evacuate instances from all of 
those dc1 computes in my london region at once, obviously probably not 
something you want, unless dc1 is being attacked by Harry Potter fans 
and you need to get those instances to another data center.

The solution here is you specify the fully qualified domain name for the 
host you want to evacuate:

nova host-evacuate london.dc1.compute1.foo.bar

Right? What am I missing here?

If you wanted to change the CLI to be more strict, we could do that by 
just adding a --strict_hostname option or something and fail if we get 
back more than one host, as a way to guard the operator from making a 
mistake.

But none of this sounds like changes that need to be done in the REST 
API, and arguably isn't a bug in the CLI either.

-- 

Thanks,

Matt