)]}'
{"id":"openstack%2Fopenstack-specs~134839","triplet_id":"openstack%2Fopenstack-specs~master~I29a2a59ded9e260a3d3bf79957bd49f403d8e83a","project":"openstack/openstack-specs","branch":"master","topic":"my_spec","hashtags":[],"change_id":"I29a2a59ded9e260a3d3bf79957bd49f403d8e83a","subject":"Add OSprofiler spec","status":"ABANDONED","created":"2014-11-16 20:57:32.000000000","updated":"2015-12-03 15:12:03.000000000","total_comment_count":73,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"820595dcd89dc72ac448df49fd8430c0ae897779","_number":134839,"virtual_id_number":134839,"owner":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"actions":{},"labels":{"Verified":{"recommended":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"all":[{"value":1,"date":"2015-01-06 21:15:20.000000000","_account_id":3,"name":"Jenkins","username":"jenkins"},{"date":"2015-01-06 21:39:56.000000000","_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},{"_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},{"_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"},{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},{"date":"2015-02-03 08:10:37.000000000","_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},{"date":"2015-02-06 10:01:28.000000000","_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},{"_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},{"date":"2015-01-07 13:46:24.000000000","_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},{"_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},{"date":"2015-01-23 00:22:11.000000000","_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"}],"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":{"disliked":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"all":[{"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":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},{"value":-1,"date":"2015-01-15 11:21:13.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},{"value":-1,"date":"2015-01-07 13:34:42.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},{"value":-1,"date":"2015-01-07 13:27:51.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},{"value":-1,"date":"2015-01-06 22:47:55.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"}],"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":{"all":[{"_account_id":3,"name":"Jenkins","username":"jenkins"},{"_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},{"date":"2015-06-12 07:35:43.000000000","_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},{"date":"2015-01-07 03:57:03.000000000","_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"},{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},{"date":"2015-05-28 18:23:02.000000000","_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},{"date":"2015-01-08 18:14:28.000000000","_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},{"value":0,"permitted_voting_range":{"min":-1,"max":0},"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},{"date":"2015-12-03 15:12:03.000000000","_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"}],"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":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},{"_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},{"_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},{"_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},{"_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},{"_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2014-12-18 18:14:58.000000000","updated_by":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"reviewer":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"state":"REVIEWER"},{"updated":"2015-01-06 12:55:13.000000000","updated_by":{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},"reviewer":{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},"state":"REVIEWER"},{"updated":"2015-01-06 21:15:20.000000000","updated_by":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"reviewer":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"state":"REVIEWER"},{"updated":"2015-01-06 21:39:56.000000000","updated_by":{"_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},"reviewer":{"_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},"state":"REVIEWER"},{"updated":"2015-01-06 22:47:55.000000000","updated_by":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"reviewer":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"state":"REVIEWER"},{"updated":"2015-01-07 03:57:03.000000000","updated_by":{"_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"},"reviewer":{"_account_id":9098,"name":"Nathan Kinder","email":"nkinder@redhat.com","username":"nkinder"},"state":"REVIEWER"},{"updated":"2015-01-07 13:27:51.000000000","updated_by":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"reviewer":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"state":"REVIEWER"},{"updated":"2015-01-07 13:34:42.000000000","updated_by":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"reviewer":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"state":"REVIEWER"},{"updated":"2015-01-08 18:14:28.000000000","updated_by":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"reviewer":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"state":"REVIEWER"},{"updated":"2015-01-15 11:21:13.000000000","updated_by":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"reviewer":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"state":"REVIEWER"},{"updated":"2015-01-23 00:22:11.000000000","updated_by":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"reviewer":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"state":"REVIEWER"},{"updated":"2015-02-03 08:10:37.000000000","updated_by":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"reviewer":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"state":"REVIEWER"},{"updated":"2015-02-06 10:01:28.000000000","updated_by":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"reviewer":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"state":"REVIEWER"},{"updated":"2015-05-28 18:23:02.000000000","updated_by":{"_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},"reviewer":{"_account_id":8726,"name":"Victor Morales","email":"chipahuac@hotmail.com","username":"electrocucaracha"},"state":"REVIEWER"},{"updated":"2015-06-12 07:35:43.000000000","updated_by":{"_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},"reviewer":{"_account_id":6794,"name":"Simon Pasquier","email":"pasquier.simon@gmail.com","username":"simon-pasquier"},"state":"REVIEWER"},{"updated":"2015-12-03 15:12:03.000000000","updated_by":{"_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},"reviewer":{"_account_id":8158,"name":"Hemanth Makkapati","email":"makstacker+osgerrit@gmail.com","username":"hemanth.makkapati"},"state":"REVIEWER"}],"messages":[{"id":"6346657c569acd23eb97bf37528a0b9dc0646465","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2014-11-16 20:57:32.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"4f48d32206791d3024ed45decf6cf5d8b7d04b02","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2014-11-16 20:57:33.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- noop http://logs.openstack.org/39/134839/1/check/noop/e161255 : SUCCESS","accounts_in_message":[],"_revision_number":1},{"id":"388c42bb4e4e68fda6cf5c9de73aebc1bf557083","author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"date":"2014-11-28 11:22:10.000000000","message":"Patch Set 1:\n\n(5 comments)","accounts_in_message":[],"_revision_number":1},{"id":"7bc2284a83174275f4a7e6d27adaeaa7322730cc","author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"date":"2014-12-18 18:14:58.000000000","message":"Patch Set 1: Code-Review-1\n\n(6 comments)\n\nI\u0027m generally in favor of the idea, but have implementation questions. Comments inline.","accounts_in_message":[],"_revision_number":1},{"id":"211953c787ded9e998f05eb44b65c0497541d0e3","author":{"_account_id":4715,"name":"Angus Salkeld","email":"asalkeld@redhat.com","username":"asalkeld"},"date":"2015-01-06 12:55:13.000000000","message":"Patch Set 1: Code-Review+1","accounts_in_message":[],"_revision_number":1},{"id":"9bf23ba07b7fce3b42acab53543e29d9b265bfe1","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-01-06 21:13:15.000000000","message":"Patch Set 1:\n\n(11 comments)","accounts_in_message":[],"_revision_number":1},{"id":"5c790f9bdfc4575262addae05e9db8dab7dd7f28","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-01-06 21:13:29.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"5d2544fd0363b37c60bd553f379943fa94128232","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2015-01-06 21:13:34.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- noop http://logs.openstack.org/39/134839/2/check/noop/a80d573/ : SUCCESS","accounts_in_message":[],"_revision_number":2},{"id":"d51c97fc26f73a02c1f9409f7b91a5ec8092ac89","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-01-06 21:13:57.000000000","message":"Patch Set 1:\n\nFixed some typos and rephrased some parts","accounts_in_message":[],"_revision_number":1},{"id":"e834a1a9abc2015b6f532ec6a44669bf28120323","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-01-06 21:15:17.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"3e41979213f0e5f51bca2a55bf65b53759242fa1","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2015-01-06 21:15:20.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- noop http://logs.openstack.org/39/134839/3/check/noop/fb5310e/ : SUCCESS","accounts_in_message":[],"_revision_number":3},{"id":"2ac1dda3bae28e4b9571ee5724ee499a6907bad5","author":{"_account_id":964,"name":"Anne Gentle","email":"annegentle@justwriteclick.com","username":"annegentle"},"date":"2015-01-06 21:39:56.000000000","message":"Patch Set 3:\n\n(6 comments)","accounts_in_message":[],"_revision_number":3},{"id":"d443a88d39ae9f5fa7535f2477891ba2f51cc17a","author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"date":"2015-01-06 22:47:55.000000000","message":"Patch Set 3: Code-Review-1\n\n(8 comments)\n\nI am concerned about sensitive data leaking into the profiling information. A lot of the comments mirror what was discussed with the keystone team when this integration was originally proposed against keystone (though that was pre-dating the specification process).","accounts_in_message":[],"_revision_number":3},{"id":"0abbe4111cea2a88ee90283faf2c26e60b41df30","author":{"_account_id":3031,"name":"Sam Morrison","email":"sorrison@gmail.com","username":"sorrison"},"date":"2015-01-07 03:48:42.000000000","message":"Patch Set 3:\n\n(2 comments)","accounts_in_message":[],"_revision_number":3},{"id":"b5fceed478d9a9d97ced43f8649f44aa4ef12e3e","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-01-07 13:27:51.000000000","message":"Patch Set 3: Code-Review-1\n\nSorry, but I think this is a bad direction. I applaud the effort and understand the need for instrumentation, but the approach for instrumentation concerns me. \n\nWe already have log messages in our code. We already have notification messages in our code. Now we\u0027re talking about introducing profiling messages in our code?\n\nThis same problem has been solved and proven in production with a monkey-patching approach similar to that used by New Relic and, for the python world, Tach [1] (and to a lesser extent Mock)\n\nThe monkey-patch approach simply introduces a loader in front of the executable. The necessary methods/functions are patched and the timings collected. \n\nSomething like:\n\nnewosprofiler --config my_profiling_config my_program my_config\n\nNo code changes required and works across all projects out of the box. Completely independent solution.\n\nAll the other stuff in the spec is fine ... the cross service linking*, how we get the data out of the service, but the code change is too much, imho. \n\n\n* though, I would prefer to see something that unifies the cross-service Request-ID effort with this cross-service profiling effort. \n\n[1] https://github.com/ohthree/tach","accounts_in_message":[],"_revision_number":3},{"id":"b1198642e19cb75bd4284e1d11e22e3ed0ed2bfd","author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"date":"2015-01-07 13:34:42.000000000","message":"Patch Set 3: Code-Review-1\n\n(25 comments)","accounts_in_message":[],"_revision_number":3},{"id":"aaf71f52394b99a65eb334f226e2e5ed247ab64d","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-01-07 13:46:24.000000000","message":"Patch Set 3:\n\nSandy, \n\n\nI hate to say, but...\n\n1) But your solution is not integrable. Like I can\u0027t integrate it via OpenStack API. It means that I am not able to integrate it with Rally or Horizon out of box. It means nobody will use it, cause it is too complicated. \n\n2) Monkey patching code requires non-stop rebasing -\u003e nobody will do that -\u003e non consumable stuff in real development\n\n3) There is NO REAL LIFE CLIENTS (that pays money for OpenStack) that will allow you to restart all services on all servers and put monkey patching code EVEN IF IT IS absolutely safe. So your solution is not consumable in real life. \n\n4) POC results are that Tach is not commonly used and OpenStack have billions bottlenecks. \n\n\n5) LOGs and Notifications \u003d\u003e They all have own purpose and are very useful in various cases. \nLOGs and Notifications \u003d\u003e something that works for all requests, and get allow us to get some \"common\" data or understanding where something is failing. Profiling is useful when we are tuning some specific peace of OpenStack. In real life we need all that stuff.","accounts_in_message":[],"_revision_number":3},{"id":"5ca4abafefdb3c4dd593db64f0255aa89275c9f3","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-01-07 14:05:53.000000000","message":"Patch Set 3:\n\nHmm, I think you may need to elaborate on some of these points for me:\n\n1) But your solution is not integrable. Like I can\u0027t integrate it via OpenStack API. It means that I am not able to integrate it with Rally or Horizon out of box. It means nobody will use it, cause it is too complicated.\n\nNot sure what you mean by \"integrate it via OpenStack API\"? And what\u0027s complicated about the solution?\n\n2) Monkey patching code requires non-stop rebasing -\u003e nobody will do that -\u003e non consumable stuff in real development\n\nIt requires a config file change and only if the method/module changes. Possibly if the signature of the method changes, but that\u0027s easily handled. For common libraries like DB API or oslo.messaging, that\u0027s nearly never. \n\n3) There is NO REAL LIFE CLIENTS (that pays money for OpenStack) that will allow you to restart all services on all servers and put monkey patching code EVEN IF IT IS absolutely safe. So your solution is not consumable in real life.\n\nIf the requirement is to leave profiling on all the time, it can be done in the exact same manner osprofiler would do it. There\u0027s no difference, only in how the hook is applied. Putting a signal interface on it would be pretty simple, so the service would not have to be restarted. \n\nRequiring every project to take on the profiling effort seems like a big ask. We have a hard enough time getting everyone to standardize on logging and notification adoption as it is. \n\nThat said, I can\u0027t imagine many companies wanting to leave profiling on all the time. There are much lower impact ways to gather metrics. Metering !\u003d instrumentation. \n\n4) POC results are that Tach is not commonly used and OpenStack have billions bottlenecks.\n\nI agree that Tach is not commonly used, but the approach is. Not sure what you mean by \"a billion bottlenecks\"\n\n5) LOGs and Notifications \u003d\u003e They all have own purpose and are very useful in various cases. LOGs and Notifications \u003d\u003e something that works for all requests, and get allow us to get some \"common\" data or understanding where something is failing. Profiling is useful when we are tuning some specific peace of OpenStack. In real life we need all that stuff.\n\nI agree there is a place for it, but I don\u0027t think it\u0027s permanently in the code. Logs track processing, notifications track usage and events of interest to downstream consumers. Profiling, however, is done selectively and generally independently of production. It\u0027s largely just wrapping methods. It doesn\u0027t need to live in the code all the time. \n\nSide note: I think there is merit in trying to merge the notification and logging code. If there was some easy way to get the structured data. Perhaps the schema efforts will help there. \n\nLess code, not more code.","accounts_in_message":[],"_revision_number":3},{"id":"302e9e84493fb57b03dc10faafefc4d1f4d08811","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-01-07 14:17:44.000000000","message":"Patch Set 3:\n\nAh, I think I get the \"billions of bottlenecks\" comment. \n\nYes, there are. But, we find them, we squash them and we move on. The hook doesn\u0027t need to live in the code forever. I\u0027d rather have  a separate config file and a test for regression checks.","accounts_in_message":[],"_revision_number":3},{"id":"85cdb1d0346dcb7e419e48ae95bcfd0335228bd0","author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"date":"2015-01-15 11:21:13.000000000","message":"Patch Set 3: Code-Review-1\n\n(6 comments)\n\nThis is a problem that needs solving, agreed with that.\n\nThe cross service request-ids should be separated out from this effort, and made to work with logging. This is important regardless of profiling. Certainly I worry if profiling decides to use its own custom approach to the general problem.\n\nThe details of this are that it feels too intrusive on the projects you are profiling. I think with the use of something like https://github.com/ohthree/tach you can easily achieve your goals without having to touch the code in every project. The use of oslo should make it easy to monkey patch appropriate things to hook in the profiling, when required, trimming the list of active hook points to just what you are interested in.","accounts_in_message":[],"_revision_number":3},{"id":"cfc54c25ac447814b2ca5e52e765a64a923e96c7","author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"date":"2015-01-23 00:22:11.000000000","message":"Patch Set 3:\n\nUgh, my nice careful reply got eaten by the gerrit web UI and fat fingers.\n\nSo tl;dr:\n - noone wants to be playing catchup with trunk with their instrumentation. \n - I support having the tracer (which this is, vs a profiler) be pluggable, *but* not at the cost of causing operators to play catchup.\n - If you haven\u0027t, please read http://research.google.com/pubs/pub36356.html which is about a very similar system. In particular note the ability to add additional trace messages from dev code: this is a feature, and one that the monkey patch approach doesn\u0027t offer, because it doesn\u0027t scale.\n - Yes logging is very similar. In fact one can build the same thing entirely out of logging if our messages are processable enough and enough effort is put into the log forwarding infrastructure; yet tach exists and that to me seems like evidence that its more pragmatic to use a direct service. That said, if we want to do it with logs, lets do that - keep the same API, have osprofiler push it into the logging subsystem. BUT: being able to sample is key, and one of the big differences between logging and tracing subsystems is that logging generally isn\u0027t a sampling based mechanism. Whereas a trace system is allowed to just drop events when a backlog builds up without blocking the thread or filling up disk.\n - good tracing is a feature. The time we spent implementing OOPS in Launchpad has been massively returned in fast diagnostics of operational issues - something I\u0027m sure folk using tach or osprofiler have already experienced. It wasn\u0027t built for a distributed architecture, or I would have been proposing it or working on integration a few years back. That we don\u0027t offer this in the core by default is a reason for sadness IMO.\n\nOn intrusiveness, that I can agree with - if only we had a small number of pervasive layers that all potential things went through (see the dapper paper above :)). In fact I think we do have the opportunity to do that, though more layers are involved. But if we add tracing to oslo.messaging, all the server-used API clients, oslo.db and the REST framework that our APIs come in on, we should get excellent coverage (particularly when accompanied by judicious annotation of extra data.","accounts_in_message":[],"_revision_number":3},{"id":"0f6edb81a68583a3c2755df596b6c6078068a71a","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-01-28 18:22:29.000000000","message":"Patch Set 3:\n\nIf you\u0027re concerned about a mismatch between the monkey patch hooks and the code, this is a solved problem. We already do this with entry points, but it could just as easily be handled with a config file of mappings (which could be unit tested for accuracy). You\u0027re almost alluding to this in your last comment where the suggestion is to hook into the more pervasive layers. These layers rarely change. Even in the early days of openstack the rpc layers were quite stable. DB would be the same. The power of the monkey patching approach is it allows a deployer to insert ad-hoc patches without code changes. \n\nNot sure about your use of the word \"scale\" in your comment. Can you elaborate? It\u0027s been a long time since I read the Dapper doc, but I don\u0027t recall it saying anything about monkey patching nor it causing a scaling concern? I assume you\u0027re referring to my previous point?\n\nAlso, we\u0027re talking about the method of hooking into the system here, not what to do with the collected data. We could write it to a log or snail mail it to ops, but that\u0027s a handler/deployer decision. For profiling, my personal preference is a UDP message, since these are transient/non-mission critical updates. But let\u0027s focus on the hooks for now. \n\nAs John said, the bigger discussion we should also have is dusting off the shared Request-ID\u0027s across services effort. That will pay big dividends to all these initiatives.","accounts_in_message":[],"_revision_number":3},{"id":"0d0922ad8733a7a0bad0c63fd542b16a3e197b4d","author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"date":"2015-02-03 08:10:37.000000000","message":"Patch Set 3:\n\n(4 comments)","accounts_in_message":[],"_revision_number":3},{"id":"648c3b2dda9522f04b3cf8496b3937cb41b0ee3d","author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"date":"2015-02-03 08:19:29.000000000","message":"Patch Set 3:\n\nIn all honesty; even though some of the questions keep on coming up again and again. I think we really need to start making some progress here... We\u0027ve been \u0027flip flopping\u0027 (and debating) on this for years now and it makes me sorta sad that we can\u0027t just get something working and iterate (and stop trying to design the \u0027supreme\u0027 solution from the get-go); accept that we won\u0027t all have everything perfect, accept that it may not monkey-patch things in (and this is fine to disagree on IMHO) and move-on. I honestly believe not having something like this (and the endless debate around it) is actually hurting all of us more than we think/know...\n\nMy 2 cents...","accounts_in_message":[],"_revision_number":3},{"id":"88cf46759096ada0e9e968de66d886e17cc92e58","author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"date":"2015-02-03 08:29:30.000000000","message":"Patch Set 3:\n\n@Joshua, \n\nI think that not all of the questions here are as irrelevant as you\u0027re making them out to be. Monkey Patch vs non-Monkeypatch is a design choice that could be worked through in either case. Most of the concerns on overhead of a non-monkey patch model is something that could be quantified.\n\nI don\u0027t think all the questions raise fall into perfect being the enemy of good.\n\nThis spec could be split into 2 distinct specs with clear wins on both fronts.\n\n1) Unified request id. This seems non-controversial and should be easy to pass.\n2) Profiling spec. While there are some concerns about \"best approach\", there are other questions that could be easily addressed without a complete re-architecture of the osprofiler.\n\nSo to get positive traction here I would like to see this spec split as outlined above. The profiling spec can focus on addressing [even if the answer is to clearly define where the hooks are instead of leaving it nebulous, which would mitigate some of the conversation around monkeypatching and overhead] the comments without a complete re-architecture. There are some things that block what I would accept into Keystone - but they wouldn\u0027t be extremely hard to fix (this revolves around the same comments from the original code proposal against keystone itself).","accounts_in_message":[],"_revision_number":3},{"id":"a5141c4b0ac85bc8f7489277a02631deee99df4c","author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"date":"2015-02-06 10:01:28.000000000","message":"Patch Set 3:\n\nAgree with Morgan that this could be split between the non-controversial part (cross-project request IDs) and the controversial part (best approach to profiling).","accounts_in_message":[],"_revision_number":3},{"id":"a8e3feb71476f02fa50a3b9f3af56ba690a4054e","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-02-06 11:10:04.000000000","message":"Patch Set 3:\n\nThanks everybody for comments. \n\nI think that this spec doesn\u0027t have enough good description of OSprofiler which produce a lot of debates.\n\nI am going to update this spec soon to try to reply on all comments in review. Plus I will update \"Alternative\" section with Tach and request-id to make discussion more technical. \n\n\nBy the way, actually I don\u0027t see any reason why I should split this spec to 2 different. The request-id mechanism is absolutely different thing for different purpose. \nrequest-id - is for adding ability to collect all log messages related to single request from various services. \n\ntrace-id - is added for supporting nested points (that are useless in case of logs and most important part for tracing) \n\nI really don\u0027t see any reason to make a effort to combine this 2 absolutely different things together.","accounts_in_message":[],"_revision_number":3},{"id":"ac118e38e41098477d67e4611e997f32f32edd45","author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"date":"2015-02-06 20:19:30.000000000","message":"Patch Set 3:\n\n@Boris,\n\nWhy do we need trace-ids that are independant of request ids? Could they be the same thing? Do we need another unique identifier for all requests or does it make sense to have them be the same? The win I see with them being the same is it allows an operator to see / correlate logs/audit-info/etc to profiling when run.\n\nI still would advocate the split in this case for the reasons outlined. I am against having massive different numbers of ways to identify a request unless there is a very good reason these should be different identifiers (\"because it would be easier to implement if they are different\" is not the correct answer).","accounts_in_message":[],"_revision_number":3},{"id":"796c5345216bdd1f13baf589ec161067436c8534","author":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"date":"2015-02-06 20:32:30.000000000","message":"Patch Set 3:\n\n@Morgan,\n\nIt has absolutely different nature... It\u0027s similar to say \"let\u0027s use Java in keystone Python and Java are close enough\" \n\nrequest-id specify request (and it\u0027s not nested). \ntrace-id specify point, 1 request creates N trace points. (points are nested)\n\nSo when we are building trace (by N trace points, even in single service), we are specifying all trace points by 3 trace ids: \n(base_trace_id, parent_point_trace, current_point_trace_id)\n\nSo trace-id doesn\u0027t care about request and doesn\u0027t specify request at all. (Actually if I don\u0027t gave up with this stuff I will work as well on tracing periodic task that are not triggered by REST at all)\n\n2 different mechasim are required because: \n1) If we put to logs 3 uuids - the size of logs will be HUGE and we won\u0027t use these 3 uuids at all\n2) If we don\u0027t have 3 uuids for describing trace point whole idea of osprofiler will be useless.","accounts_in_message":[],"_revision_number":3},{"id":"417abc7ef714cfad5e2fc0f4da77f4ade6040203","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-02-06 20:34:08.000000000","message":"Patch Set 3:\n\nyeah, request_id\u0027s aren\u0027t just for logging. We depend on them for notifications too. \n\nCouldn\u0027t trace-id be inferred from the stack (traceback)?","accounts_in_message":[],"_revision_number":3},{"id":"4f641f26ebb0bef7e66a711d37cb64c95de51928","author":{"_account_id":688,"name":"Sandy Walsh","email":"sandy.walsh@rackspace.com","username":"sandy-walsh"},"date":"2015-02-06 20:41:18.000000000","message":"Patch Set 3:\n\nspecifically function_name:\nhttps://docs.python.org/2/library/traceback.html#traceback.extract_tb","accounts_in_message":[],"_revision_number":3},{"id":"f28f71742aea81e9fb0ce52afe768f567ff98589","author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"date":"2015-08-11 09:26:49.000000000","message":"Patch Set 3:\n\nis this abandoned?","accounts_in_message":[],"_revision_number":3},{"id":"07090e9df493ab0ca666db81841830a3cfdfbfc7","author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"date":"2015-10-13 08:39:24.000000000","message":"Abandoned\n\nBoris, I\u0027m abandoning this patch as the last comment from you is from 2015-02-7 and there are still several unaddressed comments. Feel free to restore it or ping me if you still want to pursue it.","accounts_in_message":[],"_revision_number":3}],"current_revision_number":3,"current_revision":"e9ac3a0c6ae3670ef4ef0a8e6a57a092318cecdb","revisions":{"79454c2bfdf615aa8dfd49a4db9934d474d5245f":{"kind":"REWORK","_number":1,"created":"2014-11-16 20:57:32.000000000","uploader":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"ref":"refs/changes/39/134839/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-specs","ref":"refs/changes/39/134839/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/1"}}},"commit":{"parents":[{"commit":"0037520075281aedc0dc38094028be9d63c879fb","subject":"Added .gitreview","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/0037520075281aedc0dc38094028be9d63c879fb"}]}],"author":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2014-11-16 19:57:04.000000000","tz":240},"committer":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2014-11-16 19:58:07.000000000","tz":240},"subject":"Add OSprofiler spec","message":"Add OSprofiler spec\n\nThe goal of this spec is to align adoption of OSprofiler cross all\nprojects.\n\nBased on:\nhttps://review.openstack.org/#/c/103825/\n\nChange-Id: I29a2a59ded9e260a3d3bf79957bd49f403d8e83a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/79454c2bfdf615aa8dfd49a4db9934d474d5245f"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/79454c2bfdf615aa8dfd49a4db9934d474d5245f"}]},"branch":"refs/heads/master"},"c8fc792a775f839fa8276d861ac038e54906a2fe":{"kind":"REWORK","_number":2,"created":"2015-01-06 21:13:29.000000000","uploader":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"ref":"refs/changes/39/134839/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-specs","ref":"refs/changes/39/134839/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/2"}}},"commit":{"parents":[{"commit":"5191b37a08b7cbdcdac8be7f15af8cad44d7978d","subject":"Workflow documentation is now in infra-manual","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/5191b37a08b7cbdcdac8be7f15af8cad44d7978d"}]}],"author":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2014-11-16 19:57:04.000000000","tz":240},"committer":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2015-01-06 21:13:21.000000000","tz":180},"subject":"Add OSprofiler spec","message":"Add OSprofiler spec\n\nThe goal of this spec is to align adoption of OSprofiler cross all\nprojects.\n\nBased on:\nhttps://review.openstack.org/#/c/103825/\n\nChange-Id: I29a2a59ded9e260a3d3bf79957bd49f403d8e83a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/c8fc792a775f839fa8276d861ac038e54906a2fe"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/c8fc792a775f839fa8276d861ac038e54906a2fe"}]},"branch":"refs/heads/master"},"e9ac3a0c6ae3670ef4ef0a8e6a57a092318cecdb":{"kind":"REWORK","_number":3,"created":"2015-01-06 21:15:17.000000000","uploader":{"_account_id":6172,"name":"Boris Pavlovic","email":"boris@pavlovic.me","username":"boris-42"},"ref":"refs/changes/39/134839/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-specs","ref":"refs/changes/39/134839/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-specs refs/changes/39/134839/3"}}},"commit":{"parents":[{"commit":"5191b37a08b7cbdcdac8be7f15af8cad44d7978d","subject":"Workflow documentation is now in infra-manual","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/5191b37a08b7cbdcdac8be7f15af8cad44d7978d"}]}],"author":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2014-11-16 19:57:04.000000000","tz":240},"committer":{"name":"Boris Pavlovic","email":"boris@pavlovic.me","date":"2015-01-06 21:15:08.000000000","tz":180},"subject":"Add OSprofiler spec","message":"Add OSprofiler spec\n\nThe goal of this spec is to align adoption of OSprofiler cross all\nprojects.\n\nBased on:\nhttps://review.openstack.org/#/c/103825/\n\nChange-Id: I29a2a59ded9e260a3d3bf79957bd49f403d8e83a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/e9ac3a0c6ae3670ef4ef0a8e6a57a092318cecdb"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-specs/commit/e9ac3a0c6ae3670ef4ef0a8e6a57a092318cecdb"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}