yahoo-eng-team team mailing list archive

[Brian Rosmaita <brian.rosmaita@xxxxxxxxxxxxx>]

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