[RFE] using ETAG headers would improve API usability

[aeva black]

Ironic's REST API does not currently return an ETAG (*) ID in the headers of any responses. Doing so would improve the usability of the API by allowing clients to quickly and easily determine if a resource changed since the last time that client interacted with it (eg, because another client modified it). Sending ETAGs in request headers would also allow the Ironic service to prevent the "lost update problem" (*) and begin using POST in places where we currently only support PATCH requests.

The OpenStack API WG recommends that this header be included by all services.

(*) https://github.com/openstack/api-wg/blob/master/guidelines/etags.rst

[Dmitry Tantsur (divius)]

I'll be all for just approving this RFE, but let's state how the ETAG will be calculated. Also I'm not sure about "using POST instead of PATCH" bit. The cross-project spec talks about PUT. And anyway I can imagine ETAGs useful with PATCH as well (anything updating capabilities would really appreciated it, e.g. ironic-inspector).

[Jim Rollenhagen (jim-rollenhagen)]

This should have a quick spec anyway as it affects the API.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/381991

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/392213

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/381991
Committed: https://git.openstack.org/cgit/openstack/ironic-specs/commit/?id=d00bccf7629a4dc4dbb93172f00be10cc02c7444
Submitter: Jenkins
Branch: master

commit d00bccf7629a4dc4dbb93172f00be10cc02c7444
Author: Devananda van der Veen <email address hidden>
Date: Tue Oct 4 10:06:05 2016 -0700

    API Evolution - ETAG identifiers

    This specification describes the implementation of ETAG identifiers.

    This patch is part of a series of patches which propose several
    discrete units of work, broken out into separate specifications for
    tracking. These have grown out of the discussions around whether
    we should have a 'v2' API, and what current pain-points we all
    experience with the current API. It is my belief, after
    investigating all of the collected concerns, that we can implement
    many of the desired changes incrementally and without a
    full 'v2' rewrite.

    Change-Id: Id8dc039fbf56f7e74dd79256b7a223f6eb673ad2
    Related-bug: #1605728