Re: [openstack-dev] [glance] about use shared image with each other
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"; > *Date: * Mon, Nov 19, 2018 10:26 PM > *To: * "OpenStack Developmen"; > *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://wik
Re: [openstack-dev] [glance] about use shared image with each other
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? -- Original -- From: "Brian Rosmaita"; Date: Mon, Nov 19, 2018 10:26 PM To: "OpenStack Developmen"; 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
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-dev] [glance] about use shared image with each other
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? 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. Can you tell me more about this?Thank you very much! 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
