4. The primary use case of image-locations is for operators to specify fully customized (with glance's location comprehension constraints) for being able to specify those that are near to some services like nova (using v2). This is to boost boot times and reduce network lags and errors. Will the admins be able to set the image location as they find convenient?
5. What will happen to existing images in the DB that were stored by specifying a image location that contains identifier that's not image id?
Hi, I just read through the bug (as I was not involved earlier). I think we need to define what the exact workflow is being proposed here.
It seems like we need to clarify in one complete outline of the proposal the following things:
1. two non-default config options need to be enabled for v2, single location can always be set for v1?
2. some policy changes in the source tree that will restrict access to regular users (including project admins?) (for both v1 and v2?)
3. Nova uses (v1) direct access to locations in libvirt driver ( https:/ /github. com/openstack/ nova/blob/ 824c3706a3ea691 781f4fcc4453881 517a9e1c55/ nova/virt/ libvirt/ imagebackend. py#L967 and https:/ /github. com/openstack/ nova/blob/ 824c3706a3ea691 781f4fcc4453881 517a9e1c55/ nova/virt/ libvirt/ driver. py#L1517 )
Is setting default policy to be restrictive going to break this for those users?
4. The primary use case of image-locations is for operators to specify fully customized (with glance's location comprehension constraints) for being able to specify those that are near to some services like nova (using v2). This is to boost boot times and reduce network lags and errors. Will the admins be able to set the image location as they find convenient?
5. What will happen to existing images in the DB that were stored by specifying a image location that contains identifier that's not image id?