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