yahoo-eng-team team mailing list archive

[Nikhil Komawar <nik.komawar@xxxxxxxxx>]

@Lyle: are you using the schemas to validate your request?

I see how a 409 is more convenient.

I'm on the fence for this -- my opinion is that 403 is the right call
from glance's perspective as you are trying to update the reserved
attribute and have some knowledge of the image (using the id).

Though, at the same time for a `save` in your case makes sense to first
check for id and then for other attributes. So, we will have to discuss
this on the review itself. If you'd like to propose a review on this, it
would be quite helpful.

** Changed in: glance
       Status: New => Opinion

** Changed in: glance
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1611154

Title:
  Glance v2 gives 403 instead of 409 on Conflict

Status in Glance:
  Opinion

Bug description:
  Background:

  I'm working on fixing some issues around the handling of Glance V2 in
  the Ruby fog-openstack gem: https://github.com/fog/fog-
  openstack/pull/170. One of these issues was the implementation of a
  `save` method that creates an object if it doesn't exist, otherwise it
  updates the object. Normally the presence of an ID causes the `update`
  method to be called, but Glance V2 allows an ID to be specified on
  `create`. To implement this `save` method, I'd like to always call
  `create`, then rescue and call `update` on a 409 Conflict. However,
  I'm seeing the following behavior.

  Bug:

  Attempt to POST a new image with an conflicting ID (ID already
  exists), but with a read-only attribute set, e.g. `self`.

  ```
  curl -v \
    -H "Content-Type: application/json" \
    -H "X-Auth-Token: MY_TOKEN" \
    -X POST \
    -d '{
      "id": "EXISTING_IMAGE_ID",
      "name": "my-image",
      "self": "/v2/foo"
    }' \
    https://OPENSTACK_HOSTNAME:9292/v2/images
  ```

  Expected to receive "409 Conflict" HTTP response, but was "403
  Forbidden", "Attribute 'self' is read-only.". Removing the `self` from
  the request makes things work as expected, but the lack of the 409
  response code makes it difficult to implement a "create or update"
  method as described above.

  Thanks!

  - Lyle

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1611154/+subscriptions