On 26/07/16 14:32 +0300, Mikhail Fedosin wrote:
Hello!As you may know glance v1 is going to be deprecated in Newton cycle. Almost all projects support glance v2 at this moment, Nova uses it by default. Only one thing that blocks us from complete adoption is a possibility to set custom locations to images. In v1 any user can set a location to his image, but in v2 this functionality is not allowed by default, which prevents v2 adoption in services like Horizon or Heat. It all happens because of differences between v1 and v2 locations. In v1 it is pretty easy - user specifies an url and send a request, glance adds this url to the image and activates it. In v2 things are more complicated: v2 supports multiple locations per image, which means that when user wants to download image file glance will choose the best one from the list of locations. It leads to some inconsistencies: user can add or delete locations from his image even if it is active. To enable adding custom locations operator has to set True to config option 'show_multiple_locations'. After that any user will be able to add or remove his image locations, update locations metadata, and finally see locations of all images even if they were uploaded to local storage. All this things are not desired if glance v2 has public interface, because it exposes inner cloud architecture. It leads to the fact that Heat and Horizon and Nova in some cases and other services that used to set custom locations in glance v1 won't be able to adopt glance v2. Unfortunately, removing this behavior in v2 isn't easy, because it requires serious architecture changes and breaks API. Moreover, many vendors use these features in their clouds for private glance deployments and they really won't like if we break anything. So, I want to hear opinions from Glance community and other involved people.
I agree the current situation is not ideal but I don't think there's a perfect solution that will let other services magically use the location's implementation in v2. The API itself is different and it requires a different call. With that in mind, I think the right thing to do here is to get rid of that option[0] and let operators manage this through poilicies. This does not mean the policies available are perfect. I'm not an expert on service tokens but I think we said that we could probably just use service tokens to allow for this feature to be used by other services instead of keeping it wide open everywhere. While I don't think the current situation is ideal, I think it's better than keeping it wide open. Hope the above helps, Flavio [0] https://review.openstack.org/#/c/313936/
Best regards, Mikhail Fedosin
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
