Alexander ran into some technical problems working on the implementation, so we reconsidered. Here's the correspondence with the Searchlight PTL about this bug:
On 10/17/16, 5:59 PM, "Brian Rosmaita" wrote: Hi Steve, We have a discussion going on around the proposed change to updated_at in the image response [0]. Steve (Lewis) feels (not un-rightly) that changing updated_at when the representation itself hasn't changed is un-RESTful. I thought I had a decent argument to the contrary until Alex pointed out that we aren't modifying the updated_at when there's a change in member_status, and while I thought it was OK to change updated_at on the image when the member_list changed, when we get down to the member level it seems a bit icky even though consistency would compel me to say, yes, we should change it. (Additionally, there is a technical problem related to the context in which a member_status changes that will make it difficult to update the image anyway.) So, my questions for you are: (1) does Searchlight need the updated_at to change when member_status changes (from 'pending' to 'accepted', for instance)? (2) is there another way to achieve the result Searchlight needs without modifying the image's updated_at? We need to explore the situation a bit more. thanks, brian [0] https://bugs.launchpad.net/glance/+bug/1547079 On 10/18/16, 3:21 PM, "McLellan, Steven" wrote: Hi Brian, TLDR: if it's contentious, we can live with it. My feeling on 'the representation hasn't changed' is that the member list IS part of the representation in the sense that the member list is absolutely an attribute of "an image", and the fact that essentially because the member list is a separate SQL table it became a separate REST endpoint is an implementation detail. That said, I can see the Steve's point of view that since it IS a separate entity in a RESTy sense, it shouldn't be diddling with image properties. Our workaround is to retrieve the image (and members) from glance and do an unconditional save (ignoring timestamps). We only consider 'accepted' image members since we use it primarily for RBAC, so image member state changes have no impact. The vast likelihood is that it takes longer to get the image from Glance than the timeframe in which race conditions can occur, and since it's a relatively uncommon operation there's probably no performance impact. HTH! Steve ** Changed in: glance Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1547079 Title: image not updated on image member change Status in Glance: Won't Fix Bug description: When an image member is added to/deleted from an image, the updated_at time of the image does not change. This is misleading because image membership affects image behavior, in particular, whether an image is visible to (can be booted by) a particular user. Even though the image member-list is not part of the GET v2/images/{image_id} response, *something* about the image has changed, and the updated_at timestamp should reflect this fact. (This is causing problems for Searchlight, it's not a purely academic discussion.) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1547079/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
