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" <fla...@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-requ...@lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >-- >@flaper87 >Flavio Percoco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
