)]}'
{"nova/availability_zones.py":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ef338969e48fd861591a020db541744945f767b5","unresolved":false,"context_lines":[{"line_number":192,"context_line":"                  \u0027 and thus az in cache is updated\u0027,"},{"line_number":193,"context_line":"                  {\u0027az\u0027: az, \u0027az_inst\u0027: az_inst})"},{"line_number":194,"context_line":"        az \u003d az_inst"},{"line_number":195,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a6ced46_e76d1e06","line":195,"updated":"2015-03-23 13:53:52.000000000","message":"I\u0027m not sure it\u0027s the right way to do this. Let me explain : AZs are only metadata associated to host aggregates. They don\u0027t have a real value if an instance is attached to an host which is not part of an aggregate, because if so, that\u0027s only a default thing.\n\nAZs should always be consider wrt host aggregates and consequently, if the instance related information about AZ is incorrect, it should rather be updated - and not the host one.\n\nSo, long story short, I would invert the logic and consider that if a discrepancy (L188) is identified, then we should update the instance.az information (provided both instance AZ info and host AZ info are not defaulted)","commit_id":"9d00c30016397b92193193eb2a9c21ec05435d40"},{"author":{"_account_id":12861,"name":"Trung Trinh","email":"trungtt1981@gmail.com","username":"ttt"},"change_message_id":"d15790474adf05bbc2adc1a4266bfbd8c6473a70","unresolved":false,"context_lines":[{"line_number":192,"context_line":"                  \u0027 and thus az in cache is updated\u0027,"},{"line_number":193,"context_line":"                  {\u0027az\u0027: az, \u0027az_inst\u0027: az_inst})"},{"line_number":194,"context_line":"        az \u003d az_inst"},{"line_number":195,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"}],"source_content_type":"text/x-python","patch_set":2,"id":"da9b358b_7805b2c0","line":195,"in_reply_to":"1a6ced46_e76d1e06","updated":"2015-03-30 03:34:23.000000000","message":"@Sylvain\nI disagree with your solution!\nWhat\u0027s wrong here is the az info stored in the cache and if so the az cache should be updated from the az stored in the instance.\nWhen you carefully read the \"Bug Description\" (link: https://bugs.launchpad.net/nova/+bug/1390033), you\u0027ll yourself re-produce this bug easily. After that, you can apply your patch set to check if your solution can overcome this problem or not.\nI did ever encounter this problem in reality, not that I built up this kind of problem!","commit_id":"9d00c30016397b92193193eb2a9c21ec05435d40"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"a7b83660f90b044e60f5b6cac92921e6817a5099","unresolved":false,"context_lines":[{"line_number":192,"context_line":"                  \u0027 and thus az in cache is updated\u0027,"},{"line_number":193,"context_line":"                  {\u0027az\u0027: az, \u0027az_inst\u0027: az_inst})"},{"line_number":194,"context_line":"        az \u003d az_inst"},{"line_number":195,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"}],"source_content_type":"text/x-python","patch_set":2,"id":"da9b358b_5582a301","line":195,"in_reply_to":"da9b358b_7805b2c0","updated":"2015-03-30 15:54:19.000000000","message":"It seems Trung is right here. During the boot time we can provide an option to set instance az and we probably have to follow that value in priority if set. Otherwise I can join Sylvain\u0027s point and we probably have to remove the field availability_zone form instance but currently this patch looks the only viable thing.","commit_id":"9d00c30016397b92193193eb2a9c21ec05435d40"},{"author":{"_account_id":6450,"name":"Hans Lindgren","email":"hanlind@kth.se","username":"hanlind"},"change_message_id":"f2d1327e158c8c78102ad1ac3a7671a6a36d6f4e","unresolved":false,"context_lines":[{"line_number":170,"context_line":"def get_instance_availability_zone(context, instance):"},{"line_number":171,"context_line":"    \"\"\"Return availability zone of specified instance.\"\"\""},{"line_number":172,"context_line":"    host \u003d instance.get(\u0027host\u0027)"},{"line_number":173,"context_line":"    if not host:"},{"line_number":174,"context_line":"        # Likely hasn\u0027t reached a viable compute node yet so give back the"},{"line_number":175,"context_line":"        # desired availability_zone in the instance record if the boot request"},{"line_number":176,"context_line":"        # specified one."}],"source_content_type":"text/x-python","patch_set":3,"id":"da9b358b_58d4fc1e","line":173,"updated":"2015-03-31 08:40:56.000000000","message":"This is where the case when the instance is still scheduling and hasn\u0027t been assigned a host is handled.","commit_id":"aee3d60d55b706d08087d20b2ec4f6db4e8315ed"},{"author":{"_account_id":6450,"name":"Hans Lindgren","email":"hanlind@kth.se","username":"hanlind"},"change_message_id":"c8010a2effc804b8b11c1f9fa8e30e7cba50fbe1","unresolved":false,"context_lines":[{"line_number":192,"context_line":"                  \u0027 and thus az in cache is updated\u0027,"},{"line_number":193,"context_line":"                  {\u0027az\u0027: az, \u0027az_inst\u0027: az_inst})"},{"line_number":194,"context_line":"        az \u003d az_inst"},{"line_number":195,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"}],"source_content_type":"text/x-python","patch_set":3,"id":"da9b358b_7496c44d","line":195,"updated":"2015-03-30 17:55:55.000000000","message":"This is in reply to comments on the previous patchset.\n\nI must say I agree with Sylvain, instance.availability_zone isn\u0027t really what defines what az the instance lives in, it is just a desired value the user provides when the instance is initially created, which is then used by the scheduler to place the instance. The actual az is entirely decided by the host aggregate (with az set) that the host the instance runs on is associated with. I stated something similar on a previous patch iteration a long time ago[1].\n\nThe cache is furthermore just that, a cache layer for the host aggregate info so if a value is dirty, the correct value should be re-read from the aggregate tables, which is the only true source of information.\n\nIn fact, what I think we should do is figure out why the cache \"unexpectedly go wrong\" and solve that instead of trying to fix stuff up after the fact. I can think of a couple of reasons, one being evacuate/resize/migrate that probably isn\u0027t checking scheduler filters leading to instances being moved between azs, another one that actually has a bug is renaming an az[2].\n\n[1] https://review.openstack.org/#/c/135566/4/nova/availability_zones.py\n\n[2] https://bugs.launchpad.net/nova/+bug/1378904","commit_id":"aee3d60d55b706d08087d20b2ec4f6db4e8315ed"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b98c6775b0831945352bc4536c82c247a0794f1d","unresolved":false,"context_lines":[{"line_number":192,"context_line":"                  \u0027 and thus az in cache is updated\u0027,"},{"line_number":193,"context_line":"                  {\u0027az\u0027: az, \u0027az_inst\u0027: az_inst})"},{"line_number":194,"context_line":"        az \u003d az_inst"},{"line_number":195,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"}],"source_content_type":"text/x-python","patch_set":3,"id":"da9b358b_e72fa83c","line":195,"in_reply_to":"da9b358b_7496c44d","updated":"2015-03-31 10:43:41.000000000","message":"I share Hans\u0027s point as said in the previous PS. Here, the problem is classic : we have a cache that is invalidated because there is a discrepancy between what\u0027s cached and what is the real value. \n\nMy disapproval to that change goes to the fact that the source of truth is what the user is requesting, not what we actually have. A common solution is to invalidate the cache and fetch the actual result, hence my previous comment.","commit_id":"aee3d60d55b706d08087d20b2ec4f6db4e8315ed"},{"author":{"_account_id":6450,"name":"Hans Lindgren","email":"hanlind@kth.se","username":"hanlind"},"change_message_id":"f2d1327e158c8c78102ad1ac3a7671a6a36d6f4e","unresolved":false,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"},{"line_number":199,"context_line":"    if not az:"},{"line_number":200,"context_line":"        elevated \u003d context.elevated()"},{"line_number":201,"context_line":"        az \u003d get_host_availability_zone(elevated, host)"},{"line_number":202,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"}],"source_content_type":"text/x-python","patch_set":3,"id":"da9b358b_b869c827","line":199,"updated":"2015-03-31 08:40:56.000000000","message":"Another problem with this change. What if the hosts az hasn\u0027t been cached yet. If we call this method on an instance running on that host, we never reach here anymore so we never get to cache the correct value.","commit_id":"aee3d60d55b706d08087d20b2ec4f6db4e8315ed"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b98c6775b0831945352bc4536c82c247a0794f1d","unresolved":false,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"    # If az cache is None and az stored in instance does not exist"},{"line_number":198,"context_line":"    # but host is valid, then get az from db eventually"},{"line_number":199,"context_line":"    if not az:"},{"line_number":200,"context_line":"        elevated \u003d context.elevated()"},{"line_number":201,"context_line":"        az \u003d get_host_availability_zone(elevated, host)"},{"line_number":202,"context_line":"        cache.set(cache_key, az, AZ_CACHE_SECONDS)"}],"source_content_type":"text/x-python","patch_set":3,"id":"da9b358b_e7d68826","line":199,"in_reply_to":"da9b358b_b869c827","updated":"2015-03-31 10:43:41.000000000","message":"Yeah, that\u0027s just another exhibit for considering the host-related AZ information as the actual information to care about.","commit_id":"aee3d60d55b706d08087d20b2ec4f6db4e8315ed"}]}