)]}'
{"neutron/api/rpc/handlers/dhcp_rpc.py":[{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"3753f3ba3e39fae0c7f1e689ae2bdea43aa60706","unresolved":false,"context_lines":[{"line_number":167,"context_line":"    @db_api.retry_db_errors"},{"line_number":168,"context_line":"    def release_dhcp_port(self, context, **kwargs):"},{"line_number":169,"context_line":"        \"\"\"Release the port currently being used by a DHCP agent.\"\"\""},{"line_number":170,"context_line":"        context.session.expunge_all()"},{"line_number":171,"context_line":"        host \u003d kwargs.get(\u0027host\u0027)"},{"line_number":172,"context_line":"        network_id \u003d kwargs.get(\u0027network_id\u0027)"},{"line_number":173,"context_line":"        device_id \u003d kwargs.get(\u0027device_id\u0027)"}],"source_content_type":"text/x-python","patch_set":5,"id":"3afc51ec_3d9a0b64","line":170,"updated":"2016-03-14 04:47:04.000000000","message":"wouldn\u0027t it be wiser to move this within the decorator, rather than spreading it like this? It feels rather error prone. Do you mean that the expunge is not needed in all cases? And how did this \u0027work\u0027 before?","commit_id":"a820de492bfb642010ccbb81676a8eafc221cb3a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"d0f4c433220639cd6a60a56df79c3fd0c0752819","unresolved":false,"context_lines":[{"line_number":167,"context_line":"    @db_api.retry_db_errors"},{"line_number":168,"context_line":"    def release_dhcp_port(self, context, **kwargs):"},{"line_number":169,"context_line":"        \"\"\"Release the port currently being used by a DHCP agent.\"\"\""},{"line_number":170,"context_line":"        context.session.expunge_all()"},{"line_number":171,"context_line":"        host \u003d kwargs.get(\u0027host\u0027)"},{"line_number":172,"context_line":"        network_id \u003d kwargs.get(\u0027network_id\u0027)"},{"line_number":173,"context_line":"        device_id \u003d kwargs.get(\u0027device_id\u0027)"}],"source_content_type":"text/x-python","patch_set":5,"id":"3afc51ec_239dcc59","line":170,"in_reply_to":"3afc51ec_3d9a0b64","updated":"2016-03-14 06:34:55.000000000","message":"I didn\u0027t put it in the decorator because the functions we decorate aren\u0027t very consistent in the placement of the context (some in first arg vs second arg vs inside of the request object).\n\nIt would be a good idea to expunge in all cases. This has been working before because it seems to be a pretty rare to get a case where a retry is triggered that creates two objects with the exact same unique constraint.\n\nFor example, in a \u0027real\u0027 deployment, a retry on a port create is normally triggered by an IP allocation duplicate record or failure to update the range. This means that someone has already taken the IP that we were trying to take, so on the next retry when the IP allocation object is added to the session, it\u0027s different than any possible leftover ones.\n\nThe additional thing that makes this hard to trigger is that the objects in the session that can cause conflicts are only held by a weak reference. So if everything exits and cleans up on the retry, there won\u0027t be anything left on the next iteration.\n\nIn the particular case of the bug and unit test, something holds onto a reference that can make it back to the IP allocation object between retries. I suspect it may be the traceback itself that the oslo DB retry decorator keeps, or perhaps its something in the logging engine. It will even be wiped out after poking around with pdb for a bit during the test and then continuing (i.e. the test then passes without any fixes).\n\nTL;DR. We\u0027ve been getting lucky by re-using the session without expunging since some objects may have persisted if things held references to them.","commit_id":"a820de492bfb642010ccbb81676a8eafc221cb3a"}],"neutron/db/db_base_plugin_v2.py":[{"author":{"_account_id":11816,"name":"mike bayer","display_name":"Mike Bayer","email":"mike_mp@zzzcomputing.com","username":"zzzeek","status":"Red Hat"},"change_message_id":"815e9c6bd9488f840070ac96627b5b0bf675c845","unresolved":false,"context_lines":[{"line_number":1252,"context_line":"            # to ipallocations and then remove the extra reference to the"},{"line_number":1253,"context_line":"            # allocation records so theys can be garbage collected as normal."},{"line_number":1254,"context_line":"            db_port.get(\u0027fixed_ips\u0027)"},{"line_number":1255,"context_line":"            context.session.info[\u0027allocated_ips\u0027] \u003d []"},{"line_number":1256,"context_line":"            if (\u0027dns-integration\u0027 in self.supported_extension_aliases and"},{"line_number":1257,"context_line":"                \u0027dns_name\u0027 in p):"},{"line_number":1258,"context_line":"                dns_assignment \u003d []"}],"source_content_type":"text/x-python","patch_set":7,"id":"3afc51ec_c0cf857d","line":1255,"updated":"2016-03-15 02:24:48.000000000","message":"were you getting the same kind of error on this one?","commit_id":"245078d7a5c850c43ebeabfbba843333c582e7a7"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"1c96314a8b12a95a20551c56068dcd38e7fde28b","unresolved":false,"context_lines":[{"line_number":1252,"context_line":"            # to ipallocations and then remove the extra reference to the"},{"line_number":1253,"context_line":"            # allocation records so theys can be garbage collected as normal."},{"line_number":1254,"context_line":"            db_port.get(\u0027fixed_ips\u0027)"},{"line_number":1255,"context_line":"            context.session.info[\u0027allocated_ips\u0027] \u003d []"},{"line_number":1256,"context_line":"            if (\u0027dns-integration\u0027 in self.supported_extension_aliases and"},{"line_number":1257,"context_line":"                \u0027dns_name\u0027 in p):"},{"line_number":1258,"context_line":"                dns_assignment \u003d []"}],"source_content_type":"text/x-python","patch_set":7,"id":"3afc51ec_92d02cf8","line":1255,"in_reply_to":"3afc51ec_927b0c28","updated":"2016-03-15 06:35:03.000000000","message":"Hmmm. We can get rid of passive_deletes\u003dTrue, we load all of the fixed ips for a port during port delete operations anyway.","commit_id":"245078d7a5c850c43ebeabfbba843333c582e7a7"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"0b41ac9d54d2a186dea205ab38828eea88a9fbc4","unresolved":false,"context_lines":[{"line_number":1252,"context_line":"            # to ipallocations and then remove the extra reference to the"},{"line_number":1253,"context_line":"            # allocation records so theys can be garbage collected as normal."},{"line_number":1254,"context_line":"            db_port.get(\u0027fixed_ips\u0027)"},{"line_number":1255,"context_line":"            context.session.info[\u0027allocated_ips\u0027] \u003d []"},{"line_number":1256,"context_line":"            if (\u0027dns-integration\u0027 in self.supported_extension_aliases and"},{"line_number":1257,"context_line":"                \u0027dns_name\u0027 in p):"},{"line_number":1258,"context_line":"                dns_assignment \u003d []"}],"source_content_type":"text/x-python","patch_set":7,"id":"3afc51ec_f25370e0","line":1255,"in_reply_to":"3afc51ec_c0cf857d","updated":"2016-03-15 06:23:56.000000000","message":"Yeah, the issue here was with a functional test that would create ports, delete ports, and then recreate ports all under the same session. Leaving the allocation attached to the session caused a conflict.","commit_id":"245078d7a5c850c43ebeabfbba843333c582e7a7"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"970a527009450a130c180fd7b9f1619fcaa0ac4b","unresolved":false,"context_lines":[{"line_number":1252,"context_line":"            # to ipallocations and then remove the extra reference to the"},{"line_number":1253,"context_line":"            # allocation records so theys can be garbage collected as normal."},{"line_number":1254,"context_line":"            db_port.get(\u0027fixed_ips\u0027)"},{"line_number":1255,"context_line":"            context.session.info[\u0027allocated_ips\u0027] \u003d []"},{"line_number":1256,"context_line":"            if (\u0027dns-integration\u0027 in self.supported_extension_aliases and"},{"line_number":1257,"context_line":"                \u0027dns_name\u0027 in p):"},{"line_number":1258,"context_line":"                dns_assignment \u003d []"}],"source_content_type":"text/x-python","patch_set":7,"id":"3afc51ec_927b0c28","line":1255,"in_reply_to":"3afc51ec_f25370e0","updated":"2016-03-15 06:32:54.000000000","message":"It seems to be related to the passive_deletes option on the Port\u0027s fixed_ips relationship. If I remove passive_deletes completely, then it works okay, but even changing to \"cascade\u003d\u0027all, delete-orphan\u0027, passive_deletes\u003dTrue\" had no effect.","commit_id":"245078d7a5c850c43ebeabfbba843333c582e7a7"}]}