)]}'
{"ceilometer/tests/api/v2/test_list_events_scenarios.py":[{"author":{"_account_id":7052,"name":"Fabio Giannetti","email":"fgiannet@cisco.com","username":"fabgia"},"change_message_id":"d5866000a50d38b581f80547fb1b032251ce5029","unresolved":false,"context_lines":[{"line_number":85,"context_line":"        data \u003d self.get_json(\u0027/meters/instance\u0027)"},{"line_number":86,"context_line":"        self.assertEqual(2, len(data))"},{"line_number":87,"context_line":"        for s in data:"},{"line_number":88,"context_line":"            self.assertEqual(timeutils.utcnow().isoformat(), s[\u0027recorded_at\u0027])"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":91,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":2,"id":"fa98f980_3239e141","side":"PARENT","line":88,"updated":"2014-09-10 15:35:21.000000000","message":"Why did you remove this test? This is important it validates that the date is in iso format. Can you please re-instate this test?","commit_id":"fcc6b0de4ef309a91dbf1ea94f475a8e5f168534"},{"author":{"_account_id":8052,"name":"Nejc Saje","email":"nejc@saje.info","username":"nsaje"},"change_message_id":"3e1d8cfec5b057702c1a0972a956725fbf87f267","unresolved":false,"context_lines":[{"line_number":82,"context_line":"        self.assertEqual(2, len(data))"},{"line_number":83,"context_line":"        for s in data:"},{"line_number":84,"context_line":"            # Parse with the exact format we expect"},{"line_number":85,"context_line":"            iso_format \u003d \"%Y-%m-%dT%H:%M:%S.%f\""},{"line_number":86,"context_line":"            actual \u003d datetime.datetime.strptime(s[\u0027recorded_at\u0027], iso_format)"},{"line_number":87,"context_line":"            # Double-check the parsed value"},{"line_number":88,"context_line":"            self.assertEqual(actual.isoformat(), s[\u0027recorded_at\u0027])"}],"source_content_type":"text/x-python","patch_set":5,"id":"fa98f980_0cc5618d","line":85,"updated":"2014-09-12 09:48:12.000000000","message":"I just can\u0027t shake the feeling that it isn\u0027t right to have this as a hardcoded literal. How is this checked in other places in the tests?","commit_id":"00011c845df28cdbaa11a6e0a309ac67cafa9466"},{"author":{"_account_id":144,"name":"justinsb","email":"justin@fathomdb.com","username":"justin-fathomdb"},"change_message_id":"99158f0447ff0bb2c88fd1bb5a90eace8a7d5068","unresolved":false,"context_lines":[{"line_number":82,"context_line":"        self.assertEqual(2, len(data))"},{"line_number":83,"context_line":"        for s in data:"},{"line_number":84,"context_line":"            # Parse with the exact format we expect"},{"line_number":85,"context_line":"            iso_format \u003d \"%Y-%m-%dT%H:%M:%S.%f\""},{"line_number":86,"context_line":"            actual \u003d datetime.datetime.strptime(s[\u0027recorded_at\u0027], iso_format)"},{"line_number":87,"context_line":"            # Double-check the parsed value"},{"line_number":88,"context_line":"            self.assertEqual(actual.isoformat(), s[\u0027recorded_at\u0027])"}],"source_content_type":"text/x-python","patch_set":5,"id":"fa98f980_582c7802","line":85,"in_reply_to":"fa98f980_0cc5618d","updated":"2014-09-12 18:28:52.000000000","message":"Please see Fabio\u0027s comment on patch set 2 to see why I added this.  Originally I was casting everything to a datetime and doing comparisons, but Fabio pointed out that this meant that I had lost the validation of the exact format.","commit_id":"00011c845df28cdbaa11a6e0a309ac67cafa9466"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"28a15a35b32124dac556ca2accb933c49c33f502","unresolved":false,"context_lines":[{"line_number":20,"context_line":"import datetime"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"from oslo.utils import timeutils"},{"line_number":23,"context_line":"import pytz"},{"line_number":24,"context_line":"import six"},{"line_number":25,"context_line":"import webtest.app"},{"line_number":26,"context_line":""}],"source_content_type":"text/x-python","patch_set":8,"id":"baa201ad_374b5388","line":23,"updated":"2014-10-16 03:55:02.000000000","message":"should we add this into test-requirements.txt?","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":3012,"name":"Dina Belova","email":"dbelova@mirantis.com","username":"dbelova"},"change_message_id":"fb9484ef873aa395c988020ea5253a4351d3cf87","unresolved":false,"context_lines":[{"line_number":20,"context_line":"import datetime"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"from oslo.utils import timeutils"},{"line_number":23,"context_line":"import pytz"},{"line_number":24,"context_line":"import six"},{"line_number":25,"context_line":"import webtest.app"},{"line_number":26,"context_line":""}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_7f7444cf","line":23,"in_reply_to":"9aa7fdbe_03893026","updated":"2014-10-21 10:48:19.000000000","message":"Justin, you\u0027re right here, requirements are installed anyway","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"fd3820748686e655e6230609b7df157e01e9fc61","unresolved":false,"context_lines":[{"line_number":20,"context_line":"import datetime"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"from oslo.utils import timeutils"},{"line_number":23,"context_line":"import pytz"},{"line_number":24,"context_line":"import six"},{"line_number":25,"context_line":"import webtest.app"},{"line_number":26,"context_line":""}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_4185abab","line":23,"in_reply_to":"9aa7fdbe_7f7444cf","updated":"2014-10-23 01:51:15.000000000","message":"ah, my bad, it\u0027s already there.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":144,"name":"justinsb","email":"justin@fathomdb.com","username":"justin-fathomdb"},"change_message_id":"79c0f9f8b1acb7ba2454e6ec51d480cc162571d6","unresolved":false,"context_lines":[{"line_number":20,"context_line":"import datetime"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"from oslo.utils import timeutils"},{"line_number":23,"context_line":"import pytz"},{"line_number":24,"context_line":"import six"},{"line_number":25,"context_line":"import webtest.app"},{"line_number":26,"context_line":""}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_03893026","line":23,"in_reply_to":"baa201ad_374b5388","updated":"2014-10-21 03:34:56.000000000","message":"pytz is in requirements.txt.  It is my understanding that we do not duplicate it into test-requirements.txt.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"28a15a35b32124dac556ca2accb933c49c33f502","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        now \u003d timeutils.utcnow()"},{"line_number":40,"context_line":"        # Make sure our UTC timestamp has a UTC timezone"},{"line_number":41,"context_line":"        self.assertEqual(now.tzinfo, None)"},{"line_number":42,"context_line":"        self.recorded_at \u003d now.replace(tzinfo\u003dpytz.UTC)"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"        self.sample1 \u003d sample.Sample("}],"source_content_type":"text/x-python","patch_set":8,"id":"baa201ad_d23e95b7","line":41,"updated":"2014-10-16 03:55:02.000000000","message":"why we need this? timeutils.utcnow() should always return datetime object with tzinfo of None, unless somebody set utcnow.override_time, but here no one set that.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"fd3820748686e655e6230609b7df157e01e9fc61","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        now \u003d timeutils.utcnow()"},{"line_number":40,"context_line":"        # Make sure our UTC timestamp has a UTC timezone"},{"line_number":41,"context_line":"        self.assertEqual(now.tzinfo, None)"},{"line_number":42,"context_line":"        self.recorded_at \u003d now.replace(tzinfo\u003dpytz.UTC)"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"        self.sample1 \u003d sample.Sample("}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_01a48355","line":41,"in_reply_to":"9aa7fdbe_23d9d457","updated":"2014-10-23 01:51:15.000000000","message":"sorry, but how could utcnow() return a timestamp with non-None tzinfo? https://docs.python.org/2/library/datetime.html said utcnow() \"Return the current UTC date and time, with tzinfo None. \". The only way to return a tzinfo timestamp is to set utcnow.override_time which is not the case here.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":144,"name":"justinsb","email":"justin@fathomdb.com","username":"justin-fathomdb"},"change_message_id":"79c0f9f8b1acb7ba2454e6ec51d480cc162571d6","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        now \u003d timeutils.utcnow()"},{"line_number":40,"context_line":"        # Make sure our UTC timestamp has a UTC timezone"},{"line_number":41,"context_line":"        self.assertEqual(now.tzinfo, None)"},{"line_number":42,"context_line":"        self.recorded_at \u003d now.replace(tzinfo\u003dpytz.UTC)"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"        self.sample1 \u003d sample.Sample("}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_23d9d457","line":41,"in_reply_to":"baa201ad_d23e95b7","updated":"2014-10-21 03:34:56.000000000","message":"utcnow() might be expected to return a timestamp with a timezone of UTC.  To compute the delta on recorded_at, we need it to have the correct timezone.  In fact, it doesn\u0027t, so we have the assertion (to document that utcnow() isn\u0027t returning time with a UTC timezone), followed immediately by a line which sets the timezone to UTC.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":2284,"name":"Eoghan Glynn","email":"eglynn@redhat.com","username":"eglynn"},"change_message_id":"4cb4b59890e354c151baae53fd6b3885acb33007","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"fa98f980_abeec51f","line":102,"updated":"2014-09-15 14:43:58.000000000","message":"I\u0027m struggling to understand the value of this assertion. As opposed to ensuring the correctness of the ceilometer code, it seems to be more an assertion on the sanity of the time-setup of the host on which the remote DB is running.\n\nShould the ceilometer scenario tests fail for example because ntpd in not running on the remote host?\n\nAm I missing something fundamental here?","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"fd3820748686e655e6230609b7df157e01e9fc61","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_6182af95","line":102,"in_reply_to":"9aa7fdbe_8320c04a","updated":"2014-10-23 01:51:15.000000000","message":"yes, to tolerate the clock skew, we needs the abs. I\u0027m just saying we don\u0027t need abs if we don\u0027t plan to tolerate clock skew here, which I think we shouldn\u0027t.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":144,"name":"justinsb","email":"justin@fathomdb.com","username":"justin-fathomdb"},"change_message_id":"79c0f9f8b1acb7ba2454e6ec51d480cc162571d6","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"9aa7fdbe_8320c04a","line":102,"in_reply_to":"baa201ad_92432d12","updated":"2014-10-21 03:34:56.000000000","message":"Delta will be positive or negative as the client or the server is skewed ahead (assuming the write takes negligible time).  We _don\u0027t_ want to fail the test due to clock skew; but we do expect that client recorded_at time should \u003d\u003d server recorded_at time.  We can\u0027t do this exactly, but we compromise and allow up to 30 seconds of clock skew in either direction.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":4491,"name":"Lianhao Lu","email":"llh_misc@outlook.com","username":"lianhao-lu"},"change_message_id":"28a15a35b32124dac556ca2accb933c49c33f502","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"baa201ad_92432d12","line":102,"in_reply_to":"fa98f980_3b34cbfa","updated":"2014-10-16 03:55:02.000000000","message":"why abs the delta? I don\u0027t think the actual recorded_at could be earlier than client side time, if we want to fail the test due to clock skew.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":7052,"name":"Fabio Giannetti","email":"fgiannet@cisco.com","username":"fabgia"},"change_message_id":"3de29354906f2a07389bab643b116f6bf6573867","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"fa98f980_ec96204b","line":102,"in_reply_to":"fa98f980_abeec51f","updated":"2014-09-15 17:48:40.000000000","message":"I think this is exactly what the test is trying to evaluate. If the db is running on localhost it will always pass, but if it is in a different server it must be kept in sync. I think 30s may be a good measure but really we should check for the min possible difference if ntpd is truly running.","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"},{"author":{"_account_id":144,"name":"justinsb","email":"justin@fathomdb.com","username":"justin-fathomdb"},"change_message_id":"41ad1547f8b6f8917fdfab723d74b8d9665855e3","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"            # If this fails when running on a remote storage system,"},{"line_number":101,"context_line":"            # verify that clocks are set consistently"},{"line_number":102,"context_line":"            self.assertTrue(abs(delta_seconds) \u003c 30)"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    def test_all_trailing_slash(self):"},{"line_number":105,"context_line":"        data \u003d self.get_json(\u0027/meters/instance/\u0027)"}],"source_content_type":"text/x-python","patch_set":8,"id":"fa98f980_3b34cbfa","line":102,"in_reply_to":"fa98f980_abeec51f","updated":"2014-09-16 12:36:41.000000000","message":"The original test verifies that the recorded_at timestamp is set to the current time.\n\nOriginally the current time was mocked.  However, if we\u0027re using a storage backend that sets its own timestamps (and I\u0027m working on one!) then we can\u0027t mock time for that external system.\n\nIt\u0027s not just clock skew either:  if a storage system takes one minute to do the write, then the 30 second tolerance would likely fail also.  (Arguably though, one minute writes would be a bug)\n\nThe best I can think of is to assert that the inserted timestamp matches the client clock to within a margin of error, and 30 seconds seems sane - than would be a huge skew for ntpd and a big delay for a write.\n\nFor normal unit tests, we should be running locally, so there will be no time skew, we\u0027re really just allowing for \u0027insert delay\u0027.  If the tests are configured with a remote server, the assertion will fail if the clocks are skewed (which is why there\u0027s the comment on the line which will fail).\n\nSo I think this is mostly a check on the ceilometer code (verify that recorded_at defaults to now).  If you set it up with a remote server, you are also checking the latency to that server and clock skew, but that\u0027s not the normal way to run the tests.  The normal scenario for the test suite is running locally, where we\u0027re 95% testing ceilometer :-)\n\nOf course, if you have a better suggestion, I am very open to it!  It sounds like you would prefer to just get rid of the assertion altogether?","commit_id":"5e5ee8a710a377ace37727003eb87e6cc74c008b"}]}