)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eeccd30701e7f38de959aabff453c9c4864f4991","unresolved":false,"context_lines":[{"line_number":16,"context_line":""},{"line_number":17,"context_line":"This is useful for deployments with mixed hypervisors where"},{"line_number":18,"context_line":"one driver supports multiattach volumes but another does not."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Change-Id: Ic6018078ac238232033098d2920a3c1fa890f113"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"ffb9cba7_6627b214","line":19,"updated":"2019-04-22 22:08:02.000000000","message":"Related-Bug: #1817927 ?\n\nI guess that\u0027s specifically about move operations and this one is about initial deploy?","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"}],"nova/compute/api.py":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"a2670bc202312c9970423a75b44751fcfc052c51","unresolved":false,"context_lines":[{"line_number":995,"context_line":"                    self._bdm_validate_set_size_and_instance(context,"},{"line_number":996,"context_line":"                        instance, instance_type, block_device_mapping,"},{"line_number":997,"context_line":"                        supports_multiattach))"},{"line_number":998,"context_line":"                self._modify_request_spec_for_multiattach("},{"line_number":999,"context_line":"                    req_spec, block_device_mapping)"},{"line_number":1000,"context_line":"                instance_tags \u003d self._transform_tags(tags, instance.uuid)"},{"line_number":1001,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_58834caa","line":998,"updated":"2019-03-21 20:17:48.000000000","message":"If you wanted you could avoid the call to the method with an if block_device_mapping: or if req_spec.is_bfv: guard\n\nNot a big deal as the method does nothing in that case, but sometimes people get super uptight about calling to methods that don\u0027t do anything.\n\nIf I were writing this, instead of passing the req_spec I would return something from the called method and not be side effecty. But again: this is fine and in keeping with norms.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac5512baac8a8ef5282d265325d5cbc3bed237c","unresolved":false,"context_lines":[{"line_number":995,"context_line":"                    self._bdm_validate_set_size_and_instance(context,"},{"line_number":996,"context_line":"                        instance, instance_type, block_device_mapping,"},{"line_number":997,"context_line":"                        supports_multiattach))"},{"line_number":998,"context_line":"                self._modify_request_spec_for_multiattach("},{"line_number":999,"context_line":"                    req_spec, block_device_mapping)"},{"line_number":1000,"context_line":"                instance_tags \u003d self._transform_tags(tags, instance.uuid)"},{"line_number":1001,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_b39a93c2","line":998,"in_reply_to":"5fc1f717_58834caa","updated":"2019-03-21 20:29:58.000000000","message":"I\u0027m re-writing this because _bdm_validate_set_size_and_instance drops my hacky multiattach attribute when it clones the list, so I\u0027m just going to return an explicit multiattach boolean parameter and only call the new method if that is True.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0919d899d521ca4799ed415c2c5ae468623c6e43","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_58226c03","line":1098,"updated":"2019-03-21 20:09:33.000000000","message":"The best would be to create the unnumbered group based on the flavor and then this function would only extend the unnumbered group. But your proposal works too and also pretty self contained.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"a2670bc202312c9970423a75b44751fcfc052c51","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_78d088ca","line":1098,"updated":"2019-03-21 20:17:48.000000000","message":"The thing that needs to be true (except in unusual situations) is that in the resulting request this trait is not on a numbered required group as we want all nested-ness to not mean anything in this filtering.\n\nI\u0027m not familiar enough with how the requested_resources list gets translated to a query string to know if this is right.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82a075ca50fc0d54ac6cd6d59a54dcd79eb53a9a","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_b8efd085","line":1098,"in_reply_to":"5fc1f717_58226c03","updated":"2019-03-21 20:15:17.000000000","message":"What if there is an existing group for a port resource request? Can I modify that or does it not matter if both groups are unnumbered?","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3ac5512baac8a8ef5282d265325d5cbc3bed237c","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_d3eb9f0f","line":1098,"in_reply_to":"5fc1f717_78d088ca","updated":"2019-03-21 20:29:58.000000000","message":"A functional test is failing and it looks like this:\n\n    2019-03-21 16:25:00,817 INFO [placement.requestlog] 127.0.0.1 \"GET /placement/allocation_candidates?limit\u003d1000\u0026required1\u003dCOMPUTE_VOLUME_MULTI_ATTACH\u0026resources\u003dMEMORY_MB%3A512%2CVCPU%3A1\u0026resources1\u003d\" status: 400 len: 402 microversion: 1.29\n\n    2019-03-21 16:25:00,818 ERROR [nova.scheduler.client.report] Failed to retrieve allocation candidates from placement API for filters: RequestGroup(aggregates\u003d[],forbidden_traits\u003dset([]),provider_uuids\u003d[],requester_id\u003dNone,required_traits\u003dset([\u0027COMPUTE_VOLUME_MULTI_ATTACH\u0027]),resources\u003d{},use_same_provider\u003dTrue), RequestGroup(aggregates\u003d[],forbidden_traits\u003dset([]),provider_uuids\u003d[],requester_id\u003dNone,required_traits\u003dset([]),resources\u003d{MEMORY_MB\u003d512,VCPU\u003d1},use_same_provider\u003dFalse)\n    Got 400: {\"errors\": [{\"request_id\": \"req-c789800b-16ef-4e0d-9d37-686c3d2a3152\", \"title\": \"Bad Request\", \"code\": \"placement.undefined_code\", \"detail\": \"The server could not comply with the request since it is either malformed or otherwise incorrect.\\n\\n Badly formed resources parameter. Expected resources query string parameter in form: ?resources\u003dVCPU:2,MEMORY_MB:1024. Got: empty string.  \", \"status\": 400}]}.\n\nI guess something down the line is munging the flavor into an unnumbered RequestGroup which is breaking with the thing I\u0027m adding which doesn\u0027t have any resources.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fdff1ee4f0c6021b75b70fabb221dceaec8c87a4","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_bc757afc","line":1098,"in_reply_to":"5fc1f717_93a19749","updated":"2019-03-22 08:05:52.000000000","message":"The request groups from the ports are always numbered. There could be only one unnumbered group. I think this trait belongs that group logically. (And by adding the trait to the flavor.extra_spec you basically make sure that it is added to the unnumbered group.) \nI guess the placement error above is caused by the fact that this new group only has required traits but no requested resources. I think that is not supported by placement.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"718d87b21a322a1982bf5022089068f87e691f8b","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_c12f3786","line":1098,"in_reply_to":"5fc1f717_bc757afc","updated":"2019-03-22 14:29:54.000000000","message":"\u003e I think that is not supported by placement.\n\nThat\u0027s correct. I wonder if we should \"fix\" that. Because there may come a day when the compute RP has no resources to give (e.g. CPU/mem in NUMA providers, shared disk) but it\u0027s still the thing exposing traits we want to filter by.\n\nI vaguely remember discussions of traits being \"inherited\" by descendants. We must have decided against it, and I don\u0027t remember why, but present me thinks it sounds like a terrible idea.\n\nBut how would we express that otherwise? root_required\u003dX,Y,Z? Or simply allow required$N\u003dX,Y,Z where there\u0027s no corresponding resources$N, and it means \"there must exist a provider in the resulting allocation with these traits\"? That\u0027s a bastardization of the granular syntax, at least if group_policy\u003disolate.\n\nFor *right now* you could make sure to stuff it in the unnumbered group, but that would mean flavors are *required* to put their VCPU/MEMORY_MB resources in the unnumbered group, which is not something we\u0027ve restricted previously. And it also goes out the window once we start doing NUMA things, which we\u0027re talking about doing for Train.\n\nI\u0027ve added this boggle to the nova/placement xproj etherpad [1] - unless you think there\u0027s an easy way to solve it.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"17ff163f81d749ee718518ef0c19e18e8f6dc1e3","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_e13d932c","line":1098,"in_reply_to":"5fc1f717_c12f3786","updated":"2019-03-22 14:36:47.000000000","message":"\u003e I vaguely remember discussions of traits being \"inherited\" by\n \u003e descendants. We must have decided against it, and I don\u0027t remember\n \u003e why, but present me thinks it sounds like a terrible idea.\n\nMy recollection was that un-numbered required was for the whole true, but numbered was not. I\u0027ll go see if I can find where we made that true.\n\nWe did make it the case that numbered requireds must be paired with a numbered resource. For the reasons you state, it does seem that the un-numbered required should not need a un-numbered pair.\n\nMatt\u0027s original trouble was because he had a numbered required and no numbered resource.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0a0e8ff01d01614f02a10db9abeaffc0a24e9f60","unresolved":false,"context_lines":[{"line_number":1095,"context_line":"                # RequestSpec.from_components will have defaulted the"},{"line_number":1096,"context_line":"                # requested_resources field to an empty list."},{"line_number":1097,"context_line":"                # TODO(mriedem): Should this be a new RequestGroup or modify"},{"line_number":1098,"context_line":"                # an existing one to add the required trait?"},{"line_number":1099,"context_line":"                LOG.debug(\u0027Modifying RequestSpec to require trait \u0027"},{"line_number":1100,"context_line":"                          \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1101,"context_line":"                          instance_uuid\u003dreqspec.instance_uuid)"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_93a19749","line":1098,"in_reply_to":"5fc1f717_d3eb9f0f","updated":"2019-03-21 21:03:02.000000000","message":"I\u0027m just going to avoid the RequestGroup complexity and have the trait hitch a ride on the RequestSpec.flavor.extra_specs.","commit_id":"bca9d737323782003aa7158bbbee5a8993e42b55"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a4b308e1aeb16c20146256188457e38419077426","unresolved":false,"context_lines":[{"line_number":1071,"context_line":"        When creating a server from an existing multi-attach volume, the"},{"line_number":1072,"context_line":"        scheduler needs to pick a host that supports multi-attach volumes."},{"line_number":1073,"context_line":"        Since the 19.0.0 Stein release, compute node resource providers"},{"line_number":1074,"context_line":"        automatically have the COMPUTE_VOLUME_MULTI_ATTACH trait set on them"},{"line_number":1075,"context_line":"        if the virt driver supports multi-attach volumes. So this method"},{"line_number":1076,"context_line":"        modifies the RequestSpec to require that trait for scheduler filtering"},{"line_number":1077,"context_line":"        in placement."}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_19ceca59","line":1074,"range":{"start_line":1074,"start_character":31,"end_line":1074,"end_character":58},"updated":"2019-03-26 08:09:30.000000000","message":"Note to self:\n\nok so this is applied to the compute node RP\nso we want to request this in the un numbered request group\nnot in a separate request group for the volume as we are not looking for a volume with COMPUTE_VOLUME_MULTI_ATTACH we are looking for a compute host.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2ad75bb77118733091a79156353fd7fd27989835","unresolved":false,"context_lines":[{"line_number":1082,"context_line":"                  \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1083,"context_line":"                  instance_uuid\u003dreqspec.instance_uuid)"},{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_f31eda72","line":1085,"updated":"2019-03-21 21:48:10.000000000","message":"Probably shouldn\u0027t persist it, because let\u0027s say you create a server that is not volume backed, but has a non-root data volume attached that is multiattach capable, then you detach that volume later and migrate it, we\u0027d force the scheduler to pick a host that supports multiattach volumes even though the server isn\u0027t using one.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"e2c6ea6fd551d5872248dcd1da8e4a527bc03432","unresolved":false,"context_lines":[{"line_number":1082,"context_line":"                  \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1083,"context_line":"                  instance_uuid\u003dreqspec.instance_uuid)"},{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_dc5de615","line":1085,"in_reply_to":"5fc1f717_b944b148","updated":"2019-03-22 07:14:42.000000000","message":"there could also be cases that I boot a server and then attached a multi-attach volume, so we still have to calculate if there is a need for multi attach able compute nodes. So I guess the safest way is not persist this and recalculate for multi attach when we doing actions","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"caf650fe28aca232fab50c17d9bae501f4603c2f","unresolved":false,"context_lines":[{"line_number":1082,"context_line":"                  \u0027COMPUTE_VOLUME_MULTI_ATTACH during scheduling.\u0027,"},{"line_number":1083,"context_line":"                  instance_uuid\u003dreqspec.instance_uuid)"},{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_b944b148","line":1085,"in_reply_to":"5fc1f717_f31eda72","updated":"2019-03-21 22:47:08.000000000","message":"Although technically we could have the same issue when migrating the server if we don\u0027t filter properly...but do we really want to try and recalculate this for every move operation? If we made this more generic with a placement pre-request filter, we\u0027d have to get the multiattach information off the BDMs attached to the instance, which is buried deep in the connection_info for attached volumes and would not exist for BDMs during server create (since they aren\u0027t attached yet). I guess we could assume that if you can create a server with a multiattach volume, chances are going to be good that you can migrate with it too.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"baaeb1a2800d3a2d8730c80491cb9641a36d92bd","unresolved":false,"context_lines":[{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""},{"line_number":1089,"context_line":"    @staticmethod"},{"line_number":1090,"context_line":"    def _retrieve_trusted_certs_object(context, trusted_certs, rebuild\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_39f521ee","line":1087,"updated":"2019-03-21 23:02:14.000000000","message":"this seems reasonable, but had you wanted to do it on the request groups, I think what would have been needed, based on the error you pasted before is that you take the request_groups[0] (if present) and extend it\u0027s required value, otherwise you add a new request group, which becomes the Nth, creating required1, which is not the thing you want.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"68da5971ac39d9e7cecf999f9d52091272e325ac","unresolved":false,"context_lines":[{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""},{"line_number":1089,"context_line":"    @staticmethod"},{"line_number":1090,"context_line":"    def _retrieve_trusted_certs_object(context, trusted_certs, rebuild\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_c2f742d4","line":1087,"in_reply_to":"5fc1f717_39f521ee","updated":"2019-03-22 02:53:12.000000000","message":"That wouldn\u0027t fix this because in the test that was failing, requested_resources was empty. The RequestGroup that was added was added by some scheduler utility code that translates the Flavor in the RequestSpec to a RequestGroup, so it does the magic with vcpu/memory_mb/disk_gb for resources and any required traits and that wasn\u0027t jiving with the RequestGroup I was adding. I\u0027m not sure why, and I\u0027m not sure if it\u0027s a bug or not, but it\u0027s definitely a very confusing interface and I didn\u0027t want to spend the time trying to grok all of that code to make it work. Hence hitching a ride, man.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a4b308e1aeb16c20146256188457e38419077426","unresolved":false,"context_lines":[{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""},{"line_number":1089,"context_line":"    @staticmethod"},{"line_number":1090,"context_line":"    def _retrieve_trusted_certs_object(context, trusted_certs, rebuild\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_f440a537","line":1087,"in_reply_to":"5fc1f717_c2f742d4","updated":"2019-03-26 08:09:30.000000000","message":"i dont think this wants to be in a numbered request group so i think this is right. at least if i was to create this flavor manually i would not have wanted to request a multi attach capable host.\n\non the conversion code we actully have two implementions\n\none that build the request form the flavor and\na second that build it from a request spec.\n\nhttps://github.com/openstack/nova/blob/10b375990d6c24d09c1da2fea459f32c286c4b02/nova/scheduler/utils.py#L383-L493\n\nwe only use resources_from_flavor in two places\n_heal_allocations_for_instance and and we use it in the report client\n_instance_to_allocations_dict which is only used in tests.\ni think the _heal_allocations_for_instance period task should acully be useing the request spec form too as currently that task will ignore requests form ports and images/volumes\n\ni might open a bug for that and go fix it as its going to do more harm then good longterm.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bb96bd2a843cc10f15ea23f810e1888f5d45053c","unresolved":false,"context_lines":[{"line_number":1084,"context_line":"        # Hitch a ride on the flavor that will be used during scheduling."},{"line_number":1085,"context_line":"        # TODO(mriedem): Should we reset this change so it does not get saved?"},{"line_number":1086,"context_line":"        reqspec.flavor.extra_specs["},{"line_number":1087,"context_line":"            \u0027trait:%s\u0027 % os_traits.COMPUTE_VOLUME_MULTI_ATTACH] \u003d \u0027required\u0027"},{"line_number":1088,"context_line":""},{"line_number":1089,"context_line":"    @staticmethod"},{"line_number":1090,"context_line":"    def _retrieve_trusted_certs_object(context, trusted_certs, rebuild\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":2,"id":"5fc1f717_d4bec9ac","line":1087,"in_reply_to":"5fc1f717_f440a537","updated":"2019-03-26 08:26:47.000000000","message":"sorry its not the _heal_allocations_for_instance periodic task the resouce_from_flavor is used in the nova manage command but im not sure that is correct.\n\nanyway this code hits \nhttps://github.com/openstack/nova/blob/b33fa1c054ba4b7d4e789aa51250ad5c8325da2d/nova/scheduler/utils.py#L449-L459\nin resources_from_request_spec\n\nwhich calls \n\nhttps://github.com/openstack/nova/blob/b33fa1c054ba4b7d4e789aa51250ad5c8325da2d/nova/scheduler/utils.py#L135-L183\n\nto actully extract the resouce and traits requests.\n\nso this will add this trait to the un numbered traits request group which is correct.","commit_id":"f462949b2da1415e9078f41a872175af8b38d658"}]}