Open Stack

On 8/2/2019 3:53 AM, Budai Laszlo wrote:
> 1. configure Nova to use local LVM storage (images_types = lvm) - provided the best performance, but we could not migrate our instances (seems to be a bug).

Yes it's a known bug:

https://bugs.launchpad.net/nova/+bug/1831657

As noted within that bug report, WindRiver had a patch at one point to 
make that work but it's long out of date, someone would have to polish 
it off and get it working again.

The good news is we have a nova-lvm CI job which is currently skipping 
resize tests but in the patch that implements migrate for lvm we could 
unskip those tests and make sure everything is working in that nova-lvm 
CI job. We just need contributors that care about it to do the work 
(there seem to be several people that want this, but a dearth of people 
actually making it happen).

> 2. use cinder with lvm backend  and instance locality, we could migrate the instances, but the performance is less than half of the previous case

I could dredge up the ML thread on this but while this is an option, (or 
even using the now-either-deprecated-or-deleted cinder local block 
volume type driver), it could quickly become a management nightmare 
since enforcing compute/volume locality with availability zones becomes 
a mess at scale. If you only have a half dozen computes or something 
then maybe that's not a problem in a private cloud shop, but it's 
definitely a problem at larger scale, and also complicated if you set 
the [cinder]cross_az_attach=False value in nova.conf because of known 
bugs [1] with that.

[1] https://bugs.launchpad.net/nova/+bug/1694844 - yes I'm a bad person 
for not having cleaned up that patch yet but I haven't felt much urgency 
either.

-- 

Thanks,

Matt