)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":28459,"name":"Bob Church","email":"robert.church@windriver.com","username":"rchurch"},"change_message_id":"60685d3320ddfe421df3f697c60c4e046cb38580","unresolved":true,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5606be6e_fdeff7e2","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"updated":"2022-10-20 19:45:57.000000000","message":"So this LP is referring to application apply/remove failing, but looking at the changes I don\u0027t see it doing anything different other than removing log noise. Does it actually fix the application apply/remove failures?\n\nIf so, then I think the fix is to catch the traceback in calling code (i.e sysinv.conductor.kube_app) as opposed to changing this common dispatcher. With that said, it seems to me that we need to understand why we are seeing this in the first place with the transition to FluxCD.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"b2491887efa7d9284a240702eb30f31c433ddff9","unresolved":true,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"f497bc12_432c56bc","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"in_reply_to":"5606be6e_fdeff7e2","updated":"2022-10-23 20:05:41.000000000","message":"\u003e I don\u0027t see it doing anything different other than removing log noise\n\nThis is meant to be a neutral change.\nFor some reason, the try-except block in this file sometimes does catch the exception as it should, throwing an error for which there already exists an \"except\" clause implemented and halting code execution.\nThis commit is not supposed to change anything about the logic, just the code syntax by swapping the try-except block for a built-in python function. \n\n\u003e Does it actually fix the application apply/remove failures?\n\nIt fixes one of the intermittent failure points in the framework, but there are others.\n\n\u003e we need to understand why we are seeing this in the first place with the transition to FluxCD\n\nI believe this particular error is caused by some weirdness in python\u0027s exception handling.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"fe8f3063a6601b3d9c96e1f9aa138d0a7301b8b5","unresolved":false,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3edb0169_ac32b9d4","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"in_reply_to":"5bcb4b19_58cb0ced","updated":"2022-11-10 17:13:16.000000000","message":"Ack","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"b07c84efe814e8f409d0304d893ca195e38e3274","unresolved":true,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5bcb4b19_58cb0ced","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"in_reply_to":"c4aaff82_a1c10c05","updated":"2022-11-04 17:53:49.000000000","message":"The LP description mentions only the log noise, so I think Closes-Bug is correct.\n\nThere are at least two different error conditions which trigger this noise, so for clarity I think it\u0027s just better to deal with each on a separate LP.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":15435,"name":"Al Bailey","email":"albailey1974@gmail.com","username":"albailey"},"change_message_id":"aba7e07f2cad8e2f843f1ceebf56f969ad640347","unresolved":true,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"c4aaff82_a1c10c05","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"in_reply_to":"ef308cb6_744de483","updated":"2022-11-04 14:14:57.000000000","message":"Do we think the commit message should say \nPartial-Bug: \nto indicate that we still have further work to do to close the bug,  or is the bug just \u0027log noise\u0027   in which case, the Closes-Bug:   is  correct?","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"7e8d3c2a1939b73b6593df2b80297c47ab02fc95","unresolved":true,"context_lines":[{"line_number":19,"context_line":"    the warning is seen, demonstrating that the section"},{"line_number":20,"context_line":"    is no longer a failure point."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Closes-Bug: 1991701"},{"line_number":23,"context_line":"Signed-off-by: Leonardo Fagundes Luz Serrano \u003cLeonardo.FagundesLuzSerrano@windriver.com\u003e"},{"line_number":24,"context_line":"Change-Id: Ia37cf4c5340b58e7f318683669eaf35871558134"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"ef308cb6_744de483","line":22,"range":{"start_line":22,"start_character":12,"end_line":22,"end_character":19},"in_reply_to":"f497bc12_432c56bc","updated":"2022-11-04 04:47:59.000000000","message":"I think I understand what you meant now.\n\nMy assessment was that the \u0027AttributeError\u0027 was the root cause of the problem, but following a suggestion from Dan I was able to reproduce the error message and it appears to be a log artifact of the appfwk, just noise as you said. And it always comes coupled with another message with the actual error.\n\nI believe this change should be merged to remove the message and avoid confusion as it is very misleading.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":30852,"name":"Dan Voiculeasa","email":"Dan.Voiculeasa@windriver.com","username":"dvoicule"},"change_message_id":"9c9c6e187f42ca89402cdd922aced739ad2795d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"d7702db9_756768ff","updated":"2022-10-31 13:11:25.000000000","message":"For this particular case a LOG.whatever can be used during active developer investigation to figure out the differences between good/bad path.\nWe see this error because one of the proxyobj is written in a way it intercepts the AttributError, developer active investigation should focus on what that proxyobj is and where it comes from to understand why we see this now.\n\nChanging to hasattr just makes the investigation not necessary anymore.\n\nWe don\u0027t even need the LOG.debug here now, doesn\u0027t provide any real value in real-world runtime. Only provides proof in the developer environment that the issue is fixed. Can remove the LOG.debug.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"fe0d63e5c26b869dc88f33c0a36bfb256e59c06c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"3026fc6a_b815b292","in_reply_to":"7b135a55_c23f2ab9","updated":"2022-11-01 19:53:23.000000000","message":"removed log","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33750,"name":"Leonardo Fagundes Luz Serrano","display_name":"Leonardo Serrano","email":"Leonardo.FagundesLuzSerrano@windriver.com","username":"lfagunde"},"change_message_id":"16d7761bb08583a34ecf869444e235a3f34bdfa6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"7b135a55_c23f2ab9","in_reply_to":"d7702db9_756768ff","updated":"2022-10-31 13:56:19.000000000","message":"\u003e developer active investigation should focus on what that proxyobj is and where it comes from to understand why we see this now\n\nDuring investigation it was observed that the exception triggers very often, even during normal apply operations, so it was just assumed proxyobj not having the attribute is normal.\n\nWhat is odd is that sometimes the try-except block catches the exception and the code functions normally and sometimes it doesn\u0027t (despite the logs claiming it is AttributeError and so the catch block should have handled it).\n\nI\u0027m in the process of investigating why the code catches the exception sometimes and not others.","commit_id":"0e151e3c6548fad10d510b4f1469cb836c15d551"},{"author":{"_account_id":33594,"name":"Thales Elero Cervi","display_name":"Thales Cervi","email":"thaleselero.cervi@windriver.com","username":"tcervi"},"change_message_id":"52dc05d31af4b662499336dd4b69671f7880fe79","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"e6878483_a35f01fe","updated":"2022-11-10 12:53:57.000000000","message":"Apparently this log noise is happening quite often when testing stx-openstack fluxcd according to Lucas (CCed here now). So it seems to me that would be good to have this clean up code merged for more meaningful error logs while testing.","commit_id":"015df527fed192b8eb10609309241472cc8c8ac1"}]}