)]}'
{"neutron/objects/qos/policy.py":[{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"9dd24b437928f3bc820169c510e76b649f1aad55","unresolved":false,"context_lines":[{"line_number":392,"context_line":"                                          qosrouter.router_id, policy_id))"},{"line_number":393,"context_line":"        return set(bound_tenants)"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"    def obj_make_compatible(self, primitive, target_version):"},{"line_number":396,"context_line":"        def filter_rules(obj_names, rules):"},{"line_number":397,"context_line":"            return [rule for rule in rules if"},{"line_number":398,"context_line":"                    rule[\u0027versioned_object.name\u0027] in obj_names]"}],"source_content_type":"text/x-python","patch_set":2,"id":"bfb3d3c7_4bfe5906","side":"PARENT","line":395,"updated":"2019-05-16 18:41:00.000000000","message":"Can you explain why this is no longer needed?  This code enables the rolling upgrade behavior for QosPolicyRBAC objects.  Will there never ever be a reason for compatibility between versions of this object?  Given that there are already multiple versions that seems unlikely.  And there\u0027s not enough information in the commit message to know why you want to compel this behaior... but it is expected that any OVO object be able to downgrade to an older version if needed.  So I\u0027d be very interested in getting an explanation, ideally for posterity in the commit message.","commit_id":"bd3d85807cf3391d4c41c8e7d10e56566b8c1ecf"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"01ec378fa82433b224db07f8f8fe457e094cc6ae","unresolved":false,"context_lines":[{"line_number":392,"context_line":"                                          qosrouter.router_id, policy_id))"},{"line_number":393,"context_line":"        return set(bound_tenants)"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"    def obj_make_compatible(self, primitive, target_version):"},{"line_number":396,"context_line":"        def filter_rules(obj_names, rules):"},{"line_number":397,"context_line":"            return [rule for rule in rules if"},{"line_number":398,"context_line":"                    rule[\u0027versioned_object.name\u0027] in obj_names]"}],"source_content_type":"text/x-python","patch_set":2,"id":"bfb3d3c7_832d0d48","side":"PARENT","line":395,"in_reply_to":"bfb3d3c7_4bfe5906","updated":"2019-05-17 10:48:49.000000000","message":"For sure and if you agree with this explanation, I\u0027ll add this to the commit message.\n\nAs you know the compatibility methods are meant to solve the problems between servers and agents with different code versions. OpenStack should keep 1 release backwards compatibility. What I\u0027m removing are OVO versions backwards compatibility methods implemented more than 1 year ago because neither the server nor the agents should implement OVOs with versions older than the latest one.\n\nLast changes affecting to object compatibility, done in those OVOs:\n* QoSPolicy: https://review.opendev.org/#/c/428304/, 2 years ago.\n* QosBandwidthLimitRule: https://review.opendev.org/#/c/449831/, 2y 1m ago\n* QosDscpMarkingRule: https://review.opendev.org/#/c/300501/, 2y 10m ago\n* QosMinimumBandwidthRule: https://review.opendev.org/#/c/344145/, 2y 8m ago\n* QosRuleType: https://review.opendev.org/#/c/475260/, 1y 10m ago","commit_id":"bd3d85807cf3391d4c41c8e7d10e56566b8c1ecf"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"82ebb9443ca72bc6a46740cd6e37b4a533191d8e","unresolved":false,"context_lines":[{"line_number":392,"context_line":"                                          qosrouter.router_id, policy_id))"},{"line_number":393,"context_line":"        return set(bound_tenants)"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"    def obj_make_compatible(self, primitive, target_version):"},{"line_number":396,"context_line":"        def filter_rules(obj_names, rules):"},{"line_number":397,"context_line":"            return [rule for rule in rules if"},{"line_number":398,"context_line":"                    rule[\u0027versioned_object.name\u0027] in obj_names]"}],"source_content_type":"text/x-python","patch_set":2,"id":"bfb3d3c7_a03600b4","side":"PARENT","line":395,"in_reply_to":"bfb3d3c7_832d0d48","updated":"2019-05-17 16:25:43.000000000","message":"I don\u0027t mind doing this - it\u0027s good housecleaning.  I don\u0027t think I would tear down the structure for making the checks as well as the checks themselves.  Perhaps leave obj_make_compatible in place with just a pass, so that in the future if there is a revision it is clear where compatibility code should be introduced.  You could even point at this change in a comment there as well, to help later engineers.\n\nI\u0027ll propose a topic for the coming Neutron Team Meeting to propose that we make this kind of cleaning global.  That also vets the idea with the whole community, so others won\u0027t have the same questions I did.\n\nThanks!","commit_id":"bd3d85807cf3391d4c41c8e7d10e56566b8c1ecf"}]}