<div dir="ltr">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. <div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 5:33 PM <<a href="mailto:stuart.mclaren@hp.com">stuart.mclaren@hp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mike,<br>
<br>
Here's my $0.02 on setting locations directly:<br>
<br>
I think there will always be some (probably public cloud) operators who<br>
are wary of allowing regular users to do this. For this reason,<br>
and also because the API calls are backend specific (setting location<br>
isn't supported for a filesystem backend [1]), my guess is it's unlikely that<br>
API calls for setting locations directly will become part of DefCore.<br>
<br>
In general I'm not a huge fan of setting the image locations directly<br>
because:<br>
<br>
* Any time you allow setting the location directly you're risking the<br>
database and the image data getting out of sync. Eg an 'active' image's<br>
data can be deleted from under it.<br>
* Some ways of setting the locations directly give you images without<br>
a known checksum.<br>
<br>
In my mind, the feature is probably best restricted (by default at least)<br>
to power users (admins) and other services -- eg Cinder can do this<br>
to reduce copying data around in some cases. Existing policies can be<br>
used to restrict to admin; something like service tokens [1] could be<br>
used to allow other services (eg Cinder) to do this on behalf of users,<br>
while preventing users from doing it directly themselves.<br>
<br>
To keep things as inter-operable as possible it might be good to ensure<br>
that services are able to use Glance even if setting locations directly<br>
is completely disabled.<br>
<br>
-Stuart<br>
<br>
[1] <a href="https://review.openstack.org/#/c/141706" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/141706</a><br>
[2] <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html</a><br>
<br>
> Hello!<br>
><br>
> As you may know glance v1 is going to be deprecated in Newton cycle. Almost<br>
> all projects support glance v2 at this moment, Nova uses it by default.<br>
> Only one thing that blocks us from complete adoption is a possibility to<br>
> set custom locations to images. In v1 any user can set a location to his<br>
> image, but in v2 this functionality is not allowed by default, which<br>
> prevents v2 adoption in services like Horizon or Heat.<br>
><br>
> It all happens because of differences between v1 and v2 locations. In v1 it<br>
> is pretty easy - user specifies an url and send a request, glance adds this<br>
> url to the image and activates it.<br>
> In v2 things are more complicated: v2 supports multiple locations per<br>
> image, which means that when user wants to download image file glance will<br>
> choose the best one from the list of locations. It leads to some<br>
> inconsistencies: user can add or delete locations from his image even if it<br>
> is active.<br>
><br>
> To enable adding custom locations operator has to set True to config option<br>
> 'show_multiple_locations'. After that any user will be able to add or<br>
> remove his image locations, update locations metadata, and finally see<br>
> locations of all images even if they were uploaded to local storage. All<br>
> this things are not desired if glance v2 has public interface, because it<br>
> exposes inner cloud architecture. It leads to the fact that Heat and<br>
> Horizon and Nova in some cases and other services that used to set custom<br>
> locations in glance v1 won't be able to adopt glance v2. Unfortunately,<br>
> removing this behavior in v2 isn't easy, because it requires serious<br>
> architecture changes and breaks API. Moreover, many vendors use these<br>
> features in their clouds for private glance deployments and they really<br>
> won't like if we break anything.<br>
><br>
> So, I want to hear opinions from Glance community and other involved<br>
> people.<br>
><br>
> Best regards,<br>
> Mikhail Fedosin<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL:<br>
> <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160726/b97af3b0/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>