[openstack-dev] [ironic] User survey question

Galyna Zholtkevych gzholtkevych at mirantis.com
Thu Jan 5 15:32:24 UTC 2017


Hello,

I would like to use this opportunity upcoming to decide things related to
one of features that I am implementing.

To prevent lost-update problem, the user in the next Ironic API versions
will have the ability to use the entity tag for each resource.
Thus, in order to send conditional request he has to have at least some
representation on client side.

So there is a question on how to implement better storing resource (with
ETAG) representation in ironic CLI (see
https://review.openstack.org/#/c/381991/)

The proposals are following, I will specify some in the spec:

- During update send get and afterwards update with current representation
(descreases performance and changes the general behaviour, but hides the
behaviour from user)

- Force user to do ``ironic node-show <node>`` and afterwards he will do
update
putting entity tag manually

- Or he may be advised to do sth like

``node=$(ironic node-show <node>)``

and then he can send sth like

``ironic node-update $node``and resource will call manager and update
itself (doing it through the resource is the similar way in
python-novaclient for some requests).

In these two last cases user is forced again to do additional actions to
perform a simple command. Need to be discussed if it is a good way to
change behaviour like that


- Cache resource representation at client side using e.g. requests-cache

- Cache resource representation at ironic api middleware (or contribute
caching to pecan to make it available for other projects)

There are many conflicting opinions basically on this question, so need to
be decided in which direction to go, and what is the most reasonable,
standard, logical manner.

Thank you for comments in advance.



Best regards,
Galyna Zholtkevych
Mirantis Inc

IRC nickname:galyna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170105/80ab324a/attachment.html>


More information about the OpenStack-dev mailing list