Open Stack

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.fossdev at gmail.com>;
> *Date: * Mon, Nov 19, 2018 10:26 PM
> *To: * "OpenStack Developmen"<openstack-dev at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev