Open Stack

Can we have a special way (i.e. restricted) of setting Image locations, to
be used by clients like Horizon (where an end-users create images)? It
would be hard to explain different set of Image Sources depending on their
adminness.

Anoher question that I'm asking myself about Horizon is how affordable
would be the loss of 'URL Image Source', since 'copy-from' is missing for
sure already. Are there many valuable use cases for URL source in absence
of 'copy-from' feature?

On Tue, Jul 26, 2016 at 5:33 PM <stuart.mclaren at hp.com> wrote:

> Hi Mike,
>
> Here's my $0.02 on setting locations directly:
>
> I think there will always be some (probably public cloud) operators who
> are wary of allowing regular users to do this. For this reason,
> and also because the API calls are backend specific (setting location
> isn't supported for a filesystem backend [1]), my guess is it's unlikely
> that
> API calls for setting locations directly will become part of DefCore.
>
> In general I'm not a huge fan of setting the image locations directly
> because:
>
> * Any time you allow setting the location directly you're risking the
> database and the image data getting out of sync. Eg an 'active' image's
> data can be deleted from under it.
> * Some ways of setting the locations directly give you images without
> a known checksum.
>
> In my mind, the feature is probably best restricted (by default at least)
> to power users (admins) and other services -- eg Cinder can do this
> to reduce copying data around in some cases. Existing policies can be
> used to restrict to admin; something like service tokens [1] could be
> used to allow other services (eg Cinder) to do this on behalf of users,
> while preventing users from doing it directly themselves.
>
> To keep things as inter-operable as possible it might be good to ensure
> that services are able to use Glance even if setting locations directly
> is completely disabled.
>
> -Stuart
>
> [1] https://review.openstack.org/#/c/141706
> [2]
> https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html
>
> > 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
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> > <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.html
> >
> >
> > ------------------------------
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/00840aa0/attachment.html>