<div>yes, but I also have a question, Do we have the quota limit for requests to share the image to each other? For example, someone shares the image with me without stop, how do we deal with it?</div><div><includetail><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Brian Rosmaita"<rosmaita.fossdev@gmail.com>;</div><div><b>Date: </b> Mon, Nov 19, 2018 10:26 PM</div><div><b>To: </b> "OpenStack Developmen"<openstack-dev@lists.openstack.org>; <wbr></div><div></div><div><b>Subject: </b> Re: [openstack-dev] [glance] about use shared image with each other</div></div><div> </div><div style="position:relative;">On 11/19/18 7:58 AM, Rambo wrote:<br>> Hi,all<br>> <br>>      Recently, I want to use the shared image with each other.I find it<br>> isn't convenient that the producer notifies the consumer via email which<br>> the image has been shared and what its UUID is. In other words, why the<br>> image api v2 is no provision for producer-consumer communication?<br><br>The design goal for Image API v2 image sharing was to provide an<br>infrastructure for an "image marketplace" in an OpenStack cloud by (a)<br>making it easy for cloud end users to share images, and (b) making it<br>easy for end users not to be spammed by other end users taking advantage<br>of (a).  When v2 image sharing was introduced in the Grizzly release, we<br>did not want to dictate how producer-consumer communication would work<br>(because we had no idea how it would develop), so we left it up to<br>operators and end users to figure this out.<br><br>The advantage of email communication is that client side message<br>filtering is available for whatever client a particular cloud end-user<br>employs, and presumably that end-user knows how to manipulate the<br>filters without learning some new scheme (or, if the end-user doesn't<br>know, learning how to filter messages will apply beyond just image<br>sharing, which is a plus).<br><br>Also, email communication is just one way to handle producer-consumer<br>communication.  Some operators have adjusted their web interfaces so<br>that when an end-user looks at the list of images available, a<br>notification pops up if the end-user has any images that have been<br>shared with them and are still in "pending" status.  There are various<br>other creative things you can do using the normal API calls with regular<br>user credentials.<br><br>In brief, we figured that if an image marketplace evolved in a<br>particular cloud, producers and consumers would forge their own<br>relationships in whatever way made the most sense for their particular<br>use cases.  So we left producer-consumer communication out-of-band.<br><br>>       To make it is more convenient,  if we can add a task to change the<br>> member_status from "pending" to "accepted" when we share the image with<br>> each other. It is similar to the resize_confirm in Nova, we can control<br>> the time interval in config.<br><br>You could do this, but that would defeat the entire purpose of the<br>member statuses implementation, and hence I do not recommend it.  See<br>OSSN-0005 [1] for more about this issue.<br><br>Additionally, since the Ocata release, "community" images have been<br>available.  These do not have to be accepted by an end user (but they<br>also don't show up in the default image-list response).  Who can<br>"communitize" an image is governed by policy.<br><br>See [2] for a discussion of the various types of image sharing currently<br>available in the Image API v2.  The Image Service API v2 api-ref [3]<br>contains a brief discussion of image visibility and image sharing that<br>may also be useful.  Finally, the Glance Ocata release notes [4] have an<br>extensive discussion of image visibility.<br><br>>        Can you tell me more about this?Thank you very much!<br><br>The original design page on the wiki [5] has a list of 14 use cases we<br>wanted to address; looking through those will give you a better idea of<br>why we made the design choices we did.<br><br>Hope this helps!<br><br>cheers,<br>brian<br><br>[0]<br>http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html<br>[1] https://wiki.openstack.org/wiki/OSSN/1226078<br>[2]<br>http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html<br>[3] https://developer.openstack.org/api-ref/image/v2/<br>[4] https://docs.openstack.org/releasenotes/glance/ocata.html<br>[5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing<br><br><br>> <br>> Best Regards<br>> Rambo<br>> <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>> <br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div></div><!--<![endif]--></includetail></div>