)]}'
{"nova/scheduler/filters/aggregate_instance_extra_specs.py":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"888b9376729b53200cd99d047daf49c191d78043","unresolved":false,"context_lines":[{"line_number":51,"context_line":"            if len(scope) \u003e 1 and scope[0] \u003d\u003d _SCOPE:"},{"line_number":52,"context_line":"                del scope[0]"},{"line_number":53,"context_line":"            else:"},{"line_number":54,"context_line":"                continue"},{"line_number":55,"context_line":"            key \u003d scope[0]"},{"line_number":56,"context_line":"            aggregate_vals \u003d metadata.get(key, None)"},{"line_number":57,"context_line":"            if not aggregate_vals:"}],"source_content_type":"text/x-python","patch_set":1,"id":"9a8ffd7b_64f14b6a","line":54,"updated":"2015-12-01 15:38:50.000000000","message":"here you\u0027re making a big user impact by asking all the operators to provide a scope, and not just using the direct name.\n\nTo be honest, I\u0027m very good with that but there are many left points that I would like to see :\n\n#1 we can\u0027t do that right in the release, we should rather deprecate the usage of not providing scoped names for that filter only for that release (and remove that in the N release) so the operators could have one cycle to change the extra specs for all the aggregates they use\n\n#2 the ComputeCapabilitiesFilter shares the same bad logic and should be part of the change - because we no longer want to provide non-scoped extra specs\n\n#3 the documentation is very poor on that, and we should at least mention that here https://github.com/openstack/nova/blob/master/doc/source/filter_scheduler.rst\n\nTo be clear, that\u0027s a very big change you want to provide even if that looks very simple.","commit_id":"6b2a1bafca8d49cc2cf5dc816e2e5167dfe33356"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"6854434ef1efc5894fc6be30df26505bbcd4b99c","unresolved":false,"context_lines":[{"line_number":51,"context_line":"            if len(scope) \u003e 1 and scope[0] \u003d\u003d _SCOPE:"},{"line_number":52,"context_line":"                del scope[0]"},{"line_number":53,"context_line":"            else:"},{"line_number":54,"context_line":"                continue"},{"line_number":55,"context_line":"            key \u003d scope[0]"},{"line_number":56,"context_line":"            aggregate_vals \u003d metadata.get(key, None)"},{"line_number":57,"context_line":"            if not aggregate_vals:"}],"source_content_type":"text/x-python","patch_set":1,"id":"fa69d971_7ffbb7c1","line":54,"in_reply_to":"9a8ffd7b_64f14b6a","updated":"2016-01-05 15:09:12.000000000","message":"Those are all good points. Two questions:\n  -- When is the good time to move this forward? Or\n  -- Is it possible to maintain the existing behavior and in the same time to support the scoped extra-specs with a simple user configurable hook? Something like STRICT_SCOPE_EXTRA_SPECS \u003d True (False by default).\n\nThanks.","commit_id":"6b2a1bafca8d49cc2cf5dc816e2e5167dfe33356"}]}