On 26/07/16 15:45 +0000, Fox, Kevin M wrote:
The app catalog has suffered this change too. We had to force v1 in our 
suggested download cli lines to make it work when newer clients defaulted to v2 
and the previously working command line switches suddenly vanished.

As I understand, v2 had a solution to it, but that solution too was deprecated. 
I've heard rumor of a new suggested way of doing it, but I haven't been able to 
find it, so I guess its still cooking.

I'd ask the Glance team to not deprecate v1 until this issue is resolved, as it 
is a very common use case for Glance. I understand the desire to sluff off the 
old and only support a single, new api. But the new api has a big gap in it 
that needs to be fixed first.

To be honest, I don't think this is a blocker for the v1 deprecation. The v1
deprecation has been postponed long enough and I don't think this is a real
blocker. There is indeed a way to allow for services to add locations, which is
enabling it in the config file. I don't mean to oversimplify the work of
changing config files and the cost this has from an operations perspective but
it's not blocking other projects. This option can be set to True in the gate if
necessary.

That being said, I do think we can do better here and that the current state is
not ideal to everyone. I've attempted several times to change this situation but
I believe it was not the right time *shrugs*

Flavio

Thanks,
Kevin
________________________________
From: Mikhail Fedosin [[email protected]]
Sent: Tuesday, July 26, 2016 4:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Glance][Heat][Horizon] Glance v2 and custom locations

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.

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

Attachment: 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

Reply via email to