)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"b256cc6b05f5976f969716d4877f58cc4c1e7c7f","unresolved":false,"context_lines":[{"line_number":12,"context_line":"This change keeps the current behaviour of storing the"},{"line_number":13,"context_line":"user_id in the resource_id, but does so in methods which can"},{"line_number":14,"context_line":"be overridden to enable storing the user_id in a different"},{"line_number":15,"context_line":"way (for example, resource data)."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Iac41ab99f8e9b0953b2cd447ff0e027443fabeca"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"AAAATn%2F9I3k%3D","line":15,"updated":"2013-12-16 12:43:52.000000000","message":"So, I\u0027ve been looking at this too in relation to allowing SignalResponder resources to create an ec2 keypair derived from a trust (ref bug #1089261).\n\nIn that case, we want to remove the existing assumption in heat_keystoneclient that each user has only one ec2-keypair, and each SignalResponder needs to store the trust ID and the ec2 accesskey ID, so we can delete both at handle_delete.\n\nSo my question is, why don\u0027t we just store the user_id and access_key id in resource data in SignalResponder, if that will help your subclass use-case, and my trusts-accesskey one?","commit_id":"25cd630ea8d6e948684e13889179d654a19efc70"},{"author":{"_account_id":4571,"name":"Steve Baker","email":"sbaker@redhat.com","username":"steve-stevebaker"},"change_message_id":"22170d833fbabe6e97f8439c10e5e3e4ac80fafa","unresolved":false,"context_lines":[{"line_number":12,"context_line":"This change keeps the current behaviour of storing the"},{"line_number":13,"context_line":"user_id in the resource_id, but does so in methods which can"},{"line_number":14,"context_line":"be overridden to enable storing the user_id in a different"},{"line_number":15,"context_line":"way (for example, resource data)."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Change-Id: Iac41ab99f8e9b0953b2cd447ff0e027443fabeca"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"AAAATn%2F8%2FuA%3D","line":15,"in_reply_to":"AAAATn%2F9I3k%3D","updated":"2013-12-17 22:23:43.000000000","message":"That would work for me. We would have to decide what the existing SignalResponder resources would use for their resource_id. Maybe the subclass handle_create should just set the resource_id from the user_id.","commit_id":"25cd630ea8d6e948684e13889179d654a19efc70"}],"heat/engine/signal_responder.py":[{"author":{"_account_id":4328,"name":"Steven Hardy","email":"steven.hardy@suse.com","username":"shardy"},"change_message_id":"68bdd2961bf095923d0b54ea3d4dcf3a7d147bdd","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"    # Subclasses may set this to False if there is a more appropriate"},{"line_number":48,"context_line":"    # resource to use for the resource_id."},{"line_number":49,"context_line":"    user_id_is_resource_id \u003d True"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    def handle_create(self):"},{"line_number":52,"context_line":"        # Create a keystone user so we can create a signed URL via FnGetRefId"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAUH%2F%2FiMk%3D","line":49,"updated":"2014-01-12 09:41:36.000000000","message":"Is this flag actually needed?  I\u0027m thinking the subclass will just override handle_create to create $thing_more_appropriate_than_user?\n\nAlso if we\u0027re storing the user_id in resource data anyway, maybe the base class should just set the resource id to the physical_resource_name instead, then even if the subclass calls the superclass handle_create, it can re-set the resource id by calling resource_data_set again?","commit_id":"dc1f58b97bb076c80461bcd18db78a5b5fbb7998"},{"author":{"_account_id":4571,"name":"Steve Baker","email":"sbaker@redhat.com","username":"steve-stevebaker"},"change_message_id":"6190f85412a8211858e89d35e370598b186bd00d","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"    # Subclasses may set this to False if there is a more appropriate"},{"line_number":48,"context_line":"    # resource to use for the resource_id."},{"line_number":49,"context_line":"    user_id_is_resource_id \u003d True"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    def handle_create(self):"},{"line_number":52,"context_line":"        # Create a keystone user so we can create a signed URL via FnGetRefId"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAUH%2F%2Fg3U%3D","line":49,"in_reply_to":"AAAAUH%2F%2Fg5w%3D","updated":"2014-01-13 04:14:33.000000000","message":"Actually, replying to myself again, I\u0027d like to leave this current patch set as the best approach. Leaving the existing three subclasses to store the user_id as resource_id and resource data is a low-risk approach and handles upgrades from older versions of heat. Subclasses which want to use something else as the resource_id can just set the flag.","commit_id":"dc1f58b97bb076c80461bcd18db78a5b5fbb7998"},{"author":{"_account_id":4571,"name":"Steve Baker","email":"sbaker@redhat.com","username":"steve-stevebaker"},"change_message_id":"9ad352e0cff1442e56807f7179a23f6aa29df7e4","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"    # Subclasses may set this to False if there is a more appropriate"},{"line_number":48,"context_line":"    # resource to use for the resource_id."},{"line_number":49,"context_line":"    user_id_is_resource_id \u003d True"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    def handle_create(self):"},{"line_number":52,"context_line":"        # Create a keystone user so we can create a signed URL via FnGetRefId"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAUH%2F%2Fg5w%3D","line":49,"in_reply_to":"AAAAUH%2F%2FhVc%3D","updated":"2014-01-13 03:57:57.000000000","message":"Actually I can\u0027t think of an upgrade friendly approach which doesn\u0027t either use a flag or require that some subclasses override a get user_id method, and using a flag seems simpler and cleaner.","commit_id":"dc1f58b97bb076c80461bcd18db78a5b5fbb7998"},{"author":{"_account_id":4571,"name":"Steve Baker","email":"sbaker@redhat.com","username":"steve-stevebaker"},"change_message_id":"fb27822bf3864826b9abbbaba9724163cfba8e09","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"    # Subclasses may set this to False if there is a more appropriate"},{"line_number":48,"context_line":"    # resource to use for the resource_id."},{"line_number":49,"context_line":"    user_id_is_resource_id \u003d True"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    def handle_create(self):"},{"line_number":52,"context_line":"        # Create a keystone user so we can create a signed URL via FnGetRefId"}],"source_content_type":"text/x-python","patch_set":4,"id":"AAAAUH%2F%2FhVc%3D","line":49,"in_reply_to":"AAAAUH%2F%2FiMk%3D","updated":"2014-01-12 22:04:56.000000000","message":"The reason I\u0027m storing in resource_data and resource_id is to maintain backwards compatibility for live upgrades. I\u0027ll go for an upgrade-friendly approach based on get_user_id method.","commit_id":"dc1f58b97bb076c80461bcd18db78a5b5fbb7998"}]}