ec9d5e375e
ImageCacheManager deletes base image while image backend is copying image to the instance path leading instance to go in the error state. Acquired lock before removing image from cache. If libvirt is copying image to the instance path, image cache manager won't be able to remove it until libvirt finishes copying image completely. Closes-Bug: 1256838 Closes-Bug: 1470437 Co-Authored-By: Michael Still <mikal@stillhq.com> Depends-On: I337ce28e2fc516c91bec61ca3639ebff0029ad49 Change-Id: I376cc951922c338669fdf3f83da83e0d3cea1532
13 lines
674 B
YAML
13 lines
674 B
YAML
---
|
|
upgrade:
|
|
- Upgrade the rootwrap configuration for the compute service,
|
|
so that patches requiring new rootwrap configuration can be
|
|
tested with grenade.
|
|
fixes:
|
|
- In a race condition if base image is deleted by ImageCacheManager
|
|
while imagebackend is copying the image to instance path, then the
|
|
instance goes in to error state. In this case when libvirt has
|
|
changed the base file ownership to libvirt-qemu while imagebackend
|
|
is copying the image, then we get permission denied error on updating
|
|
the file access time using os.utime. Fixed this issue by updating the
|
|
base file access time with root user privileges using 'touch' command. |