)]}'
{"ceilometer/compute/pollsters/disk.py":[{"author":{"_account_id":6537,"name":"gordon chung","email":"gord@live.ca","username":"chungg"},"change_message_id":"d7b9393c4f920a7f56e30b588d90c9b113e30807","unresolved":false,"context_lines":[{"line_number":70,"context_line":"                r_requests +\u003d info.read_requests"},{"line_number":71,"context_line":"                w_bytes +\u003d info.write_bytes"},{"line_number":72,"context_line":"                w_requests +\u003d info.write_requests"},{"line_number":73,"context_line":"                per_disk_requests[disk.device] \u003d {"},{"line_number":74,"context_line":"                    \u0027read_bytes\u0027: info.read_bytes,"},{"line_number":75,"context_line":"                    \u0027read_requests\u0027: info.read_requests,"},{"line_number":76,"context_line":"                    \u0027write_bytes\u0027: info.write_bytes,"}],"source_content_type":"text/x-python","patch_set":1,"id":"AAAAW3%2F%2F21w%3D","line":73,"updated":"2014-04-09 22:08:30.000000000","message":"this looks good. an alternative would be to group this by read/write_bytes/requests first and then disk.device.\n\nthat way below when we add additional_metadata we don\u0027t include per_disk information unrelated to sample? ie. disk.read.requests only contains per_disk read_requests and not write_bytes, write_requests, etc..","commit_id":"5cd850c1ba78bd8d6f6d71be6635c28adb9f8a3b"},{"author":{"_account_id":7729,"name":"Ilya Tyaptin","email":"ityaptin@mirantis.com","username":"ityaptin"},"change_message_id":"4193bc74548bc4fa3f46ed6df8e29f6ec444f6ee","unresolved":false,"context_lines":[{"line_number":225,"context_line":"                \u0027write_bytes_rate\u0027: per_disk_w_bytes_rate,"},{"line_number":226,"context_line":"                \u0027write_requests_rate\u0027: per_disk_w_requests_rate,"},{"line_number":227,"context_line":"            }"},{"line_number":228,"context_line":"            # i_cache[instance.id] \u003d virt_inspector.DiskRateStats("},{"line_number":229,"context_line":"            i_cache[instance.id] \u003d DiskRateData("},{"line_number":230,"context_line":"                r_bytes_rate,"},{"line_number":231,"context_line":"                r_requests_rate,"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAW3%2F%2FQ94%3D","line":228,"updated":"2014-04-15 17:20:41.000000000","message":"Why did you leave commented code here? Possibly you may delete it if it isn\u0027t needed?","commit_id":"873c06a20119c160f5a0f1591bb4ad5fab6103e2"},{"author":{"_account_id":6924,"name":"Pradeep Kilambi","email":"pkilambi@redhat.com","username":"pkilambi"},"change_message_id":"db92f1f2e24906fd8045607ef8b2834c99e06aa5","unresolved":false,"context_lines":[{"line_number":225,"context_line":"                \u0027write_bytes_rate\u0027: per_disk_w_bytes_rate,"},{"line_number":226,"context_line":"                \u0027write_requests_rate\u0027: per_disk_w_requests_rate,"},{"line_number":227,"context_line":"            }"},{"line_number":228,"context_line":"            # i_cache[instance.id] \u003d virt_inspector.DiskRateStats("},{"line_number":229,"context_line":"            i_cache[instance.id] \u003d DiskRateData("},{"line_number":230,"context_line":"                r_bytes_rate,"},{"line_number":231,"context_line":"                r_requests_rate,"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAW3%2F%2FQ18%3D","line":228,"in_reply_to":"AAAAW3%2F%2FQ94%3D","updated":"2014-04-15 17:36:26.000000000","message":"Sure, I will once i get some feedback on if this approach is ok. This is still WIP not fully done.","commit_id":"873c06a20119c160f5a0f1591bb4ad5fab6103e2"},{"author":{"_account_id":7478,"name":"Nadya Shakhat","email":"nadmi4@gmail.com","username":"nprivalova"},"change_message_id":"872d4a24a03873abee03313b7d0c695c2fc4da62","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2Fqx8%3D","line":157,"updated":"2014-04-18 11:58:27.000000000","message":"I don\u0027t like the idea of storing meter data inside metadata. The explanation is simple: sample\u0027s metadata will be applied to whole Resource. Let me provide more details.\nI\u0027ve tested your code and for very simple configuration c_data.per_disk_requests[\u0027read_bytes\u0027] \u003d\u003d {\u0027vda\u0027:0, \u0027hdd\u0027: 0}. In this situation these values goes to Resource and becomes a part of it\u0027s metadata. Ok. After that WriteBytesPollster is working. And metadata keys are the same: vda and hdd. So they will be overwritten in Resource. This behaviour is wrong twice (imho): 1. metadata is not the place for storing meter values, they don\u0027t represent \u0027Resource\u0027 actually 2. Additional metadata keys that you introduce are overwritten in Resource.\n\nI\u0027m not agains the idea in general but we should implement it in another way. The most essential for me is to add \"per disk\" meters into volume field. But I guess it\u0027s not align with Ceilometer architecture now. The second variant is create a separate meter like \u003cdisk.read.bytes:hdd\u003e. But I\u0027m not sure in this suggestion. \nAnyway, we should think about a mechanism of Resource\u0027s metadata override during a session about data model. The  use case that is being implemented in this patch is very good example for data-model session. Maybe the simplest decision is just add \"additional data\" field in Sample object. But we should process this correctly.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":9562,"name":"Ildiko Vancsa","email":"ildiko.vancsa@gmail.com","username":"ildikov"},"change_message_id":"b2289e47583568527652ad03fc150151e4b1bd49","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXX%2F%2FyHU%3D","line":157,"in_reply_to":"AAAAXH%2F%2FRIk%3D","updated":"2014-04-27 19:27:37.000000000","message":"My point of view is that it would be better, if we could handle the per disk values in meter(s) and not in metadata. I think these values should not be stored in resource metadata, we should keep the metadata section as tiny as possible as that part is kind of out of control currently. So in my opinion, it would be good if we could handle the disk counter, like it would be derived from the per disk values.\n\nI know that this does not fit really well with the current architecture and/or data models. As we plan to refine those on the upcoming Summit, we could include this question in the process too, that how we can match the design, the data models all together with the functionality and extendability.\n\nIf we finally end up storing it in the metadata section, then I agree with Gordon that we should find an appropriate, possibly new location.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":6537,"name":"gordon chung","email":"gord@live.ca","username":"chungg"},"change_message_id":"713fd869c51eac5d41d50cfdd4be24397c670366","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2FRIk%3D","line":157,"in_reply_to":"AAAAXH%2F%2FSnQ%3D","updated":"2014-04-22 21:40:32.000000000","message":"@eglynn, so for me it\u0027s not like the cpu_util value because it\u0027s not derived, the per disk values are actually the raw data where as the current meter volume is the derived value (ie. i sort of see these meters as going through a hardcoded transformer which rolls them up together... which maybe we shouldn\u0027t have done...)... for me, the per disk values give greater detail into the resource as cpu_number does.\n\nright now i think the most appropriate place to put these values is metadata... maybe another new location might be better but i\u0027m not sure we\u0027ve found it yet... the main preference is that we don\u0027t do additional polling since we have the value here.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":2284,"name":"Eoghan Glynn","email":"eglynn@redhat.com","username":"eglynn"},"change_message_id":"44cc87942d09a76141f96cf79a90c5b89bd13601","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2FSnQ%3D","line":157,"in_reply_to":"AAAAXH%2F%2FUc4%3D","updated":"2014-04-22 18:05:04.000000000","message":"@gordc: I\u0027m struggling to see the direct analogy with the cpu_number being stored in resource metadata, as this value is a fixed (presumably?) attribute of the instance, as opposed to a variable value being metered.\n\nWould a closer analogy be the approach (that we didn\u0027t take) of embedding the cpu_util derived value as resource metadata in the cpu meter samples?","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":6924,"name":"Pradeep Kilambi","email":"pkilambi@redhat.com","username":"pkilambi"},"change_message_id":"63709adc843ec3395d72bfb7fe9c2449adf6122f","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2FUc4%3D","line":157,"in_reply_to":"AAAAXH%2F%2FcYE%3D","updated":"2014-04-22 14:33:43.000000000","message":"I agree with Gordon. I dont really see much difference between cpu-number use case vs disk numbers i have. They are very similar. Regarding  aggregate view of resource_metadata that really is outside of what i had in mind, I just need to be able to access the per disk data as part of the cumulative meter that already is doing the bulk of work. So to me this is the most efficient way to get it without loading ceilometer with extra metrics and polling.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":7478,"name":"Nadya Shakhat","email":"nadmi4@gmail.com","username":"nprivalova"},"change_message_id":"5b12b336b246ed61d7cfd0be6f1e9a9bf0470df8","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2FcYE%3D","line":157,"in_reply_to":"AAAAXH%2F%2FdW0%3D","updated":"2014-04-21 18:28:41.000000000","message":"Gordon, I agree that additional meter for each disk is not a good idea, I just suggested variants.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":6537,"name":"gordon chung","email":"gord@live.ca","username":"chungg"},"change_message_id":"3ce5f3e8ef38e82802dd466b4f56bb22f20797ff","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2FdW0%3D","line":157,"in_reply_to":"AAAAXH%2F%2Fe0M%3D","updated":"2014-04-21 16:18:09.000000000","message":"what does cr stand for? not up to speed with my internet acronyms :)\n\nto me they are similar... \"# of cpu\" value is an attribute of what makes up an instance meter... similarly, \"per disks\" values are attribute of what makes up aggregated disk.read/write meter. could they be their own meters? sure. should they be their own meters? maybe (since we can\u0027t groupby on resource_metadata just yet), but i definitely wouldn\u0027t want additional polls to get info we already have.\n\ni think for your aggregated view of resource_metadata, that should probably be done in a stage outside of our current write method (maybe during archival). updating resource_metadata during write will be a huge bottleneck. to a certain extent, the Resource model is starting to look like a view for analytics (which is not part of Ceilometer scope). its definitely useful for reports but the more we build it into ceilometer, i fear the more it negatively impacts collection.\n\nwondering if anyone else has an opinion on this.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":7478,"name":"Nadya Shakhat","email":"nadmi4@gmail.com","username":"nprivalova"},"change_message_id":"259577440447c98b2d9a4e2a78c769d75cb73166","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2Fe0M%3D","line":157,"in_reply_to":"AAAAXH%2F%2Fiso%3D","updated":"2014-04-21 12:37:58.000000000","message":"\"cpu-number\" describes a Resource imho. And this value is informative. In this cr resource_metadata contains \"hdd\" field and it may have several meanings: \"how many data was read from hdd\" or \"how many data was written to\". \n\nResource is very important element in Ceilometer data-model. Requests\u0027 like \"show the most high-loaded instances\" is the most essential use-case. That\u0027s why I absolutely agree that we need to have better understanding what \u0027resource_metadata\u0027 is. As for me, it should be not only \"metadata of latest sample\" but metadata \"aggregation\" of all samples. E.g. first sample is coming with metadata \"a:b, c:d\", the second with metadata \"a:b1, d:v\". Resource\u0027s metadata should be \"a:b1, c:d, d:v\". It\u0027s just my vision.\n\nComing back to cr... e.g. values of written bytes to disk is not metadata at all. It\u0027s metric\u0027s value. But currently we do not have a mechanism of \"complex values\". Would it be useful? Do we have more cases except disk-values? I think yes. I believe it would be useful for compute networking measurements. Now network.incoming.bytes.rate (just for example) has Resource \u003d IfaceID. If we have an ability to set several values per metric we may change Resource to instance_id.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"},{"author":{"_account_id":6537,"name":"gordon chung","email":"gord@live.ca","username":"chungg"},"change_message_id":"7e8b21c2d1a6147a3a7b8c8c80aa88861c04e336","unresolved":false,"context_lines":[{"line_number":154,"context_line":"            name\u003d\u0027disk.read.bytes\u0027,"},{"line_number":155,"context_line":"            type\u003dsample.TYPE_CUMULATIVE,"},{"line_number":156,"context_line":"            unit\u003d\u0027B\u0027,"},{"line_number":157,"context_line":"            volume\u003dc_data.r_bytes,"},{"line_number":158,"context_line":"            additional_metadata\u003dc_data.per_disk_requests[\u0027read_bytes\u0027],"},{"line_number":159,"context_line":"        )"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-python","patch_set":7,"id":"AAAAXH%2F%2Fiso%3D","line":157,"in_reply_to":"AAAAXH%2F%2Fqx8%3D","updated":"2014-04-19 18:29:50.000000000","message":"i actually prefer this technique. we do the same for cpu pollster (https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/pollsters/cpu.py#L42-L49)... this also saves us the overhead of polling for data we already have.\n\nthe option to define a \u003cdisk.read.bytes:hdd\u003e meter is incorrect. the instance:\u003ctype\u003e meter was only created because of resource_metadata query limitation. it is not the recommended solution at all.\n\nthe question is what is the use case for resource_metadata in Resource model? currently, in the Resource model, it\u0027s the metadata for latest sample... i\u0027m ok with the suggestion to move this data to a \u0027sample_metadata\u0027 field but what i\u0027d rather not create a new field without a use case where we can\u0027t have resource_metadata with differing additional values.","commit_id":"0c611dad3abb4bea79b43a5d83b519699161caaa"}]}