)]}'
{"id":"openstack%2Fapi-sig~234994","triplet_id":"openstack%2Fapi-sig~master~I7e61fff8f5efaada5cae0c48d6acb26613e4cfc3","project":"openstack/api-sig","branch":"master","topic":"actions","hashtags":[],"change_id":"I7e61fff8f5efaada5cae0c48d6acb26613e4cfc3","subject":"Actions guideline","status":"ABANDONED","created":"2015-10-14 21:57:08.000000000","updated":"2016-06-02 16:08:45.000000000","total_comment_count":21,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"c3b210cb4ca2135dfa3b3638773da31fff8618bc","_number":234994,"virtual_id_number":234994,"owner":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"actions":{},"labels":{"Verified":{"recommended":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"all":[{"date":"2016-01-18 16:30:37.000000000","_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},{"value":1,"date":"2015-10-14 22:22:56.000000000","_account_id":3,"name":"Jenkins","username":"jenkins"},{"date":"2015-10-22 23:13:15.000000000","_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},{"date":"2016-01-18 17:24:17.000000000","_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},{"date":"2015-10-15 10:31:20.000000000","_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},{"_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},{"date":"2016-01-18 15:04:47.000000000","_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},{"_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},{"date":"2016-05-17 03:03:30.000000000","_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"date":"2015-10-16 00:24:33.000000000","_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","value":1,"default_value":0,"optional":true},"Code-Review":{"recommended":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"disliked":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},{"value":-1,"date":"2015-10-22 02:13:50.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},{"value":-1,"date":"2016-01-15 19:12:21.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":3,"name":"Jenkins","username":"jenkins"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},{"value":-1,"date":"2016-01-15 17:03:23.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},{"value":1,"date":"2015-10-15 13:44:45.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},{"value":-1,"date":"2016-05-10 16:20:47.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","value":-1,"default_value":0,"optional":true},"Workflow":{"rejected":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"all":[{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},{"date":"2016-05-22 20:13:48.000000000","_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},{"_account_id":3,"name":"Jenkins","username":"jenkins"},{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":-1,"date":"2016-05-10 17:23:34.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},{"date":"2015-10-22 20:35:50.000000000","_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},{"date":"2016-05-17 15:15:22.000000000","_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},{"date":"2015-10-26 01:38:27.000000000","_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},{"date":"2015-12-07 15:50:04.000000000","_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},{"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},{"date":"2016-01-27 15:59:11.000000000","_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":-1,"max":0},"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":3,"name":"Jenkins","username":"jenkins"},{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},{"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},{"_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2015-10-14 22:22:56.000000000","updated_by":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"reviewer":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"state":"REVIEWER"},{"updated":"2015-10-15 10:31:20.000000000","updated_by":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"reviewer":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"state":"REVIEWER"},{"updated":"2015-10-15 13:44:45.000000000","updated_by":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"reviewer":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"state":"REVIEWER"},{"updated":"2015-10-22 02:13:50.000000000","updated_by":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"reviewer":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"state":"REVIEWER"},{"updated":"2015-10-22 20:35:50.000000000","updated_by":{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},"reviewer":{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},"state":"REVIEWER"},{"updated":"2015-10-22 23:13:15.000000000","updated_by":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"reviewer":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"state":"REVIEWER"},{"updated":"2015-10-26 01:38:27.000000000","updated_by":{"_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},"reviewer":{"_account_id":9459,"name":".Haifeng Yan","email":"yanheven@qq.com","username":"yan"},"state":"REVIEWER"},{"updated":"2015-12-07 15:50:04.000000000","updated_by":{"_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},"reviewer":{"_account_id":12053,"name":"Hua Wang","email":"wanghua.humble@gmail.com","username":"humble00"},"state":"REVIEWER"},{"updated":"2016-01-15 19:12:21.000000000","updated_by":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"reviewer":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"state":"REVIEWER"},{"updated":"2016-01-18 15:04:47.000000000","updated_by":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"reviewer":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"state":"REVIEWER"},{"updated":"2016-01-18 16:30:37.000000000","updated_by":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"reviewer":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"state":"REVIEWER"},{"updated":"2016-01-18 17:24:17.000000000","updated_by":{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},"reviewer":{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},"state":"REVIEWER"},{"updated":"2016-01-27 15:59:11.000000000","updated_by":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"reviewer":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"state":"REVIEWER"},{"updated":"2016-05-10 17:23:34.000000000","updated_by":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"reviewer":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"state":"REVIEWER"},{"updated":"2016-05-17 03:03:30.000000000","updated_by":{"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},"reviewer":{"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},"state":"REVIEWER"},{"updated":"2016-05-17 15:15:22.000000000","updated_by":{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},"reviewer":{"_account_id":11536,"name":"hongbin","email":"hongbin034@gmail.com","username":"hongbin"},"state":"REVIEWER"},{"updated":"2016-05-22 20:13:48.000000000","updated_by":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"reviewer":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"state":"REVIEWER"}],"messages":[{"id":"55746e144c0257a386ff9a35e040a4504bae399c","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-10-14 21:57:08.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"93457dbd4d771b5da580c5209a820a0503014eaa","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2015-10-14 22:05:05.000000000","message":"Patch Set 1: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see http://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n- gate-api-wg-docs http://docs-draft.openstack.org/94/234994/1/check/gate-api-wg-docs/d917345//doc/build/html/ : SUCCESS in 2m 07s\n- gate-api-wg-python27 http://logs.openstack.org/94/234994/1/check/gate-api-wg-python27/00ad6d3/ : FAILURE in 2m 07s","accounts_in_message":[],"_revision_number":1},{"id":"2099ee37e1529cbc170ff7d537368b83b35744e3","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-10-14 22:07:37.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"a9b496c9dcd5a96577bed769bd202280e7192039","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2015-10-14 22:22:56.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- gate-api-wg-docs http://docs-draft.openstack.org/94/234994/2/check/gate-api-wg-docs/16420c9//doc/build/html/ : SUCCESS in 2m 12s\n- gate-api-wg-python27 http://logs.openstack.org/94/234994/2/check/gate-api-wg-python27/31a5ce5/ : SUCCESS in 2m 05s","accounts_in_message":[],"_revision_number":2},{"id":"4e5494546423a1ce7cedb9dcff333cb60935b60d","author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"date":"2015-10-14 22:41:57.000000000","message":"Patch Set 2: Code-Review+1\n\nthanks Miguel, i really like this.","accounts_in_message":[],"_revision_number":2},{"id":"a659c4780260c99ed8e899c0252d74479b374376","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2015-10-15 10:31:20.000000000","message":"Patch Set 2:\n\nI have very mixed feelings about this so can\u0027t really vote without further discussion. I suspect much of my doubt is dogmatic so I\u0027d love to be swayed with some good argument.\n\nOn the pro side this is _much_ better than the verby URLs example provided, for all the reasons stated that way is no good.\n\nOn the con side, the proposed method is effectively SOAP in REST clothing: we create an endpoint on which we can pass encapsulated methods and their arguments. The fact that it is a per-resource endpoint is better than /actions at root but it is still problematic.\n\nWhat I would like to see is a statement of why this is better than sending some represented state to /api/servers/123 (via probably POST)?\n\nAnother alternative that I would want to see dismissed in some clean fashion is resources which take other resources as args. For example /api/rebooter to which a list of servers can be posted (note the intentional use of a noun instead of verb).","accounts_in_message":[],"_revision_number":2},{"id":"5c64beaecbc0bb94bbed784bc3ba6a475d09583e","author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"date":"2015-10-15 13:44:45.000000000","message":"Patch Set 2: Code-Review+1","accounts_in_message":[],"_revision_number":2},{"id":"ef570c29f1776e5b0ae9e75121dd7b29c3a96f0e","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-10-16 00:24:33.000000000","message":"Patch Set 2:\n\nChris, good questions.\n\n\u003e On the con side, the proposed method is effectively SOAP in REST clothing\n\nI need to say that this implementation I proposed is not what I would do if I were king and dictator. But I consider it a decent compromise. I think we try to think of actions as resources, I disagree that this is SOAP disguised as REST. In an ideal implementation that includes the optional GET/PUT/DELETE in addition to POST, actions are actually stored in the database and can be queried. For example, you could get the history of reboots, etc. that happened on a server.\n\n\u003e What I would like to see is a statement of why this is better than sending some represented state to /api/servers/123 (via probably POST)?\n\nThe only thing you can send to /servers/123 is a server representation. Going back to me being king, my preferred implementation would be to trigger actions indirectly via changing the state of the target resource, but I doubt that would ever fly in OpenStack.\n\n\u003e Another alternative that I would want to see dismissed in some clean fashion is resources which take other resources as args.\n\nThis is an interesting feature. Passing a resource as an argument is easy, you just pass the URL. I think the current proposal could be extended with another endpoint, say /servers/actions (i.e. actions for the collection instead of the individual resource). The body of the requests going into this endpoint would have the same fields as the individual action resources, plus the list of resources the action should be executed on. If there is interest in having this option I think this option is consistent with the proposal.","accounts_in_message":[],"_revision_number":2},{"id":"ae9100b474ab80ab07a136968544700234bf3a18","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2015-10-16 10:43:05.000000000","message":"Patch Set 2:\n\n\u003e Chris, good questions.\n\nThanks. I think this guideline may be one of the most interesting/important ones that we produce so I hope we can get it right (while also not being shy about letting it evolve).\n\n\u003e In an ideal implementation that includes the optional GET/PUT/DELETE in addition to POST, actions are actually stored in the database and can be queried. For example, you could get the history of reboots, etc. that happened on a server.\n\nThat would be cool but it is hard to imagine people actually choosing to implement that any time soon. I can imagine howls of \"we already store too much stuff\".\n\n\u003e The only thing you can send to /servers/123 is a server representation. Going back to me being king, my preferred implementation would be to trigger actions indirectly via changing the state of the target resource, but I doubt that would ever fly in OpenStack.\n\nYes, this is what I meant. Why can\u0027t we do that? What is the objection from the commonweal that means it won\u0027t fly? It is the canonical correct thing, everything else is a workaround.\n\nAn objection I\u0027ve heard is that people don\u0027t want to send around _the_ representation all the time. That, to me, indicates that people have an incomplete definition of \"representation\". It is completely reasonable to send _a_ representation and for that particular representation to be something other than the serialized server-side object. It could be applicaiton/vnd.openstack-server-state+json or some such hooey. The reluctance to use media types is concerning.\n\nI think if we\u0027re going to push this guideline we should state the idea and then work backwards from there to the compromise position, not start at the compromise position.\n\nThis is an interesting feature. Passing a resource as an argument is easy, you just pass the URL. I think the current proposal could be extended with another endpoint, say /servers/actions (i.e. actions for the collection instead of the individual resource). The body of the requests going into this endpoint would have the same fields as the individual action resources, plus the list of resources the action should be executed on. If there is interest in having this option I think this option is consistent with the proposal.\n\nYeah, I still don\u0027t like this because of \"actions\". I don\u0027t want to put the method in the body of the request. That\u0027s the part, to me, that is soap in rest clothing. I want to tell the /rebooter that these servers should be rebooted.\n\n(Again, not objecting to the proposal just making conversation to find the right ground.)","accounts_in_message":[],"_revision_number":2},{"id":"8ea9e8a64a3337faa2f91cc20e7ccc474fb54d47","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-10-16 21:11:47.000000000","message":"Patch Set 2:\n\nChris, while in principle I agree with you, the problem I see with the /rebooter idea is that you will end up having lots of these, since reboots are just one of many actions that need to be supported. I don\u0027t know how you can escape the proliferation of non-resource URLs without having the intended action as part of the body.","accounts_in_message":[],"_revision_number":2},{"id":"6b1d5b8f6dccec6a979bcdf049969d96ce881bd1","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2015-10-19 11:20:56.000000000","message":"Patch Set 2:\n\n\u003e Chris, while in principle I agree with you, the problem I see with the /rebooter idea is that you will end up having lots of these, since reboots are just one of many actions that need to be supported. I don\u0027t know how you can escape the proliferation of non-resource URLs without having the intended action as part of the body.\n\nYeah, I\u0027m not too excited about the /rebooter idea either, I just think of it as an option (but not a great one) that needs to be clearly dismissed so that the guideline is complete.\n\nI continue, however, to think that sending a representation that indicates state to /api/servers/123 is the canonically correct way to do things (this is the idea that you\u0027ve said won\u0027t fly in the openstack environment) and that we need to propose that and then kill it (if necessary) with whatever injections of reality are required.","accounts_in_message":[],"_revision_number":2},{"id":"877346b4e644dcd1b1fb709b11ae0d79bbacac60","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-10-19 17:18:50.000000000","message":"Patch Set 2:\n\nChris, a few months ago I proposed the \"actions as state\" solution when someone from the glance team proposed something like `/images/123/deactivate`. It didn\u0027t go well, there was big push back, they did not want to expand the state of the resource.","accounts_in_message":[],"_revision_number":2},{"id":"b93b477b903fd09fba6a6c67e8a577db60f875ed","author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"date":"2015-10-22 02:13:50.000000000","message":"Patch Set 2: Code-Review-1\n\nIt seems to me that if a proper ReST implementation is preferred (and it seems clear to me that it is), then at the very least that should be described here and presented as the default option, with a fallback to the one in this proposal for those that for whatever reason find that unpalatable.\n\nIncidentally, I am trying to figure this out for a spec right now, and would appreciate y\u0027all\u0027s input on Ib7ebbe0c5de3e407dbfff131c2e34c9da6537699 to make sure we\u0027re not diverging from the likely future guidelines.","accounts_in_message":[],"_revision_number":2},{"id":"21ba06543fbd0a45b0000ebf164e9e91b5564384","author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"date":"2015-10-22 23:13:15.000000000","message":"Patch Set 2:\n\n(3 comments)\n\nI think the discussion between Chris and Miguel is worth being taken on the ML. Gerrit is not really the best tool for this purpose.\n\nI do not think this proposal stems from SOAP principles, thus letting in from the window what you threw out from the door.\n\nTo me it looks very similar to a task API, and describing operations on resource in this way in a restful way is totally possible.","accounts_in_message":[],"_revision_number":2},{"id":"8a7f52ba5483a334680f6655ba711840f9bd8fd2","author":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"date":"2015-11-06 23:30:53.000000000","message":"Patch Set 2:\n\n(2 comments)","accounts_in_message":[],"_revision_number":2},{"id":"6c0340926c737e73fa10c54ad9f36ad83a7b7c7c","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2015-12-04 14:56:05.000000000","message":"Patch Set 2:\n\n(1 comment)\n\nI remain a bit confused about how I feel about this.\n\nThe description of how things out to work, and the alignment (for the given design of \"actions\" being their own resource) with good REST principles is good. However, when I think about this from a writing clients standpoint it strikes me as somewhat annoying. Unless I\u0027m managing a series of tasks or something like that what I really want to do is reboot a _server_ or something like that. The resource is the server and I want to change its state. It is likely in my client I already have a representation of the server resources, I\u0027d like to just PUT or PATCH that back up to the API with some changed state and be done with it.\n\nThoughts? Again, I wonder if we need to take the use case(s) to the mailing list to see what we\u0027re really trying to guide.","accounts_in_message":[],"_revision_number":2},{"id":"1548d5e97523d79e3e70f3acf0f6e4f1893a3f74","author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"date":"2015-12-04 19:45:40.000000000","message":"Patch Set 2:\n\n(1 comment)\n\n@Chris good points, my understanding about an actions endpoint in general is that it would be for situations where updating the root resource model doesn\u0027t quite make sense or needs extra information.\n\ni think asynchronous actions make the most sense for me, especially when considering that those actions may have separate error reporting that accompany the activity. for example, in sahara we have an operation to scale a running cluster. using an action for this operation would be more ideal than just updating the cluster topology resource as we could have a more discrete tracking method for the scaling operation as opposed to the general cluster resource. this would especially nice for tracking specific errors associated with the action.","accounts_in_message":[],"_revision_number":2},{"id":"036fef0ebade795e7c06e79545b9868ea0d942d3","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2016-01-15 17:03:23.000000000","message":"Patch Set 2: Code-Review-1\n\nI was asked to review this again with an eye to trying to reach some compromise position. Unfortunately, reading it again in the fresh light of a new year I\u0027ve realized I like it even less than I did before (enough to actually vote -1).\n\nI think if we follow this pattern we are abandoning any concept of the OpenStack APIs being about the actual resources that users deal with.\n\nThe correct way to do perform an action on a resource is to changes the resource\u0027s state. In the commentary before this idea was dismissed because of pushback from earlier implementors. There may have been pushback, but that doesn\u0027t make the idea wrong. There are some things we ought to take a stance on and this feels like one of them.\n\nAn alternate proposal is simply that various actions that can be performed on a resource should be conceptualized as a change in that resource\u0027s state and that change should be caused by PUTting or PATCHing a representation to that resource. For example if we want to reboot a server, we should make its state \"rebooting\" or something along those lines (that\u0027s a clumsy example, but that clumsiness is actually a good indicator of the complexity of both the client and server side handling needed; that\u0027s something we want to be visible and transparent in the system).\n\nWe could also choose to abandon RESTful principles, but that would seem an odd thing to do given what we\u0027ve done thus far.\n\nA good argument can be made for modeling \u0027actions\u0027 as taskflows and thinking of taskflows as resources themselves, but that\u0027s not what this guideline proposes, at least not on the surface, especially given the example in the introduction.\n\nI\u0027m going to punt this to the mailing list and see what kind of input that generates.","accounts_in_message":[],"_revision_number":2},{"id":"9fc36891dd358955805f05a2353e8b15f1058ccb","author":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"date":"2016-01-15 19:12:21.000000000","message":"Patch Set 2: Code-Review-1\n\n(4 comments)\n\nI cannot see an advantage for this vs \u003curl\u003e/\u003cid\u003e/\u003caction\u003e\n\nThis required you get the actions list first, then decide what action to do.\n\nThis could as easily be made part of the data returned from the base object in a meta/links object\n\nThis causes a single endpoint to have multiple valid input schemas - which is a nightmare for docs / auto generating of code.\n\nThe proposal creates tasks as actual things, removing a lot of the issues in the \n\"REST and actions: How *not* to do it\" section.","accounts_in_message":[],"_revision_number":2},{"id":"db8dba85aacecb40f91e0e8bb0ad52ce097af184","author":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"date":"2016-01-18 15:04:47.000000000","message":"Patch Set 2:\n\n(7 comments)\n\nI\u0027d like a bit of discussion on how to get a list of permitted actions for a resource, not a \"What is being done\", but a \"What can I do\". In general (as a GUI client developer) I prefer that I can rebuild the entire resource state machine in the client, so a single, separate resource endpoint would be nice.\n\nI disagree with @cdent\u0027s view that actions should be expressed in direct resource modification. To me, this feels more like I\u0027m managing a resource\u0027s shared TODO list, and modeling something like that in REST is easy.","accounts_in_message":[],"_revision_number":2},{"id":"6178937835fdaccb50126f89373b358815de06a7","author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"date":"2016-01-18 16:30:37.000000000","message":"Patch Set 2:\n\n(3 comments)\n\n@Chris: A reasoning against just sending some represented state to /api/servers/123 is that some of the states are hard to represent.  That may just be an excuse for not thinking hard enough about how to actually represent something, but look at reboot as an example.  The end state of a reboot is that the instance looks exactly as it did before.  Which is to say that the state change that occurs from a reboot is not modeled in Nova.  I don\u0027t know if we would be better served by rethinking how we represent instances and other resources to allow for that sort of API interaction, but it would certainly be more work to get there.","accounts_in_message":[],"_revision_number":2},{"id":"690b5fc2ee0008abfa29084272a5e0a045631549","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2016-01-18 17:02:21.000000000","message":"Patch Set 2:\n\nThanks for the additional input everyone.\n\nalaski: Your use of reboot still seems to support what I\u0027m suggesting, especially given what\u0027s going on in the server side code when you call a reboot:\n\n* task state is set to rebooting\n* some stuff happens\n* eventually the server is there again; it\u0027s task_state is no longer rebooting, but its vmstate is active\n\nSo why doesn\u0027t it make sense to PUT or PATCH a task_state of \u0027rebooting\u0027 to the server/instance resource (in our conceptual and hypothetical example)?\n\n----\n\nI think one of the things that this discussion reveals is that we really need to distinguish quite clearly between atomic (from the perspective of the user-agent) actions that a user-agent would like to make happen (e.g. reboot an instance) and task flows that are set of actions that as a group are non-atomic (again from the perspective of the user-agent) and may or not be ordered or parallelizable (e.g. various forms of orchestration).\n\nThose concepts are a bit conflated here in this spec and muddy the waters.\n\nFor straight up atomic actions, modifying resource state is the way these things are supposed to work. Yes, sometimes it means a bit more work designing resources but that pays out in spades down the road. Existing APIs may not be able to adhere to guidelines in that form, but that\u0027s okay, we\u0027re writing for the future.\n\nFor task flows, that\u0027s a hard problem but I\u0027m sure we can work something out (it probably surrounds observable task resources).","accounts_in_message":[],"_revision_number":2},{"id":"3d6c03d8bf785b17b5e977783263594e52b5872c","author":{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},"date":"2016-01-18 17:24:17.000000000","message":"Patch Set 2:\n\nI\u0027m not enthusiastic about this proposal as it comes already compromised as @cdent suggests when we could take the opportunity to recommend a stronger restful solution. To be sure that stronger solution was suggested and abandoned before, but we could try again if @cdent is game.\n\nI believe that the stronger solution should offer the option of:\n\n1) modifying the state of the underlying resource directly or \n\n2) creating either a subresource or a distinct taskflow resource. These may be ephemeral or not but should be represented as resources.\n\nThe choice should rest on the project developers and operators based on what makes sense for their resources and their flows. Terminology such as \u0027Transitions\u0027 and \u0027Tasks\u0027 should not matter. These should be discoverable though.","accounts_in_message":[],"_revision_number":2},{"id":"36dffcfb32d7e670fe3bc3701082a284c60d968b","author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"date":"2016-01-18 18:04:00.000000000","message":"Patch Set 2:\n\nThere\u0027s another side of this that isn\u0027t being directly addressed, and is part of the reason that setting task_state on an instance isn\u0027t IMO the ideal solution here.  How are failures exposed when they occur?\n\nA huge part of the motivation for \u0027tasks\u0027 in Nova is the ability to provide much more information on what is happening to an instance, and more importantly where the process fails.  Reboot is a poor example because there\u0027s only really one place that it can fail, but even so the current method of setting vm_state to ERROR is heavy handed because the instance may be perfectly active and usable.  There\u0027s no way to indicate that the task failed without also implying that the instance is an a bad state.\n\nBeyond the simple example of reboot there are things like resize which are comprised of multiple steps and by exposing these substeps as resources we can indicate both progress of the operation and which step failed.  So even if the action is kicked off by updating the task_state of an instance to \u0027resizing\u0027, it should still create task resources that can be used for reporting.\n\nThere\u0027s also the question of providing arguments to the operation.  How would a user indicate something like a scheduler hint for a resize/migrate/evacuate operation?\n\nAll this is to say that while I agree that atomic operations can be modeled as you describe Chris I\u0027m of the opinion that few operations in Nova, and perhaps in other projects, can be considered atomic.  And we haven\u0027t found a good solution for error exposure yet.  I think you\u0027re correct that we need to discuss the two types of operations separately though.  And my thinking has been that if we need/want richer task modeling for some operations why not provide them all that way?  But I\u0027m biased because I\u0027m only looking at this through the lens of Nova and instances, so take it all with a grain of salt.","accounts_in_message":[],"_revision_number":2},{"id":"96deae2852715be6c0770a81cba5e20a9bd2bd8d","author":{"_account_id":12807,"name":"Steve Lewis (stevelle)","email":"stevelle@gmail.com","username":"stevelle"},"date":"2016-01-18 18:15:35.000000000","message":"Patch Set 2:\n\nJust a quick follow-up for Andrew and others, full task modeling may be too much for some resources and operations because it is a heavier solution than may be necessary for a simple case. \n\nIn those cases the simplest thing is likely to be the atomic state change on the primary resource.","accounts_in_message":[],"_revision_number":2},{"id":"a92ce8524ff5ad44c053d19ec006ffb23b06d6f8","author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"date":"2016-01-26 02:27:44.000000000","message":"Patch Set 2: -Code-Review\n\nthanks everyone for the input, i\u0027m going to take another stab at this to see if we can come closer to a consensus ;)","accounts_in_message":[],"_revision_number":2},{"id":"c8cb8b2afa25a76e2c885a08534b5f5feaeff90b","author":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"date":"2016-05-10 16:20:47.000000000","message":"Patch Set 2: Code-Review-1\n\nFlagging as -1 to get it off of my review list, waiting on new revision.","accounts_in_message":[],"_revision_number":2},{"id":"fff1111edb3980d793ff77bd5c37c0d7a2dd2aed","author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"date":"2016-05-10 17:23:34.000000000","message":"Patch Set 2: Workflow-1\n\nsadly, i do not have the time to update this. i am going to mark is as -1 workflow. perhaps if there is interest we can find another author, or maybe restart this at some point?","accounts_in_message":[],"_revision_number":2},{"id":"8e814f836695e7b4d886bdacb22c20b43a29c27f","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2016-05-10 17:32:02.000000000","message":"Patch Set 2:\n\nI suspect the right thing to do is reboot it in a new form, after we\u0027ve had a chance to discuss the issues in full. It may be that that\u0027s quite some ways off: we need some real use cases to work through this.\n\nIn the meantime we can probably make other progress by being more explicit about the basic fundamentals of REST and HTTP throughout the guidelines. A lot of good behaviors will fall out from that.","accounts_in_message":[],"_revision_number":2},{"id":"4894ad29895beed679eb57b80c07033666429306","author":{"_account_id":1112,"name":"Everett Toews","email":"everett.toews@rackspace.com","username":"everett-toews"},"date":"2016-05-17 03:03:30.000000000","message":"Patch Set 2:\n\n@Andrew Laski Regarding \"And we haven\u0027t found a good solution for error exposure yet.\" We have the Errors guideline now. http://specs.openstack.org/openstack/api-wg/guidelines/errors.html","accounts_in_message":[],"_revision_number":2},{"id":"18ceea885b865b13da742fa8fc303ec386255237","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2016-06-02 16:08:45.000000000","message":"Abandoned\n\npending further cogitation","accounts_in_message":[],"_revision_number":2}],"current_revision_number":2,"current_revision":"339eec20cee62484ce6ad3be0e98ed59dca05d90","revisions":{"a8d95d1be9ebde7c6d4530ee58d25fb17e29ccc1":{"kind":"REWORK","_number":1,"created":"2015-10-14 21:57:08.000000000","uploader":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"ref":"refs/changes/94/234994/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/api-sig","ref":"refs/changes/94/234994/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/api-sig refs/changes/94/234994/1"}}},"commit":{"parents":[{"commit":"4da096bb773b49b8ad97a28db9e519cf23a61f03","subject":"Remove the voting restriction","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/4da096bb773b49b8ad97a28db9e519cf23a61f03"}]}],"author":{"name":"Miguel Grinberg","email":"miguelgrinberg50@gmail.com","date":"2015-10-14 21:57:01.000000000","tz":-420},"committer":{"name":"Miguel Grinberg","email":"miguelgrinberg50@gmail.com","date":"2015-10-14 21:57:01.000000000","tz":-420},"subject":"Actions guideline","message":"Actions guideline\n\nChange-Id: I7e61fff8f5efaada5cae0c48d6acb26613e4cfc3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/a8d95d1be9ebde7c6d4530ee58d25fb17e29ccc1"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/a8d95d1be9ebde7c6d4530ee58d25fb17e29ccc1"}]},"branch":"refs/heads/master"},"339eec20cee62484ce6ad3be0e98ed59dca05d90":{"kind":"REWORK","_number":2,"created":"2015-10-14 22:07:37.000000000","uploader":{"_account_id":12606,"name":"Miguel Grinberg","email":"miguel.grinberg@gmail.com","username":"miguelgrinberg"},"ref":"refs/changes/94/234994/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/api-sig","ref":"refs/changes/94/234994/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/api-sig refs/changes/94/234994/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/api-sig refs/changes/94/234994/2"}}},"commit":{"parents":[{"commit":"4da096bb773b49b8ad97a28db9e519cf23a61f03","subject":"Remove the voting restriction","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/4da096bb773b49b8ad97a28db9e519cf23a61f03"}]}],"author":{"name":"Miguel Grinberg","email":"miguelgrinberg50@gmail.com","date":"2015-10-14 21:57:01.000000000","tz":-420},"committer":{"name":"Miguel Grinberg","email":"miguelgrinberg50@gmail.com","date":"2015-10-14 22:07:29.000000000","tz":-420},"subject":"Actions guideline","message":"Actions guideline\n\nChange-Id: I7e61fff8f5efaada5cae0c48d6acb26613e4cfc3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/339eec20cee62484ce6ad3be0e98ed59dca05d90"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/api-sig/commit/339eec20cee62484ce6ad3be0e98ed59dca05d90"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}