Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160727/1880548d/attachment.pgp>