)]}'
{"specs/mitaka/approved/lightweight-nova-service-profiling.rst":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c604750666cc5b2341e90e30dd2f221ec265720d","unresolved":false,"context_lines":[{"line_number":103,"context_line":"maintained project.  As a benchmarking tool, however, it\u0027s not advisible to use"},{"line_number":104,"context_line":"Rally in a production environment.  Further, for very large deployments, it\u0027s"},{"line_number":105,"context_line":"unlikely that a staging environment with the same characteristics as the"},{"line_number":106,"context_line":"production environment will be available for benchmarking purposes."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Data model impact"},{"line_number":109,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_b9eb51db","line":106,"updated":"2015-11-19 15:58:43.000000000","message":"The obvious alternative is OSProfiler which is already used in a number of openstack projects:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2015-November/078845.html\n\nMy general thought is that we should focus on integrating with that, rather than twisting the notifications API into a performance monitoring system.\n\nI feel the primary purpose of the notifications system is to provide information about system state changes or important actions which other apps need to trigger work from. I can see why it might be appealing to tack extra info onto that to enable profiling, but I\u0027m really convinced it is the right way to approach profiling.  I think it is more compelling to focus on the OSProfile library which will let us trace across all openstack components starting right from the clients","commit_id":"57e11211aecc7a2cad688c9f9e1d998530965f98"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f5fb12bf812e4a564bcedc2c2315768c1f573736","unresolved":false,"context_lines":[{"line_number":103,"context_line":"maintained project.  As a benchmarking tool, however, it\u0027s not advisible to use"},{"line_number":104,"context_line":"Rally in a production environment.  Further, for very large deployments, it\u0027s"},{"line_number":105,"context_line":"unlikely that a staging environment with the same characteristics as the"},{"line_number":106,"context_line":"production environment will be available for benchmarking purposes."},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Data model impact"},{"line_number":109,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_157452cd","line":106,"in_reply_to":"ba8a016a_b9eb51db","updated":"2015-11-20 22:22:50.000000000","message":"Thanks for the reference.  I updated the patch set to include OSProfiler as an alternative.","commit_id":"57e11211aecc7a2cad688c9f9e1d998530965f98"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2f08028ed0d9f0e732e384b5cd7af0bb156852a0","unresolved":false,"context_lines":[{"line_number":343,"context_line":"          \"nova_object.name\":\"KeyPair\","},{"line_number":344,"context_line":"          \"nova_object.namespace\":\"nova\","},{"line_number":345,"context_line":"          \"nova_object.data\":{"},{"line_number":346,"context_line":"              # actual data here"},{"line_number":347,"context_line":"          }"},{"line_number":348,"context_line":"      },"},{"line_number":349,"context_line":"      \"message_id\":\"98f1221f-ded0-4153-b92d-3d67219353ee\""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a740942_9e8ecd77","line":346,"updated":"2015-12-07 11:54:57.000000000","message":"Look in here, and you find the progress percentage.\n\nThat can be used to break down the larger action into smaller chunks.","commit_id":"c6572f88001993122e5e2c6f5c94d033711fca89"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2f08028ed0d9f0e732e384b5cd7af0bb156852a0","unresolved":false,"context_lines":[{"line_number":366,"context_line":""},{"line_number":367,"context_line":"Another alternative would be to introduce an \u0027activity\u0027 field on the nova"},{"line_number":368,"context_line":"versioned object itself.  Since it\u0027s a versioned object, this should be"},{"line_number":369,"context_line":"backward compatible and not interfere with any current consumers."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"More notifications"},{"line_number":372,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a740942_9ee56d39","line":369,"updated":"2015-12-07 11:54:57.000000000","message":"Really, for this approach we should look at the API concept of progress, and update that.","commit_id":"c6572f88001993122e5e2c6f5c94d033711fca89"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"ba2c19346e5ecf10f7ecae6823818b2c094bee89","unresolved":false,"context_lines":[{"line_number":388,"context_line":"discussion about whether integrating OSProfiler into Nova or modifying"},{"line_number":389,"context_line":"notifications as proposed in this spec is the better way forward.  The current"},{"line_number":390,"context_line":"status of OSProfiler is described in a recent posting to the mailing list"},{"line_number":391,"context_line":"[OSM1]_."},{"line_number":392,"context_line":""},{"line_number":393,"context_line":"Data model impact"},{"line_number":394,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba8a016a_729fcd5f","line":391,"updated":"2015-11-23 10:36:00.000000000","message":"IMHO OSProfiler is the way forward for profiling. For a start OSProfile will have zero overhead unless it is specifically enabled, which can be done on a per-request basis.It has pluggable backends, so if admins want to avoid flooding the message bus with profiling data they can do so.\n\nMore fundamentally is the type of data being emitted and the intended recipient of that data. Notifications provide data intended for receipt by external non-nova services and/or users. IOW the data provided via notifications has low security sensitivity.  The profiling data will be targetted towards cloud admins and is considered *highly* security sensitive and some of this data must not *ever* be accessable to users who who are not cloud admins.   This IMHO is a key reason why we must not use notifications as the basis of profiling - the risk of unintentionally leaking security sensitive data is significant. \n\nHaving a completely separated framework for profiling is highly desirable from a security POV IMHO.","commit_id":"c6572f88001993122e5e2c6f5c94d033711fca89"}]}