Open Stack

Sorry guys, I'm a little late responding to this topic.

>From a Horizon perspective, it would help if there were an API to discover
whether custom locations are off or on in a Glance v2 installation. We
could then expose it to the user only if it's enabled.

What we've done to prevent this from being a blocker to v2 adoption so far
is add a config value in Horizon that allows an operator to turn it off
explicitly [0], but that requires operators to turn it on/off in 2
services separately.

[0] https://review.openstack.org/#/c/320039/

Thanks,
Brad

On 7/27/16, 5:08 AM, "Flavio Percoco" <flavio at redhat.com> wrote:

>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