)]}'
{"specs/xena/qos-minimum-guaranteed-packet-rate.rst":[{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":109,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":110,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":111,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":112,"context_line":"                    \u0027default\u0027: constants.EGRESS_DIRECTION,"},{"line_number":113,"context_line":"                    \u0027validate\u0027: {"},{"line_number":114,"context_line":"                        \u0027type:values\u0027: constants.VALID_DIRECTIONS}"},{"line_number":115,"context_line":"                }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8c188d9b_89bec6e7","line":112,"updated":"2021-04-08 14:02:12.000000000","message":"Is egress/ingress meant from the perspective of instance port, softswitch or compute host?\n\nPlease note the possible combinations too, like traffic that flows from one vm to another vm on the same host: that is ingress and egress at the same time for the softswitch, but neither ingress nor egress for the compute.\n\nAlso I\u0027m wondering how we want to address packet processing capacity consumed by incoming traffic? In a fully cooperative environment I guess the admin could come up with an educated guess of outgoing/incoming packet ratio and reserve packet processing capacity based on that. It seems to me we cannot make guarantees if the environment is not fully cooperative. Or can we?","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":true,"context_lines":[{"line_number":109,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":110,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":111,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":112,"context_line":"                    \u0027default\u0027: constants.EGRESS_DIRECTION,"},{"line_number":113,"context_line":"                    \u0027validate\u0027: {"},{"line_number":114,"context_line":"                        \u0027type:values\u0027: constants.VALID_DIRECTIONS}"},{"line_number":115,"context_line":"                }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c9d1a29b_82cfdccf","line":112,"in_reply_to":"40660fd1_a0a3e586","updated":"2021-04-13 14:33:22.000000000","message":"\u003e Is egress/ingress meant from the perspective of instance port, softswitch or compute host?\n\n\u003e For QoS I would keep that direction is from the instance\u0027s perspective:\n\u003e https://docs.openstack.org/neutron/latest/admin/config-qos.html#supported-qos-rule-types\n\ninstance\u0027s port perspective as in case of min bw. I\u0027ve added some explanation under this codeblock.\n\n\u003e Please note the possible combinations too, like traffic that flows from one vm to another \n\u003e vm on the same host: that is ingress and egress at the same time for the softswitch, but \n\u003e neither ingress nor egress for the compute.\n\nIf there are two VMs A and B on the same host. Both A and B has both ingress and egress packet rate guarantees. Then when A sends a packet to B that packet is counted against the egress guarantee of A and the ingress guarantee of B. But both resource usages are counted against the same OVS resource inventory. So in case of same host traffic we allocate more resource in placement that actually used by the OVS to move the packet. This does not break the guarantee but it results in sub optimal workload placement if the majority of the traffic is between VMs on the same host. Honestly I don\u0027t see how can we optimize this during schedule time.\n\n\u003e Also I\u0027m wondering how we want to address packet processing capacity consumed by incoming traffic? \n\u003e In a fully cooperative environment I guess the admin could come up with an educated guess of \n\u003e outgoing/incoming packet ratio and reserve packet processing capacity based on that. It seems to \n\u003e me we cannot make guarantees if the environment is not fully cooperative. Or can we?\n\nI\u0027m not an expert here. I assume that if OVS can drop the incoming packet cheaply at the point when it arrives then we can provide guarantees. If dropping incoming traffic is as expensive as forwarding them, then I agree that we cannot handle excessive ingress traffic.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"57af24eff18af3bd11584b1b4d9da58c5ba44bae","unresolved":true,"context_lines":[{"line_number":109,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":110,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":111,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":112,"context_line":"                    \u0027default\u0027: constants.EGRESS_DIRECTION,"},{"line_number":113,"context_line":"                    \u0027validate\u0027: {"},{"line_number":114,"context_line":"                        \u0027type:values\u0027: constants.VALID_DIRECTIONS}"},{"line_number":115,"context_line":"                }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"40660fd1_a0a3e586","line":112,"in_reply_to":"8c188d9b_89bec6e7","updated":"2021-04-09 12:29:46.000000000","message":"For QoS I would keep that direction is from the instance\u0027s perspective:\nhttps://docs.openstack.org/neutron/latest/admin/config-qos.html#supported-qos-rule-types","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":116,"context_line":"            }"},{"line_number":117,"context_line":"        }"},{"line_number":118,"context_line":"    }"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This results in the following new API resources and operations:"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* ``GET``: List minimum packet rate rules for QoS policy"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ab154f63_924c206b","line":119,"updated":"2021-04-08 14:02:12.000000000","message":"Does this new rule type apply to ports not belonging to instances?","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":116,"context_line":"            }"},{"line_number":117,"context_line":"        }"},{"line_number":118,"context_line":"    }"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This results in the following new API resources and operations:"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"* ``GET``: List minimum packet rate rules for QoS policy"}],"source_content_type":"text/x-rst","patch_set":1,"id":"35ebbf78_66c65c1f","line":119,"in_reply_to":"ab154f63_924c206b","updated":"2021-04-13 14:33:22.000000000","message":"It definitely only apply to bound ports. If the port is not bound by Nova (I don\u0027t know who else bounds ports in Neutron) then Nova cannot guarantee that the resource allocation is created in placement. In theory service bounding ports in Neutron can look at the resource_request of the port and make the necessary resource allocation in placement to keep the consistency. However enforcing this is not in scope either of the Nova or the Neutron spec.\n\nI\u0027ve added a sentence here to clarify this.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":212,"context_line":"OVS packet processing capacity"},{"line_number":213,"context_line":"------------------------------"},{"line_number":214,"context_line":"Neutron OVS agent needs to provide a configuration option for the"},{"line_number":215,"context_line":"administrator to define the maximum packet processing capability of the OVS"},{"line_number":216,"context_line":"per compute node. This means the following new configuration option is added"},{"line_number":217,"context_line":"to OVS agent configuration::"},{"line_number":218,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"6e74b91d_13d4715c","line":215,"range":{"start_line":215,"start_character":28,"end_line":215,"end_character":64},"updated":"2021-04-08 14:02:12.000000000","message":"I assume we only have a relatively static packet processing capability when we use DPDK based OVS and a set number of CPU cores are exclusively assigned to packet processing. Is this correct?\n\nIf it is, this also may be worth mentioning here and adding to the docs in the implementation.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":212,"context_line":"OVS packet processing capacity"},{"line_number":213,"context_line":"------------------------------"},{"line_number":214,"context_line":"Neutron OVS agent needs to provide a configuration option for the"},{"line_number":215,"context_line":"administrator to define the maximum packet processing capability of the OVS"},{"line_number":216,"context_line":"per compute node. This means the following new configuration option is added"},{"line_number":217,"context_line":"to OVS agent configuration::"},{"line_number":218,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1023f6d9_a1a020b8","line":215,"range":{"start_line":215,"start_character":28,"end_line":215,"end_character":64},"in_reply_to":"6e74b91d_13d4715c","updated":"2021-04-13 14:33:22.000000000","message":"\u003e I assume we only have a relatively static packet processing capability when we use DPDK based OVS and a set number of CPU cores are exclusively assigned to packet processing. Is this correct?\n\u003e \n\u003e If it is, this also may be worth mentioning here and adding to the docs in the implementation.\n\nthe packet processing capacity of an OVS instance depends on may factors. Number of CPU cores, the exclusive usage of such cores, NUMA location of the OVS cpu core compared to the location of the cpu core of the VM (cross NUMA talk is more expansive then same NUMA). So to be able to define the packet processing capacity of a specific deployment, the admin needs to do measurement in that setup with a relativistic traffic mix. Fortunately the admin can start with a pretty conservative estimate, do the configuration based on that, monitor the load, and increase the capacity if the monitoring proves that plenty of capacity is still available.\n\nThis will be documented in the new admin guide for this feature.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":217,"context_line":"to OVS agent configuration::"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"    [ovs]"},{"line_number":220,"context_line":"    # Coma-separated list of \u003chypervisor\u003e:\u003cpacket_rate\u003e tuples, defining the"},{"line_number":221,"context_line":"    # minimum packet rate the OVS backend can guarantee in kilo packet per"},{"line_number":222,"context_line":"    # second. The hypervisor name is used to locate the parent of the resource"},{"line_number":223,"context_line":"    # provider tree. Only needs to be set in the rare case when the hypervisor"}],"source_content_type":"text/x-rst","patch_set":1,"id":"222552ec_aa31eba9","line":220,"range":{"start_line":220,"start_character":6,"end_line":220,"end_character":10},"updated":"2021-04-08 14:02:12.000000000","message":"Comma :-)","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":217,"context_line":"to OVS agent configuration::"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"    [ovs]"},{"line_number":220,"context_line":"    # Coma-separated list of \u003chypervisor\u003e:\u003cpacket_rate\u003e tuples, defining the"},{"line_number":221,"context_line":"    # minimum packet rate the OVS backend can guarantee in kilo packet per"},{"line_number":222,"context_line":"    # second. The hypervisor name is used to locate the parent of the resource"},{"line_number":223,"context_line":"    # provider tree. Only needs to be set in the rare case when the hypervisor"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c37596c6_1deee4af","line":220,"range":{"start_line":220,"start_character":6,"end_line":220,"end_character":10},"in_reply_to":"222552ec_aa31eba9","updated":"2021-04-13 14:33:22.000000000","message":"My brain was in a coma like situation at this point I guess. ;]","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":227,"context_line":"    # The default is :0 which means no packet processing capacity is guaranteed"},{"line_number":228,"context_line":"    # on the hypervisor named according to DEFAULT.host."},{"line_number":229,"context_line":"    # The fine grained resource inventory configuration defined in the"},{"line_number":230,"context_line":"    # resource_provider_inventory_defaults config option applies to this"},{"line_number":231,"context_line":"    # resource too."},{"line_number":232,"context_line":"    # packet_processing_capacity \u003d :0"},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c2d79f0e_7185b541","line":230,"range":{"start_line":230,"start_character":6,"end_line":230,"end_character":42},"updated":"2021-04-08 14:02:12.000000000","message":"Are you sure we want to share this between bandwidth and packet rate? For example would we always want to have the same \u0027reserved\u0027 value for both?","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":227,"context_line":"    # The default is :0 which means no packet processing capacity is guaranteed"},{"line_number":228,"context_line":"    # on the hypervisor named according to DEFAULT.host."},{"line_number":229,"context_line":"    # The fine grained resource inventory configuration defined in the"},{"line_number":230,"context_line":"    # resource_provider_inventory_defaults config option applies to this"},{"line_number":231,"context_line":"    # resource too."},{"line_number":232,"context_line":"    # packet_processing_capacity \u003d :0"},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a5e7b8c_5d5875e3","line":230,"range":{"start_line":230,"start_character":6,"end_line":230,"end_character":42},"in_reply_to":"c2d79f0e_7185b541","updated":"2021-04-13 14:33:22.000000000","message":"good point. I\u0027ve added a separate config option.\n\nBtw, is it a good idea that we have the same reserved value for both ingress bw and egress bw? ;)","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":291,"context_line":"separate set of resources::"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    {"},{"line_number":294,"context_line":"        {"},{"line_number":295,"context_line":"            \"resource_request_id\": \u003csome unique identifier\u003e"},{"line_number":296,"context_line":"            \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e, \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":297,"context_line":"            \"resources\":"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2a6152f6_6e9a6005","line":294,"range":{"start_line":294,"start_character":8,"end_line":294,"end_character":9},"updated":"2021-04-08 14:02:12.000000000","message":"I guess this wanted to be enclosed in a list or a dict.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":291,"context_line":"separate set of resources::"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    {"},{"line_number":294,"context_line":"        {"},{"line_number":295,"context_line":"            \"resource_request_id\": \u003csome unique identifier\u003e"},{"line_number":296,"context_line":"            \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e, \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":297,"context_line":"            \"resources\":"}],"source_content_type":"text/x-rst","patch_set":1,"id":"aead5dd9_cecd5851","line":294,"range":{"start_line":294,"start_character":8,"end_line":294,"end_character":9},"in_reply_to":"2a6152f6_6e9a6005","updated":"2021-04-13 14:33:22.000000000","message":"yepp, it should be a list of dicts. Fixed already in PS2.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":308,"context_line":"                \u003crequested bandwidth amount from the QoS policy\u003e"},{"line_number":309,"context_line":"            }"},{"line_number":310,"context_line":"        },"},{"line_number":311,"context_line":"    }"},{"line_number":312,"context_line":""},{"line_number":313,"context_line":"Each nested dict represents one set of resources and traits that needs to be"},{"line_number":314,"context_line":"fulfilled from a single resource provider. E.g. either from the bridge RP in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"07b9d737_e074db0f","line":311,"updated":"2021-04-08 14:02:12.000000000","message":"Also at the top-level dict we could introduce something like \u0027resource_request_version: 1/2/etc\u0027.\n\nThe would make sense to nova (or anyone else) processing this structure, predicting which format to expect, instead of guessing it.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":true,"context_lines":[{"line_number":308,"context_line":"                \u003crequested bandwidth amount from the QoS policy\u003e"},{"line_number":309,"context_line":"            }"},{"line_number":310,"context_line":"        },"},{"line_number":311,"context_line":"    }"},{"line_number":312,"context_line":""},{"line_number":313,"context_line":"Each nested dict represents one set of resources and traits that needs to be"},{"line_number":314,"context_line":"fulfilled from a single resource provider. E.g. either from the bridge RP in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5534dfa2_c4f39539","line":311,"in_reply_to":"07b9d737_e074db0f","updated":"2021-04-13 14:33:22.000000000","message":"This seems like a new new strategy in Neutron. I thought Neutron versions the API via API extensions normally. I planned to introduce a new API extension to signal that the structure of this field has been changed. But sure we can discuss this.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"6e64cd8c98529e600af42ec763cd65faac06f8e8","unresolved":true,"context_lines":[{"line_number":318,"context_line":"field, it is just a dict, so from Neutron perspective there is no need for a"},{"line_number":319,"context_line":"new API extension to change the structure. However from Nova needs to know"},{"line_number":320,"context_line":"which format will be used by Neutron so a new, mandatory Neutron API extension"},{"line_number":321,"context_line":"will be introduced to signal the format change to Nova."},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"Port binding"},{"line_number":324,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"904e9f51_65007450","line":321,"updated":"2021-04-08 14:02:12.000000000","message":"Alternatively at the top-level dict we could introduce something like \u0027resource_request_version: ...\u0027.\n\nThe would make sense to nova (or anyone else) processing this structure, predicting which format to expect, instead of guessing it.\n\nAlso it would be right where it is needed, not far away in the extension api.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":true,"context_lines":[{"line_number":318,"context_line":"field, it is just a dict, so from Neutron perspective there is no need for a"},{"line_number":319,"context_line":"new API extension to change the structure. However from Nova needs to know"},{"line_number":320,"context_line":"which format will be used by Neutron so a new, mandatory Neutron API extension"},{"line_number":321,"context_line":"will be introduced to signal the format change to Nova."},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"Port binding"},{"line_number":324,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0fed1411_595accb2","line":321,"in_reply_to":"904e9f51_65007450","updated":"2021-04-13 14:33:22.000000000","message":"This does feel a new strategy in Neutron. So I\u0027m a bit afraid to be the first one to do introduce it.\n\nI will add this as an alternative so that it can be discussed thoroughly.","commit_id":"8df321e85c6fdcd1f0a77b9b86f82614592579b7"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"bb282e13fa312e6b99ac4612a6f8f17af3f6ee69","unresolved":true,"context_lines":[{"line_number":106,"context_line":"                \u0027direction\u0027: {"},{"line_number":107,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":108,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":109,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":110,"context_line":"                    \u0027default\u0027: constants.EGRESS_DIRECTION,"},{"line_number":111,"context_line":"                    \u0027validate\u0027: {"},{"line_number":112,"context_line":"                        \u0027type:values\u0027: constants.VALID_DIRECTIONS}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e22ed82d_a2062827","line":109,"updated":"2021-04-09 14:21:30.000000000","message":"This should also include filtering and sorting, same as other qos rules.","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"57af24eff18af3bd11584b1b4d9da58c5ba44bae","unresolved":true,"context_lines":[{"line_number":248,"context_line":"   has direction. From scheduling perspective the direction of the QoS rule"},{"line_number":249,"context_line":"   does not matter and both direction will be counted against the single"},{"line_number":250,"context_line":"   directionless resource inventory. However, later, for data plane enforcement"},{"line_number":251,"context_line":"   the policing of the incoming and outgoing packets needs to done separately."},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"The ``configurations`` field of the OVS agent heartbeat RPC message is extended"},{"line_number":254,"context_line":"to report the packet processing capacity configuration to the Neutron server."}],"source_content_type":"text/x-rst","patch_set":2,"id":"84550dd0_7a107412","line":251,"range":{"start_line":251,"start_character":59,"end_line":251,"end_character":67},"updated":"2021-04-09 12:29:46.000000000","message":"nit: to be done","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":false,"context_lines":[{"line_number":248,"context_line":"   has direction. From scheduling perspective the direction of the QoS rule"},{"line_number":249,"context_line":"   does not matter and both direction will be counted against the single"},{"line_number":250,"context_line":"   directionless resource inventory. However, later, for data plane enforcement"},{"line_number":251,"context_line":"   the policing of the incoming and outgoing packets needs to done separately."},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"The ``configurations`` field of the OVS agent heartbeat RPC message is extended"},{"line_number":254,"context_line":"to report the packet processing capacity configuration to the Neutron server."}],"source_content_type":"text/x-rst","patch_set":2,"id":"0af4d12e_650763df","line":251,"range":{"start_line":251,"start_character":59,"end_line":251,"end_character":67},"in_reply_to":"84550dd0_7a107412","updated":"2021-04-13 14:33:22.000000000","message":"Done","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"bb282e13fa312e6b99ac4612a6f8f17af3f6ee69","unresolved":true,"context_lines":[{"line_number":305,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":306,"context_line":"                \"resources\":"},{"line_number":307,"context_line":"                {"},{"line_number":308,"context_line":"                    NET_KILOPACKET_PER_SEC:"},{"line_number":309,"context_line":"                    \u003camount requested via the QoS policy\u003e"},{"line_number":310,"context_line":"                }"},{"line_number":311,"context_line":"            },"}],"source_content_type":"text/x-rst","patch_set":2,"id":"eac26ea5_3b4bec42","line":308,"range":{"start_line":308,"start_character":20,"end_line":308,"end_character":42},"updated":"2021-04-09 14:21:30.000000000","message":"we support both directions","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":true,"context_lines":[{"line_number":305,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":306,"context_line":"                \"resources\":"},{"line_number":307,"context_line":"                {"},{"line_number":308,"context_line":"                    NET_KILOPACKET_PER_SEC:"},{"line_number":309,"context_line":"                    \u003camount requested via the QoS policy\u003e"},{"line_number":310,"context_line":"                }"},{"line_number":311,"context_line":"            },"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ece11c22_f1d0d1ee","line":308,"range":{"start_line":308,"start_character":20,"end_line":308,"end_character":42},"in_reply_to":"eac26ea5_3b4bec42","updated":"2021-04-13 14:33:22.000000000","message":"The QoS policy is direction aware but the resource inventory is direction less. See L247 for reasoning.","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"bb282e13fa312e6b99ac4612a6f8f17af3f6ee69","unresolved":true,"context_lines":[{"line_number":354,"context_line":"  with the same ``vnic_type`` so it is also fulfilled from the OVS backend."},{"line_number":355,"context_line":"  If we go with this direction then special care needs to be taken to document"},{"line_number":356,"context_line":"  the above assumption carefully so that future developers can check if any of"},{"line_number":357,"context_line":"  the statements become invalid due to new feature additions."},{"line_number":358,"context_line":""},{"line_number":359,"context_line":".. _`The QoS configuration`: https://docs.openstack.org/neutron/latest/admin/config-qos-min-bw.html#neutron-server-config"},{"line_number":360,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"c1bc97a1_b2b36e7b","line":357,"range":{"start_line":357,"start_character":60,"end_line":357,"end_character":61},"updated":"2021-04-09 14:21:30.000000000","message":"I don\u0027t see the problem here (maybe because I don\u0027t understand placement well).\n\nWe can create agent RPs with (minBW) or (minBW,minPKTS). When requesting a port, we can ask for each one of those resources or both, and consume then in the placement. If the minPKTS is zero or None, it doesn\u0027t matter if, for example, the RP does not have this trait. Right?\n\nOr is this a problem on how Neutron builds the request?","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fa894d0f0180162d46f5f2fc7f706889bf6f52cb","unresolved":true,"context_lines":[{"line_number":354,"context_line":"  with the same ``vnic_type`` so it is also fulfilled from the OVS backend."},{"line_number":355,"context_line":"  If we go with this direction then special care needs to be taken to document"},{"line_number":356,"context_line":"  the above assumption carefully so that future developers can check if any of"},{"line_number":357,"context_line":"  the statements become invalid due to new feature additions."},{"line_number":358,"context_line":""},{"line_number":359,"context_line":".. _`The QoS configuration`: https://docs.openstack.org/neutron/latest/admin/config-qos-min-bw.html#neutron-server-config"},{"line_number":360,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"e7369bdf_56f382ce","line":357,"range":{"start_line":357,"start_character":60,"end_line":357,"end_character":61},"in_reply_to":"c1bc97a1_b2b36e7b","updated":"2021-04-13 14:33:22.000000000","message":"yes, it is about the structure of the request. \n\nIf neutron simply adds the packet rate resource to the current request structure like:\n\n    {\n        \"required\": [CUSTOM_PHYSNET_1, CUSTOM_VNIC_TYPE_NORMAL],\n        \"resources\": {\n            NET_BW_EGR_KILOBIT_PER_SEC: 1000,\n            NET_BW_IGR_KILOBIT_PER_SEC: 1000,\n            NET_KILOPACKET_PER_SEC: 1000,\n        }\n    }\n\nThen placement will fail to find allocation candidates as there is no single RP in the system that provides both packet rate and bandwidth as well.\n\nIf neutron asks the bandwidth and the packet rate separately like in L300, then placement will fullfill them separately by finding the OVS Agent RP for the packet rate and the OVS bridge RP for the bandwidth request. This is good today. As it means that both the packet rate and the bandwidth are allocated from the same entity, from OVS. However if we want to make sure that in the future never allocate one resource from an SRIOV PF and one resource from OVS bridge for the same port, then we need an extra rule. Today the SRIOV and the OVS RPs are organized into two separate subtree. So that extra rule is that every resource for a single port should be allocated from a same provider subtree. These alternatives are about selecting from how to handle this extra same_subtree rule.","commit_id":"f2bf4ed63fd6cded342d791f1368b08882f1f47c"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":47,"context_line":"* data plane: Enforcing the guarantee on the soft switch"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This spec addresses placement enforcement only. Data plane enforcement"},{"line_number":50,"context_line":"can be developed later."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Use cases"},{"line_number":53,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"682cc0b7_9d31218d","line":50,"updated":"2021-04-26 15:05:37.000000000","message":"feedback from the PTG: a basic form of data plane enforcement can be implemented by using the packet rate limiter QoS along with the min packet rate QoS rule. If the max_pps value is set to min_pps value and the every VM on the host has a min_pps (and therefore max_pps) defined then the max_pps data plane rules will implement a basic form of minimum guarantees as well.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":47,"context_line":"* data plane: Enforcing the guarantee on the soft switch"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This spec addresses placement enforcement only. Data plane enforcement"},{"line_number":50,"context_line":"can be developed later."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Use cases"},{"line_number":53,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"333128ed_8afdc735","line":50,"in_reply_to":"682cc0b7_9d31218d","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":115,"context_line":"        }"},{"line_number":116,"context_line":"    }"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":119,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":120,"context_line":"that at least 1000 packet can enter the Nova server via the given port per"},{"line_number":121,"context_line":"second."},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7d52c818_2b511684","line":119,"range":{"start_line":118,"start_character":68,"end_line":119,"end_character":8},"updated":"2021-04-23 14:34:31.000000000","message":"nit: In neutron documentation usually VM is used, \"Nova server\" should make somebody to think the service (nova-api), but perhaps this is only my thinking","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":115,"context_line":"        }"},{"line_number":116,"context_line":"    }"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":119,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":120,"context_line":"that at least 1000 packet can enter the Nova server via the given port per"},{"line_number":121,"context_line":"second."},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"a75fb305_b0015dce","line":119,"range":{"start_line":118,"start_character":68,"end_line":119,"end_character":8},"in_reply_to":"7d52c818_2b511684","updated":"2021-04-28 16:57:25.000000000","message":"replaced all occurrences with VM. Though in general it is not correct in every cases, e.g. when ironic is used a nova server is backed by bare metal server not a VM.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":123,"context_line":"Neutron provides the necessary information to any client via"},{"line_number":124,"context_line":"the ``resource_request`` of the port to allow the client to keep the placement"},{"line_number":125,"context_line":"resource allocation consistent and therefore implement the schedule time"},{"line_number":126,"context_line":"guarantee. Nova will use this information to do so. However neither Neutron nor"},{"line_number":127,"context_line":"Nova can enforce that another client bounding ports are also properly"},{"line_number":128,"context_line":"allocation resources. This is out of scope."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"This results in the following new API resources and operations:"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f405226_af7307c8","line":128,"range":{"start_line":126,"start_character":52,"end_line":128,"end_character":43},"updated":"2021-04-23 14:34:31.000000000","message":"Perhaps this wording can be better: \"However neither Neutron nor Nova can enforce that another client which can bound ports (will?) properly allocate resources.\"","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":123,"context_line":"Neutron provides the necessary information to any client via"},{"line_number":124,"context_line":"the ``resource_request`` of the port to allow the client to keep the placement"},{"line_number":125,"context_line":"resource allocation consistent and therefore implement the schedule time"},{"line_number":126,"context_line":"guarantee. Nova will use this information to do so. However neither Neutron nor"},{"line_number":127,"context_line":"Nova can enforce that another client bounding ports are also properly"},{"line_number":128,"context_line":"allocation resources. This is out of scope."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"This results in the following new API resources and operations:"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"113dd8f4_bc7a0445","line":128,"range":{"start_line":126,"start_character":52,"end_line":128,"end_character":43},"in_reply_to":"9f405226_af7307c8","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":257,"context_line":".. note::"},{"line_number":258,"context_line":"   Note that while bandwidth inventory is defined per OVS bridge in the"},{"line_number":259,"context_line":"   ``[ovs]resource_provider_bandwidths`` configuration option, the packet"},{"line_number":260,"context_line":"   processing capacity is applied globally to the whole OVS instance."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":".. note::"},{"line_number":263,"context_line":"   Note that this resource is directionless while the proposed new QoS rule"}],"source_content_type":"text/x-rst","patch_set":3,"id":"221feb83_9fe5e4d8","line":260,"range":{"start_line":260,"start_character":3,"end_line":260,"end_character":69},"updated":"2021-04-26 15:05:37.000000000","message":"Feedback from the PTG: Please investigate what would it mean if we report the packet processing capacity per OVS bridge as an alternative.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"26e92465d6af98ef9e0aa7702fdea0263731cb7e","unresolved":true,"context_lines":[{"line_number":257,"context_line":".. note::"},{"line_number":258,"context_line":"   Note that while bandwidth inventory is defined per OVS bridge in the"},{"line_number":259,"context_line":"   ``[ovs]resource_provider_bandwidths`` configuration option, the packet"},{"line_number":260,"context_line":"   processing capacity is applied globally to the whole OVS instance."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":".. note::"},{"line_number":263,"context_line":"   Note that this resource is directionless while the proposed new QoS rule"}],"source_content_type":"text/x-rst","patch_set":3,"id":"54932302_69f140c1","line":260,"range":{"start_line":260,"start_character":3,"end_line":260,"end_character":69},"in_reply_to":"221feb83_9fe5e4d8","updated":"2021-04-26 16:05:12.000000000","message":"The big advantage of having the pps resource represented on the OVS bridge, on the same place as the bandwidth resource, is that it would simplify the overall design. It means that we could still keep the assumption that the resource request of the port is always fulfilled from a single resource provider. Therefore the format of the port.resource_request  and the port.bindig:profile.allocation does not need to change. \n\nOne drawback is that if we define packet processing capacity on the bridges then if there are multiple bridges then the overall packet processing capacity of the whole OVS would need to be statically split between the bridges. And multiple bridges are possible, even in the simple case of having one phynet bridge for vlan traffic and one tunneling bridge for vxlan traffic. \n\nAlso in case of bandwidth the actual resource is behind the physnet bridge, the physical interface the bridge is connected to so the resource is dedicated to the bridge. But in case of packet processing the actual resource is not at all dedicated to the given bridge. So while we can assign a portion of the overall resource to the bridge this assignment would never represent the reality well.\n\nAlso if we keep the resource globally on OVS then the host only traffic can be better accounted for as it does go through the OVS but it does not go through physnet or tunneling bridges.\n\nAlso while the currently proposed design change is significant it makes the solution more future proof. E.g. for the case when the IP pool resource handling will be refactored to use the port\u0027s resource_request then we anyhow need to be able to handle another resource provider that will not be the same as any of the existing ones as the IP addresses are shared resource between multiple host. \n\n\n[1] https://docs.openstack.org/neutron/latest/admin/config-qos-min-bw.html#limitations","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":257,"context_line":".. note::"},{"line_number":258,"context_line":"   Note that while bandwidth inventory is defined per OVS bridge in the"},{"line_number":259,"context_line":"   ``[ovs]resource_provider_bandwidths`` configuration option, the packet"},{"line_number":260,"context_line":"   processing capacity is applied globally to the whole OVS instance."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":".. note::"},{"line_number":263,"context_line":"   Note that this resource is directionless while the proposed new QoS rule"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0a658ea8_22399353","line":260,"range":{"start_line":260,"start_character":3,"end_line":260,"end_character":69},"in_reply_to":"54932302_69f140c1","updated":"2021-04-28 16:57:25.000000000","message":"Done, described in the Nova spec and referred it from this spec","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":261,"context_line":""},{"line_number":262,"context_line":".. note::"},{"line_number":263,"context_line":"   Note that this resource is directionless while the proposed new QoS rule"},{"line_number":264,"context_line":"   has direction. From scheduling perspective the direction of the QoS rule"},{"line_number":265,"context_line":"   does not matter and both direction will be counted against the single"},{"line_number":266,"context_line":"   directionless resource inventory. However, later, for data plane enforcement"},{"line_number":267,"context_line":"   the policing of the incoming and outgoing packets needs to be done"},{"line_number":268,"context_line":"   separately."},{"line_number":269,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"aa3e22f1_30c5edc5","line":266,"range":{"start_line":264,"start_character":18,"end_line":266,"end_character":36},"updated":"2021-04-26 15:05:37.000000000","message":"Feedback from the PTG: In case of OVS with vnic_type\u003dnormal it is OK to have a directionless resource as OVS in this case is CPU limited and that CPU is shared between directions. However in case of VOS with vnic_type\u003ddirect (e.g. when OVS is hardware offloaded) the different directions are handled by different hardware queues and therefore they have independent packet processing capacity. Therefore an OVS with offload should report a direction aware resource while the normal OVS should report a directionless resource. \n\nThis also means that when the port has vnic_type\u003dnormal then the neutron should put the sum of the requested pps from the QoS rules to the resource_request as a directionless request. But when the vnic_type is direct then neutron should but the two QoS rules as two independent request towards the direction aware resource.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":261,"context_line":""},{"line_number":262,"context_line":".. note::"},{"line_number":263,"context_line":"   Note that this resource is directionless while the proposed new QoS rule"},{"line_number":264,"context_line":"   has direction. From scheduling perspective the direction of the QoS rule"},{"line_number":265,"context_line":"   does not matter and both direction will be counted against the single"},{"line_number":266,"context_line":"   directionless resource inventory. However, later, for data plane enforcement"},{"line_number":267,"context_line":"   the policing of the incoming and outgoing packets needs to be done"},{"line_number":268,"context_line":"   separately."},{"line_number":269,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"d74b1fa0_39b1fecc","line":266,"range":{"start_line":264,"start_character":18,"end_line":266,"end_character":36},"in_reply_to":"aa3e22f1_30c5edc5","updated":"2021-04-28 16:57:25.000000000","message":"described in the Nova spec and referred from the Neutron spec","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":377,"context_line":""},{"line_number":378,"context_line":"* Requests ``same_subtree`` in the ``resource_request``. Placement supports a"},{"line_number":379,"context_line":"  ``same_subtree`` parameter that can express what we need. Neutron can add a"},{"line_number":380,"context_line":"  new top level key ``same_subtree`` to the ``resource_request`` dict. E.g.::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0a71dbdc_11efc4b3","line":380,"updated":"2021-04-26 15:05:37.000000000","message":"feedback from the PTG: This is the preferred solution as later on when the IP allocation pool handling are transformed to use the resource request, that resource will come from a sharing resource provider and therefore nova cannot implicitly assume same_subtree for the whole resource_request.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":377,"context_line":""},{"line_number":378,"context_line":"* Requests ``same_subtree`` in the ``resource_request``. Placement supports a"},{"line_number":379,"context_line":"  ``same_subtree`` parameter that can express what we need. Neutron can add a"},{"line_number":380,"context_line":"  new top level key ``same_subtree`` to the ``resource_request`` dict. E.g.::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"}],"source_content_type":"text/x-rst","patch_set":3,"id":"241e855a_71bbf745","line":380,"in_reply_to":"0a71dbdc_11efc4b3","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":422,"context_line":"* Let Nova guess based on the structure. The new top level ``request_groups``"},{"line_number":423,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":424,"context_line":""},{"line_number":425,"context_line":"``TBD``: Select an alternative. I personally in favor of the API extension as"},{"line_number":426,"context_line":"that feels like the standard way in Neutron to signal API change."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"When Neutron calculates the content of the ``resource_request`` for a port the"},{"line_number":429,"context_line":"``min_pps`` value from the minimum_packet_rate QoS policy rules defined for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e3896696_ee7ed7ab","line":426,"range":{"start_line":425,"start_character":0,"end_line":426,"end_character":65},"updated":"2021-04-23 14:34:31.000000000","message":"+1\na shim extension is perfectly for this kind of changes","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":422,"context_line":"* Let Nova guess based on the structure. The new top level ``request_groups``"},{"line_number":423,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":424,"context_line":""},{"line_number":425,"context_line":"``TBD``: Select an alternative. I personally in favor of the API extension as"},{"line_number":426,"context_line":"that feels like the standard way in Neutron to signal API change."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"When Neutron calculates the content of the ``resource_request`` for a port the"},{"line_number":429,"context_line":"``min_pps`` value from the minimum_packet_rate QoS policy rules defined for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"77d23510_b463ded7","line":426,"range":{"start_line":425,"start_character":0,"end_line":426,"end_character":65},"in_reply_to":"e3896696_ee7ed7ab","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":433,"context_line":"Port binding"},{"line_number":434,"context_line":"------------"},{"line_number":435,"context_line":""},{"line_number":436,"context_line":"Today Nova sends the UUID of the resource provider the port\u0027s"},{"line_number":437,"context_line":"``resource_request`` fulfilled from in the ``allocation`` key of"},{"line_number":438,"context_line":"``binding:profile``. The port binding logic uses this information to bind the"},{"line_number":439,"context_line":"port to the same physical device or OVS bridge the port\u0027s resources are"},{"line_number":440,"context_line":"allocated from. This is necessary as it is allowed to have multiple such"},{"line_number":441,"context_line":"devices that are otherwise equivalent from Neutron perspective, i.e. they are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"6494c8c8_274ad393","line":438,"range":{"start_line":436,"start_character":51,"end_line":438,"end_character":19},"updated":"2021-04-23 14:34:31.000000000","message":"A better wording could be: \".. of the port\u0027s ``resource_request`` fulfilled from the ``allocation`` key of ....\"","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":true,"context_lines":[{"line_number":433,"context_line":"Port binding"},{"line_number":434,"context_line":"------------"},{"line_number":435,"context_line":""},{"line_number":436,"context_line":"Today Nova sends the UUID of the resource provider the port\u0027s"},{"line_number":437,"context_line":"``resource_request`` fulfilled from in the ``allocation`` key of"},{"line_number":438,"context_line":"``binding:profile``. The port binding logic uses this information to bind the"},{"line_number":439,"context_line":"port to the same physical device or OVS bridge the port\u0027s resources are"},{"line_number":440,"context_line":"allocated from. This is necessary as it is allowed to have multiple such"},{"line_number":441,"context_line":"devices that are otherwise equivalent from Neutron perspective, i.e. they are"}],"source_content_type":"text/x-rst","patch_set":3,"id":"22b5b951_37f3ee2c","line":438,"range":{"start_line":436,"start_character":51,"end_line":438,"end_character":19},"in_reply_to":"6494c8c8_274ad393","updated":"2021-04-28 16:57:25.000000000","message":"Sorry, I cannot get why would that be better. Could you write out the whole sentence you suggest?","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":440,"context_line":"allocated from. This is necessary as it is allowed to have multiple such"},{"line_number":441,"context_line":"devices that are otherwise equivalent from Neutron perspective, i.e. they are"},{"line_number":442,"context_line":"connected to the same physnet and supporting the same ``vnic_type``. When the"},{"line_number":443,"context_line":"a port has two groups of resource requests (one for bandwidth and the other for"},{"line_number":444,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. We"},{"line_number":445,"context_line":"have two ways to handle this change:"},{"line_number":446,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e1d8a641_fde94483","line":443,"range":{"start_line":443,"start_character":0,"end_line":443,"end_character":1},"updated":"2021-04-23 14:34:31.000000000","message":"unnecessary \u0027a\u0027","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":440,"context_line":"allocated from. This is necessary as it is allowed to have multiple such"},{"line_number":441,"context_line":"devices that are otherwise equivalent from Neutron perspective, i.e. they are"},{"line_number":442,"context_line":"connected to the same physnet and supporting the same ``vnic_type``. When the"},{"line_number":443,"context_line":"a port has two groups of resource requests (one for bandwidth and the other for"},{"line_number":444,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. We"},{"line_number":445,"context_line":"have two ways to handle this change:"},{"line_number":446,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5ae48469_ed92a040","line":443,"range":{"start_line":443,"start_character":0,"end_line":443,"end_character":1},"in_reply_to":"e1d8a641_fde94483","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":444,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. We"},{"line_number":445,"context_line":"have two ways to handle this change:"},{"line_number":446,"context_line":""},{"line_number":447,"context_line":"* Change the structure of the ``allocation`` key. As every group of resources"},{"line_number":448,"context_line":"  in the ``resource_request`` now has a uniq identifier Nova can send a mapping"},{"line_number":449,"context_line":"  of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton`` key of ``binding:profile``"},{"line_number":450,"context_line":"  so that Neutron gets informed about which RP provided which group of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7723092f_89ef491b","line":447,"updated":"2021-04-23 14:34:31.000000000","message":"I vote on this version","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":444,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. We"},{"line_number":445,"context_line":"have two ways to handle this change:"},{"line_number":446,"context_line":""},{"line_number":447,"context_line":"* Change the structure of the ``allocation`` key. As every group of resources"},{"line_number":448,"context_line":"  in the ``resource_request`` now has a uniq identifier Nova can send a mapping"},{"line_number":449,"context_line":"  of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton`` key of ``binding:profile``"},{"line_number":450,"context_line":"  so that Neutron gets informed about which RP provided which group of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b2f86aeb_87b59cf8","line":447,"in_reply_to":"7723092f_89ef491b","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":448,"context_line":"  in the ``resource_request`` now has a uniq identifier Nova can send a mapping"},{"line_number":449,"context_line":"  of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton`` key of ``binding:profile``"},{"line_number":450,"context_line":"  so that Neutron gets informed about which RP provided which group of"},{"line_number":451,"context_line":"  resources. This means the following structure in the ``allocation`` key::"},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"    {"},{"line_number":454,"context_line":"        \u003cuniq id of the group requesting min_pps\u003e: \u003cOVS agent RP UUID\u003e,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a2de4c6c_1cd42580","line":451,"updated":"2021-04-26 15:05:37.000000000","message":"Feedback from the PTG: this is the preferred solution","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":448,"context_line":"  in the ``resource_request`` now has a uniq identifier Nova can send a mapping"},{"line_number":449,"context_line":"  of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton`` key of ``binding:profile``"},{"line_number":450,"context_line":"  so that Neutron gets informed about which RP provided which group of"},{"line_number":451,"context_line":"  resources. This means the following structure in the ``allocation`` key::"},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"    {"},{"line_number":454,"context_line":"        \u003cuniq id of the group requesting min_pps\u003e: \u003cOVS agent RP UUID\u003e,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a8db5796_41f51582","line":451,"in_reply_to":"a2de4c6c_1cd42580","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":451,"context_line":"  resources. This means the following structure in the ``allocation`` key::"},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"    {"},{"line_number":454,"context_line":"        \u003cuniq id of the group requesting min_pps\u003e: \u003cOVS agent RP UUID\u003e,"},{"line_number":455,"context_line":"        \u003cuniq id of the group requesting min_bw\u003e:"},{"line_number":456,"context_line":"        \u003cOVS bridge RP UUID or SRIOV PF RP UUID\u003e,"},{"line_number":457,"context_line":"    }"},{"line_number":458,"context_line":""},{"line_number":459,"context_line":"  Only those group id keys are present in this dict that are present in the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"132b765a_2549c5cd","line":456,"range":{"start_line":454,"start_character":8,"end_line":456,"end_character":49},"updated":"2021-04-23 14:34:31.000000000","message":"nit: change the indent sligthly please to make it easier to read","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":451,"context_line":"  resources. This means the following structure in the ``allocation`` key::"},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"    {"},{"line_number":454,"context_line":"        \u003cuniq id of the group requesting min_pps\u003e: \u003cOVS agent RP UUID\u003e,"},{"line_number":455,"context_line":"        \u003cuniq id of the group requesting min_bw\u003e:"},{"line_number":456,"context_line":"        \u003cOVS bridge RP UUID or SRIOV PF RP UUID\u003e,"},{"line_number":457,"context_line":"    }"},{"line_number":458,"context_line":""},{"line_number":459,"context_line":"  Only those group id keys are present in this dict that are present in the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"6641f791_5d988b86","line":456,"range":{"start_line":454,"start_character":8,"end_line":456,"end_character":49},"in_reply_to":"132b765a_2549c5cd","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"62f6da54160e6e803ca8560cefd9020e9de89368","unresolved":true,"context_lines":[{"line_number":456,"context_line":"        \u003cOVS bridge RP UUID or SRIOV PF RP UUID\u003e,"},{"line_number":457,"context_line":"    }"},{"line_number":458,"context_line":""},{"line_number":459,"context_line":"  Only those group id keys are present in this dict that are present in the"},{"line_number":460,"context_line":"  ``resource_request`` field."},{"line_number":461,"context_line":""},{"line_number":462,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"60fa7820_95d52c72","line":459,"range":{"start_line":459,"start_character":13,"end_line":459,"end_character":21},"updated":"2021-04-23 14:34:31.000000000","message":"this group id is the id from l320 for example?","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":456,"context_line":"        \u003cOVS bridge RP UUID or SRIOV PF RP UUID\u003e,"},{"line_number":457,"context_line":"    }"},{"line_number":458,"context_line":""},{"line_number":459,"context_line":"  Only those group id keys are present in this dict that are present in the"},{"line_number":460,"context_line":"  ``resource_request`` field."},{"line_number":461,"context_line":""},{"line_number":462,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"6743442e_f34dd70a","line":459,"range":{"start_line":459,"start_character":13,"end_line":459,"end_character":21},"in_reply_to":"60fa7820_95d52c72","updated":"2021-04-28 16:57:25.000000000","message":"yes. noted.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"81b2a6ef03c76f35b9667ad00609813d46cabad0","unresolved":true,"context_lines":[{"line_number":498,"context_line":""},{"line_number":499,"context_line":"The manipulation of the  new minimum_packet_rate QoS policy rule and changes in"},{"line_number":500,"context_line":"the ``resource_request`` and ``allocation`` fields of the port requires a new"},{"line_number":501,"context_line":"API extension."},{"line_number":502,"context_line":""},{"line_number":503,"context_line":"Testing"},{"line_number":504,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0780cbc1_222885e1","line":501,"updated":"2021-04-26 15:05:37.000000000","message":"feedback from PTG: We need to support deployments where the nova and the neutron controller services have different major versions. This means that both Wallaby Neutron - Xena Nova and Xena Neutron - Wallaby Nova situation needs to be handled. Therefore Xena Neutron should not automatically enable the new API extension that changes the format of the resource_request field as Wallaby Nova will not tolerate that. Therefore a new config option will be needed that disables the new API extension by default. This config option should be deprecate from the start so that we can in Y release.\n\nAlso Xena Nova should keep supporting the old resource_request format as Wallaby Neutron only sends that.","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d819338a6946db406bfa350cf6d19a2732d0d91","unresolved":false,"context_lines":[{"line_number":498,"context_line":""},{"line_number":499,"context_line":"The manipulation of the  new minimum_packet_rate QoS policy rule and changes in"},{"line_number":500,"context_line":"the ``resource_request`` and ``allocation`` fields of the port requires a new"},{"line_number":501,"context_line":"API extension."},{"line_number":502,"context_line":""},{"line_number":503,"context_line":"Testing"},{"line_number":504,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e62ede75_431f8c90","line":501,"in_reply_to":"0780cbc1_222885e1","updated":"2021-04-28 16:57:25.000000000","message":"Done","commit_id":"6eb6aab65d63aaa1280bfdab160ff7e1b691a006"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":128,"context_line":"    # defining packet processing capacity per traffic direction. The direction"},{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d75ec157_fb8b7f63","line":131,"range":{"start_line":131,"start_character":10,"end_line":131,"end_character":28},"updated":"2021-05-03 11:45:04.000000000","message":"No. It does not make sense to represent the same capacity in both ways, but an agent could very well have some directionless and \"directionfull\" resources at the same time.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8235e98affae7d66d2a25a226272f3d3af97a82e","unresolved":false,"context_lines":[{"line_number":128,"context_line":"    # defining packet processing capacity per traffic direction. The direction"},{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"52b1210e_e0a31817","line":131,"range":{"start_line":131,"start_character":10,"end_line":131,"end_character":28},"in_reply_to":"0e443974_81e01ad1","updated":"2021-05-05 09:38:31.000000000","message":"After talking to Bence it feels that the case Bence is after in this comment is when in the future more than one OVS instance will be handled by a single agent. In that case I agree that the two OVS instances can have different configurations resulting in that the agent has both direction less and direction aware pps inventories at the same time. However to support that the current config options are not good enough as they are not identifying witch OVS instance the inventory is related to. So we agreed to keep these mutually exclusive.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"b02ecba48d52defdbf6fb2d00a496ab63027e9fb","unresolved":false,"context_lines":[{"line_number":128,"context_line":"    # defining packet processing capacity per traffic direction. The direction"},{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6ecbdb75_61dfd122","line":131,"range":{"start_line":131,"start_character":10,"end_line":131,"end_character":28},"in_reply_to":"52b1210e_e0a31817","updated":"2021-05-05 12:04:18.000000000","message":"Thanks, I had the wrong assumption here.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":128,"context_line":"    # defining packet processing capacity per traffic direction. The direction"},{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"0e443974_81e01ad1","line":131,"range":{"start_line":131,"start_character":10,"end_line":131,"end_character":28},"in_reply_to":"d75ec157_fb8b7f63","updated":"2021-05-04 14:02:54.000000000","message":"I don\u0027t think it is valid to have both \npacket_processing_capacity and packet_processing_capacity_offloaded configured for the same agent. That would mean that this agent handles both an offloaded OVS and normal OVS at the same time. But one agent only handles one OVS instance and an OVS either has offload configured xor not.\n\nDo you mean that we should not enforce the above restriction by code and let the admin freely create logically invalid inventory config? I agree that we cannot prevent every invalid configuration i.e. we cannot check if the pps capacity is valid. But we at least know that the current agent cannot have both direction aware and direction less pps inventory at the same time. So we could reject that.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":135,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ea1fff93_214ef661","line":132,"range":{"start_line":132,"start_character":6,"end_line":132,"end_character":42},"updated":"2021-05-03 11:45:04.000000000","message":"I would suggest not equating offloaded with having a direction. Today this may be the case, but we don\u0027t know if there will be an offload mechanism that\u0027s directionless. packet_processing_capacity_with_direction and packet_processing_capacity_without_direction would work even then.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":129,"context_line":"    # is meant from the VM perspective. Note that the"},{"line_number":130,"context_line":"    # packet_processing_capacity and the packet_processing_capacity_offloaded"},{"line_number":131,"context_line":"    # are mutually exclusive options."},{"line_number":132,"context_line":"    # packet_processing_capacity_offloaded \u003d :0:0"},{"line_number":133,"context_line":"    #"},{"line_number":134,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":135,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e70e44d6_411dbd79","line":132,"range":{"start_line":132,"start_character":6,"end_line":132,"end_character":42},"in_reply_to":"ea1fff93_214ef661","updated":"2021-05-04 14:02:54.000000000","message":"Good point. I renamed the config options.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":159,"context_line":"inventory on the OVS agent resource provider (RP) to Placement in a similarly"},{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"68843bdf_62524945","line":162,"range":{"start_line":162,"start_character":36,"end_line":162,"end_character":78},"updated":"2021-05-03 11:45:04.000000000","message":"We report those VNIC_TYPEs because those are the types the agent can handle. That would be probably clearer to say here too.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":159,"context_line":"inventory on the OVS agent resource provider (RP) to Placement in a similarly"},{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"6acf453d_56c1a8b8","line":162,"range":{"start_line":162,"start_character":36,"end_line":162,"end_character":78},"in_reply_to":"68843bdf_62524945","updated":"2021-05-04 14:02:54.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2d71f3c0_5621a5b4","line":163,"range":{"start_line":163,"start_character":59,"end_line":163,"end_character":74},"updated":"2021-05-03 11:45:04.000000000","message":"I know we talked about this before, but the more I think about this the less sure I am that we need the physnets here. The presence of the physnet traits is not a direct problem but it may be unnecessary. Why would we ever want to request min kpps with a physnet trait, when we know that multiple bridges will be involved in packet processing?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8235e98affae7d66d2a25a226272f3d3af97a82e","unresolved":true,"context_lines":[{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"aeebcb44_31d42ecd","line":163,"range":{"start_line":163,"start_character":59,"end_line":163,"end_character":74},"in_reply_to":"18454cc7_0e6e1ce6","updated":"2021-05-05 09:38:31.000000000","message":"After talking with Bence I understand his comment better now. In the error case I described in my previous comment describe a separate feature where the deployment has different physnet configured to OVS on different computes. There are two cases:\n1) a single neutron network has two physnet segment. In this case the routed net feature already needs to make sure that the proper compute is selected. \n2) two neutron network has different physnets configured and two computes has different OVS configuration so that one compute has access to one of the physnet while the other compute has access to the other physnet. Today nova scheduling does not consider physnet availability in this case. Nova can select the wrong compute and the the port binding will fail. \n\nWhile the above proposed logic along with adding the physnet trait to the requested_resources would solve both situation it is outside of the scope of this feature to solve these cases. So I will remove this logic from the spec.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32b85bca4121b04ef1971dfb5d8d8d2810f3f32e","unresolved":false,"context_lines":[{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a8cecc30_88a66fa8","line":163,"range":{"start_line":163,"start_character":59,"end_line":163,"end_character":74},"in_reply_to":"1ea1cb2f_e4832e31","updated":"2021-05-06 15:47:05.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"18454cc7_0e6e1ce6","line":163,"range":{"start_line":163,"start_character":59,"end_line":163,"end_character":74},"in_reply_to":"2d71f3c0_5621a5b4","updated":"2021-05-04 14:02:54.000000000","message":"I think the physnet trait originally came into the picture to handle the following situation. We have 2 device connected to two different physnets handled by the same agent. Both device providing bandwidth inventory. Then a VM boot with a port with bandwidth request would mean nova + placement decides which device is selected for the port. If this decision does not consider the physnet then if the port\u0027s network connected to a different physnet that the device the bandwidth is allocated from then the port bindig would fail. To avoid such failure we introduced the physnet trait so that the scheduling selects the proper device.\n\nSo in case of pps there is a bit different scenario as we have only one OVS agent per host so we have a less ambiguous situation. But simply selecting the OVS on a compute host based on the vnic type and the available bandwidth or pps inventory does not mean that this OVS has connectivity towards the physnet the port\u0027s network represents. I think this could result in the same binding failure as above if some of the computes has access to one physnet while the other computes has access only to a different physnet.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"b02ecba48d52defdbf6fb2d00a496ab63027e9fb","unresolved":true,"context_lines":[{"line_number":160,"context_line":"way how the bandwidth resource is reported today. Now that the OVS agent RP has"},{"line_number":161,"context_line":"resource inventory the Neutron server also needs to report the same"},{"line_number":162,"context_line":"``CUSTOM_VNIC_TYPE_`` traits on the OVS agent RP as reported on the bridge RPs."},{"line_number":163,"context_line":"Also the Neutron server needs to report the union of the ``CUSTOM_PHYSNET_``"},{"line_number":164,"context_line":"traits from every children bridge RP to the agent RP."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ea1cb2f_e4832e31","line":163,"range":{"start_line":163,"start_character":59,"end_line":163,"end_character":74},"in_reply_to":"aeebcb44_31d42ecd","updated":"2021-05-05 12:04:18.000000000","message":"Yep, my main point wanted to be that scheduling based on the availability of physnet(s) is a valid use case. But - in contrast to the minimum bw support, where the physical bw resource (ie. the NIC enslaved to a physical bridge) is naturally part of a physnet - the min pps has no (one-to-one) logical connection to a physnet. So if we want to support the physnet based scheduling it may be better to do that purposefully in its own spec instead of doing it as a limited side effect of the min pps feature.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":180,"context_line":"            \u0027parameters\u0027: {"},{"line_number":181,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":182,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":183,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: True,"},{"line_number":184,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":185,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":186,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dca16e9d_9fb723f6","line":183,"range":{"start_line":183,"start_character":53,"end_line":183,"end_character":57},"updated":"2021-05-03 11:45:04.000000000","message":"Do you want to go directly for updatable rules?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":false,"context_lines":[{"line_number":180,"context_line":"            \u0027parameters\u0027: {"},{"line_number":181,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":182,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":183,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: True,"},{"line_number":184,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":185,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":186,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3348c100_d49be511","line":183,"range":{"start_line":183,"start_character":53,"end_line":183,"end_character":57},"in_reply_to":"310a417b_9af6dd5f","updated":"2021-05-27 12:52:29.000000000","message":"Good point. min_bw rule updated today result in http 501 if the rule is used in a policy that is used in a bound port. While if the port is not bound it is allowed to change.\n\nI changed this back to PUTable and added a note about the HTTP 501 behavior","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"54387d68c83964c8006fa335b0add5bffc9bce48","unresolved":false,"context_lines":[{"line_number":180,"context_line":"            \u0027parameters\u0027: {"},{"line_number":181,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":182,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":183,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: True,"},{"line_number":184,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":185,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":186,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"40668eb4_2ceae075","line":183,"range":{"start_line":183,"start_character":53,"end_line":183,"end_character":57},"in_reply_to":"3348c100_d49be511","updated":"2021-05-27 13:36:34.000000000","message":"501 are server side errors. i dont think this is the correct code to be passing in this case.\nit should be a 400 or 409.\n\nthis si imporant form a billing point of view as many public cloud custoemr consider 500 error to be cloud outages or sla breakes so  we shoudl not return a 501 here.\n\nthe other reason we shoudl not use a 501 is this is an incorreect usage of that errorcode\n\nhttps://datatracker.ietf.org/doc/html/rfc7231.html#section-6.6.2\na 501 is a statemnt about the webserver not the endpoint or the aplciation.\n\nthe api sig has a secontion covering this\nhttps://specs.openstack.org/openstack/api-sig/guidelines/http/response-codes.html#use-of-501-not-implemented\n\neven if we dont accpet a PUT for this endpoing we shoudl  not use 501 as that means the webserver does support put on any api call.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":false,"context_lines":[{"line_number":180,"context_line":"            \u0027parameters\u0027: {"},{"line_number":181,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":182,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":183,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: True,"},{"line_number":184,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":185,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":186,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"310a417b_9af6dd5f","line":183,"range":{"start_line":183,"start_character":53,"end_line":183,"end_character":57},"in_reply_to":"886ccb10_07605b01","updated":"2021-05-26 14:39:26.000000000","message":"You can update the value. The server will check if the QoS policy is assigned (as with min BW rules). In that case, the command is blocked.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":180,"context_line":"            \u0027parameters\u0027: {"},{"line_number":181,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":182,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":183,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: True,"},{"line_number":184,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":185,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":186,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"886ccb10_07605b01","line":183,"range":{"start_line":183,"start_character":53,"end_line":183,"end_character":57},"in_reply_to":"dca16e9d_9fb723f6","updated":"2021-05-04 14:02:54.000000000","message":"Good point. I doesn\u0027t.\n\nNote this is different from the operation that changes the qos policy id on a bound port. As far as I know we only support that for bandwidth too.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":190,"context_line":"                },"},{"line_number":191,"context_line":"                \u0027direction\u0027: {"},{"line_number":192,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":193,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":194,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":195,"context_line":"                    \u0027default\u0027: None,"},{"line_number":196,"context_line":"                    \u0027validate\u0027: {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dd499df4_7e0a2591","line":193,"range":{"start_line":193,"start_character":33,"end_line":193,"end_character":37},"updated":"2021-05-03 11:45:04.000000000","message":"Do we really want to handle the complexity of these updates? What does the user gain by this (compared to deleting and creating a new rule)?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":190,"context_line":"                },"},{"line_number":191,"context_line":"                \u0027direction\u0027: {"},{"line_number":192,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":193,"context_line":"                    \u0027allow_put\u0027: True,"},{"line_number":194,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":195,"context_line":"                    \u0027default\u0027: None,"},{"line_number":196,"context_line":"                    \u0027validate\u0027: {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"74cbfca2_954d3be7","line":193,"range":{"start_line":193,"start_character":33,"end_line":193,"end_character":37},"in_reply_to":"dd499df4_7e0a2591","updated":"2021-05-04 14:02:54.000000000","message":"Good point. I don\u0027t","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"d4384a9504ad323d04f556688b332169160c9161","unresolved":true,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"53142436_b2ba3b15","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"updated":"2021-05-03 09:42:24.000000000","message":"I suppose for this we need an extra validation to forbid the case where direction\u003dNone and direction\u003dEGRESS/INGRESS is mixed for 1 QoS policy.\nAllowed:\n\n* qos_1, minimum_packet_rate_rule_1_1, direction\u003dNone,\n\n* qos_2, minimum_packet_rate_rule_2_1, direction\u003dIngres\n         minimum_packet_rate_rule_2_2, direction\u003dEgress\n\n* qos_3, minimum_packet_rate_rule_3_1, direction\u003d(Ingress or Egress)\n\n\nNot allowed:\n\nqos_4, minimum_packet_rate_rule_4_1, direction\u003dNone\n       minimum_packet_rate_rule_4_2, direction\u003dIngress","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":false,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d6024c51_bd912942","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"246ed8e0_b780df94","updated":"2021-05-27 12:52:29.000000000","message":"lets continue the discussion of this in the last PS.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8235e98affae7d66d2a25a226272f3d3af97a82e","unresolved":true,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a112efa4_9d9c2417","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"4316908c_a913800d","updated":"2021-05-05 09:38:31.000000000","message":"After talking to Lajos and Bence I think I misunderstood the original comment. We agreed that we should reject a QoS minimum packet rate rule creation if it would result in a policy where direction aware and directionless pps rules are mixed. The comment was about where to do this check in the API layer or deeper.\n\nI will add details about it to the spec","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e684623e_d8e52a65","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"53142436_b2ba3b15","updated":"2021-05-03 11:45:04.000000000","message":"Yes, however I believe this will be a constraint of the implementation, not of the API. Theoretically an agent could handle direction-aware and directionless resources at the same time.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32b85bca4121b04ef1971dfb5d8d8d2810f3f32e","unresolved":false,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"deebfaef_e9b37c8e","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"a112efa4_9d9c2417","updated":"2021-05-06 15:47:05.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":false,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"246ed8e0_b780df94","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"deebfaef_e9b37c8e","updated":"2021-05-26 14:39:26.000000000","message":"I strongly disagree with the idea of having QoS rules with direction \u003d \"both\", as commented in last PS.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":208,"context_line":"The direction, ingress or egress of the rule is considered from the Nova"},{"line_number":209,"context_line":"server\u0027s perspective. So an 1 kpps ingress guarantee means the system ensures"},{"line_number":210,"context_line":"that at least 1000 packet can enter the VM via the given port per second."},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":213,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":214,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":215,"context_line":"accounting is directionless."},{"line_number":216,"context_line":""},{"line_number":217,"context_line":".. note::"},{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4316908c_a913800d","line":215,"range":{"start_line":211,"start_character":0,"end_line":215,"end_character":28},"in_reply_to":"e684623e_d8e52a65","updated":"2021-05-04 14:02:54.000000000","message":"It is the same trade off as the decision that we don\u0027t want to automatically sum the two directions when the vnic_type\u003dnormal. The admin needs to know how to create a qos policy that is meaningful in the deployment. E.g. in a deployment with only normal OVS any min pps policy with direction will result is NoValidHost as only directionless resource inventory will be available.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"},{"line_number":219,"context_line":"    the `Nova specification`_"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Neutron provides the necessary information to any client via"},{"line_number":222,"context_line":"the ``resource_request`` of the port to allow the client to keep the placement"},{"line_number":223,"context_line":"resource allocation consistent and therefore implement the schedule time"},{"line_number":224,"context_line":"guarantee. Nova will use this information to do so. However neither Neutron nor"},{"line_number":225,"context_line":"Nova can enforce that another client, which can bound ports also properly"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a9ec20a9_273ef6ea","line":222,"range":{"start_line":221,"start_character":43,"end_line":222,"end_character":36},"updated":"2021-05-03 11:45:04.000000000","message":"This policy is admin only / system reader. We should keep it that way.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":218,"context_line":"    For the alternative about having only direction aware QoS rule types see"},{"line_number":219,"context_line":"    the `Nova specification`_"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Neutron provides the necessary information to any client via"},{"line_number":222,"context_line":"the ``resource_request`` of the port to allow the client to keep the placement"},{"line_number":223,"context_line":"resource allocation consistent and therefore implement the schedule time"},{"line_number":224,"context_line":"guarantee. Nova will use this information to do so. However neither Neutron nor"},{"line_number":225,"context_line":"Nova can enforce that another client, which can bound ports also properly"}],"source_content_type":"text/x-rst","patch_set":4,"id":"31c684ef_82c4fdd8","line":222,"range":{"start_line":221,"start_character":43,"end_line":222,"end_character":36},"in_reply_to":"a9ec20a9_273ef6ea","updated":"2021-05-04 14:02:54.000000000","message":"We will. I\u0027ve changed the \"any client\" part.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"73941e0f9e87e83a4dfb91366232a4c11b21d7ba","unresolved":true,"context_lines":[{"line_number":227,"context_line":""},{"line_number":228,"context_line":"This results in the following new API resources and operations:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* ``GET /v2.0/qos/policies/{policy_id}/minimum_packet_rate_rules``"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"  List minimum packet rate rules for QoS policy"},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"78f54032_1010166b","line":230,"range":{"start_line":230,"start_character":28,"end_line":230,"end_character":37},"updated":"2021-04-29 07:40:25.000000000","message":"nit: some time ago we realized that requiring policy_id in such API call isn\u0027t really needed. So, to have backward compatibility and to improve our API we proposed API aliases for existing rules, see https://docs.openstack.org/api-ref/network/v2/#quality-of-service-rules-alias-api\nBut now my question is: should we continue to propose \"old way\" API for new rules and add aliases also? Or maybe go only with \"new way\" APIs for new rules?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":227,"context_line":""},{"line_number":228,"context_line":"This results in the following new API resources and operations:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* ``GET /v2.0/qos/policies/{policy_id}/minimum_packet_rate_rules``"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"  List minimum packet rate rules for QoS policy"},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"de69a7e8_89fa2d3c","line":230,"range":{"start_line":230,"start_character":28,"end_line":230,"end_character":37},"in_reply_to":"6bd5f912_1e4f6ff4","updated":"2021-05-04 14:02:54.000000000","message":"I\u0027m OK not to propose the old style APIs. I\u0027ve changed the spec accordingly. However it seems a bit strange to have alias_bandwidth_limit_rules as a name when there is nothing this API aliases. So I proposed to have the naming like: /v2.0/qos/minimum_packet_rate_rules/{rule_id} without the alias prefix. Let me know how do you feel about it.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":227,"context_line":""},{"line_number":228,"context_line":"This results in the following new API resources and operations:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* ``GET /v2.0/qos/policies/{policy_id}/minimum_packet_rate_rules``"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"  List minimum packet rate rules for QoS policy"},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"6bd5f912_1e4f6ff4","line":230,"range":{"start_line":230,"start_character":28,"end_line":230,"end_character":37},"in_reply_to":"78f54032_1010166b","updated":"2021-05-03 11:45:04.000000000","message":"+1 for the new way only, since all client code for this will be written in the future. But of course this only applies to the requests with a rule_id.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":317,"context_line":"            sa.Column(\u0027direction\u0027, sa.Enum(constants.EGRESS_DIRECTION,"},{"line_number":318,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":319,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":320,"context_line":"                      nullable\u003dFalse,"},{"line_number":321,"context_line":"                      server_default\u003dconstants.EGRESS_DIRECTION),"},{"line_number":322,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":323,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":4,"id":"f5aeb993_33f75702","line":320,"range":{"start_line":320,"start_character":31,"end_line":320,"end_character":36},"updated":"2021-05-03 11:45:04.000000000","message":"True","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":317,"context_line":"            sa.Column(\u0027direction\u0027, sa.Enum(constants.EGRESS_DIRECTION,"},{"line_number":318,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":319,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":320,"context_line":"                      nullable\u003dFalse,"},{"line_number":321,"context_line":"                      server_default\u003dconstants.EGRESS_DIRECTION),"},{"line_number":322,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":323,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":4,"id":"44ca6a29_83370359","line":320,"range":{"start_line":320,"start_character":31,"end_line":320,"end_character":36},"in_reply_to":"f5aeb993_33f75702","updated":"2021-05-04 14:02:54.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":318,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":319,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":320,"context_line":"                      nullable\u003dFalse,"},{"line_number":321,"context_line":"                      server_default\u003dconstants.EGRESS_DIRECTION),"},{"line_number":322,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":323,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"},{"line_number":324,"context_line":"                                    ondelete\u003d\u0027CASCADE\u0027)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"c11710f8_c4adcc38","line":321,"range":{"start_line":321,"start_character":37,"end_line":321,"end_character":63},"updated":"2021-05-03 11:45:04.000000000","message":"I\u0027m not sure, but maybe the directionless would be a slightly better default.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":318,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":319,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":320,"context_line":"                      nullable\u003dFalse,"},{"line_number":321,"context_line":"                      server_default\u003dconstants.EGRESS_DIRECTION),"},{"line_number":322,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":323,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"},{"line_number":324,"context_line":"                                    ondelete\u003d\u0027CASCADE\u0027)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ac6b2f31_d448fbe0","line":321,"range":{"start_line":321,"start_character":37,"end_line":321,"end_character":63},"in_reply_to":"c11710f8_c4adcc38","updated":"2021-05-04 14:02:54.000000000","message":"Good point. Done.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":363,"context_line":"        ["},{"line_number":364,"context_line":"            {"},{"line_number":365,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":366,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":367,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":368,"context_line":"                \"resources\":"},{"line_number":369,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7d0463d4_ca2902d3","line":366,"range":{"start_line":366,"start_character":30,"end_line":366,"end_character":45},"updated":"2021-05-03 11:45:04.000000000","message":"As mentioned above I\u0027m not sure if requesting the physnet makes much sense.\n\nThe vnic_type still does make sense to me, because we can choose between differently configured/backed agents early in Placement.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32b85bca4121b04ef1971dfb5d8d8d2810f3f32e","unresolved":false,"context_lines":[{"line_number":363,"context_line":"        ["},{"line_number":364,"context_line":"            {"},{"line_number":365,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":366,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":367,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":368,"context_line":"                \"resources\":"},{"line_number":369,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"48ef50bc_75f15adc","line":366,"range":{"start_line":366,"start_character":30,"end_line":366,"end_character":45},"in_reply_to":"614a2d32_97e3322d","updated":"2021-05-06 15:47:05.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":363,"context_line":"        ["},{"line_number":364,"context_line":"            {"},{"line_number":365,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":366,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":367,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":368,"context_line":"                \"resources\":"},{"line_number":369,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"614a2d32_97e3322d","line":366,"range":{"start_line":366,"start_character":30,"end_line":366,"end_character":45},"in_reply_to":"7d0463d4_ca2902d3","updated":"2021-05-04 14:02:54.000000000","message":"See my response above.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":409,"context_line":"        \"request_groups\":"},{"line_number":410,"context_line":"        ["},{"line_number":411,"context_line":"            {"},{"line_number":412,"context_line":"                \"id\": \"port-request-group-due-to-min-pps\","},{"line_number":413,"context_line":"                # ..."},{"line_number":414,"context_line":"            },"},{"line_number":415,"context_line":"            {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"115624f7_32fab3ec","line":412,"range":{"start_line":412,"start_character":17,"end_line":412,"end_character":19},"updated":"2021-05-03 11:45:04.000000000","message":"What format will be accepted by nova? Nova and Placement does not interpret this in any way, right? In what scope does this have to be unique?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":409,"context_line":"        \"request_groups\":"},{"line_number":410,"context_line":"        ["},{"line_number":411,"context_line":"            {"},{"line_number":412,"context_line":"                \"id\": \"port-request-group-due-to-min-pps\","},{"line_number":413,"context_line":"                # ..."},{"line_number":414,"context_line":"            },"},{"line_number":415,"context_line":"            {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"700b9c5a_4e4e5ade","line":412,"range":{"start_line":412,"start_character":17,"end_line":412,"end_character":19},"in_reply_to":"115624f7_32fab3ec","updated":"2021-05-04 14:02:54.000000000","message":"Good question.\n\nNova might need to correlate this in case of a direct port, where the nova PCI claim needs to be driven by the placement decision. I.e. a  direct port requested bandwidth, so nova allocated bandwidth in placement from a PF. Then nova has to make sure that PCI claim process selects VF from the same PF. Today it is done by iterating the PCI requests of the instance and checking if there is a corresponding request group in the placement allocation. This only works today as the request group requester_id is the port_id and also the requester_id of the PCI request is the port_id. This needs to be changed in nova. Probably we still need to store the port_id as the requester_id and also store the group_id in the RequestGroup in a new field. \n\nAnyhow from nova perspective the group id in the resource_request needs to be a string. Nova does not store it in the db. The placement API has a length limit of 64 for the group id. I.e.: r\u0027[a-zA-Z0-9_-]{1,64}\u0027\n\nPlacement requires that the group id is unique in a given allocation_candidate request. This means that each VM lifecycle operation (that results in scheduling) needs to have unique group ids. E.g. if there are multiple ports in a VM boot request then each group in each port needs to have a unique id. Also because ports can be added to a running VM then later a VM can be moved, the newly added port needs to have unique group ids in the scope of each port of the VM. So the best would be if Neutron could generate a uuid for each group. However if this is not feasible then a unique group id per port is the strict minimum we need. Then nova needs to combine the port_id and the group id to get a fully unique id for the lifecycle operation.\n\nBottom line, I propose to have a unique id (UUID) per deployment.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32b85bca4121b04ef1971dfb5d8d8d2810f3f32e","unresolved":false,"context_lines":[{"line_number":409,"context_line":"        \"request_groups\":"},{"line_number":410,"context_line":"        ["},{"line_number":411,"context_line":"            {"},{"line_number":412,"context_line":"                \"id\": \"port-request-group-due-to-min-pps\","},{"line_number":413,"context_line":"                # ..."},{"line_number":414,"context_line":"            },"},{"line_number":415,"context_line":"            {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"46c04382_1afc2bdb","line":412,"range":{"start_line":412,"start_character":17,"end_line":412,"end_character":19},"in_reply_to":"3ad76c0e_6927dafe","updated":"2021-05-06 15:47:05.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8235e98affae7d66d2a25a226272f3d3af97a82e","unresolved":true,"context_lines":[{"line_number":409,"context_line":"        \"request_groups\":"},{"line_number":410,"context_line":"        ["},{"line_number":411,"context_line":"            {"},{"line_number":412,"context_line":"                \"id\": \"port-request-group-due-to-min-pps\","},{"line_number":413,"context_line":"                # ..."},{"line_number":414,"context_line":"            },"},{"line_number":415,"context_line":"            {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3ad76c0e_6927dafe","line":412,"range":{"start_line":412,"start_character":17,"end_line":412,"end_character":19},"in_reply_to":"700b9c5a_4e4e5ade","updated":"2021-05-05 09:38:31.000000000","message":"After talking with Bence we figured that the best thing to do is to deterministically generate a new unique UUID from the combination of the existing UUIDs (port_id, and the ids of the rules in the QoS policy). For the generation we can use UUID5 that generates a deterministic UUID from multiple inputs.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"73941e0f9e87e83a4dfb91366232a4c11b21d7ba","unresolved":true,"context_lines":[{"line_number":472,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"The API extension is the selected alternative as that feels like the standard"},{"line_number":475,"context_line":"way in Neutron to signal API change."},{"line_number":476,"context_line":""},{"line_number":477,"context_line":"Port binding"},{"line_number":478,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6757c73f_77bff348","line":475,"updated":"2021-04-29 07:40:25.000000000","message":"+1 for that","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":472,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"The API extension is the selected alternative as that feels like the standard"},{"line_number":475,"context_line":"way in Neutron to signal API change."},{"line_number":476,"context_line":""},{"line_number":477,"context_line":"Port binding"},{"line_number":478,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"0710b374_4f8d75b5","line":475,"in_reply_to":"6757c73f_77bff348","updated":"2021-05-04 14:02:54.000000000","message":"Ack","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"d4384a9504ad323d04f556688b332169160c9161","unresolved":true,"context_lines":[{"line_number":488,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. To"},{"line_number":489,"context_line":"support that we need to change the structure of the ``allocation`` key. As"},{"line_number":490,"context_line":"every group of resources in the ``resource_request`` now has a uniq identifier"},{"line_number":491,"context_line":"Nova can send a mapping of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton``"},{"line_number":492,"context_line":"key of ``binding:profile`` so that Neutron gets informed about which RP"},{"line_number":493,"context_line":"provided which group of resources. This means the following structure in the"},{"line_number":494,"context_line":"``allocation`` key::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"29115f76_fd31e221","line":491,"range":{"start_line":491,"start_character":27,"end_line":491,"end_character":37},"updated":"2021-05-03 09:42:24.000000000","message":"currently the resource_request is a \"counted\" field in the port dict, so nothing is stored in db, to have that available during binding time the resource_request must be stored in db, am I wrong?","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":488,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. To"},{"line_number":489,"context_line":"support that we need to change the structure of the ``allocation`` key. As"},{"line_number":490,"context_line":"every group of resources in the ``resource_request`` now has a uniq identifier"},{"line_number":491,"context_line":"Nova can send a mapping of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton``"},{"line_number":492,"context_line":"key of ``binding:profile`` so that Neutron gets informed about which RP"},{"line_number":493,"context_line":"provided which group of resources. This means the following structure in the"},{"line_number":494,"context_line":"``allocation`` key::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4367335f_750c2c52","line":491,"range":{"start_line":491,"start_character":27,"end_line":491,"end_character":37},"in_reply_to":"29115f76_fd31e221","updated":"2021-05-03 11:45:04.000000000","message":"Or produce the group.ids deterministically.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":true,"context_lines":[{"line_number":488,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. To"},{"line_number":489,"context_line":"support that we need to change the structure of the ``allocation`` key. As"},{"line_number":490,"context_line":"every group of resources in the ``resource_request`` now has a uniq identifier"},{"line_number":491,"context_line":"Nova can send a mapping of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton``"},{"line_number":492,"context_line":"key of ``binding:profile`` so that Neutron gets informed about which RP"},{"line_number":493,"context_line":"provided which group of resources. This means the following structure in the"},{"line_number":494,"context_line":"``allocation`` key::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"64f9fef5_e5ac2430","line":491,"range":{"start_line":491,"start_character":27,"end_line":491,"end_character":37},"in_reply_to":"4367335f_750c2c52","updated":"2021-05-04 14:02:54.000000000","message":"Good point. I\u0027m open to either persist a new UUID4 for each group or find a deterministic unique id. \n\nRegarding the second option. We have the port_id that is unique in the scope of the deployment, and we have the QoS rule_id that is unique at least within a given QoS policy (I assume that a give policy cannot have two rules with the same rule_id). As the port has a single QoS policy therefore the QoS rule_id also unique within the scope of a port. So one way to deterministically generate a new unique id is to use the existing UUIDs and combine them. The 64 length limit does not allow a textual combination of the port_id and the QoS rule_id. Also we can have more than one rule_id per group as different traffic directions need different rules. So we might need to combine more than two UUIDs. I\u0027m wondering if using binary XOR on UUIDs are good enough to generate a combined but unique UUID.\n\nLet me know what you think.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"8235e98affae7d66d2a25a226272f3d3af97a82e","unresolved":true,"context_lines":[{"line_number":488,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. To"},{"line_number":489,"context_line":"support that we need to change the structure of the ``allocation`` key. As"},{"line_number":490,"context_line":"every group of resources in the ``resource_request`` now has a uniq identifier"},{"line_number":491,"context_line":"Nova can send a mapping of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton``"},{"line_number":492,"context_line":"key of ``binding:profile`` so that Neutron gets informed about which RP"},{"line_number":493,"context_line":"provided which group of resources. This means the following structure in the"},{"line_number":494,"context_line":"``allocation`` key::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"efcf5234_3cd92732","line":491,"range":{"start_line":491,"start_character":27,"end_line":491,"end_character":37},"in_reply_to":"64f9fef5_e5ac2430","updated":"2021-05-05 09:38:31.000000000","message":"use UUID5 to generate a new deterministic but unique UUID from the unique inputs: port_id, and the id of the QoS rules for the QoS policy attached to the port.","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32b85bca4121b04ef1971dfb5d8d8d2810f3f32e","unresolved":false,"context_lines":[{"line_number":488,"context_line":"packet rate) the resource allocation is fulfilled from more than one RPs. To"},{"line_number":489,"context_line":"support that we need to change the structure of the ``allocation`` key. As"},{"line_number":490,"context_line":"every group of resources in the ``resource_request`` now has a uniq identifier"},{"line_number":491,"context_line":"Nova can send a mapping of \u003cgroup.id\u003e: \u003cRP.uuid\u003e back in the ``allocaton``"},{"line_number":492,"context_line":"key of ``binding:profile`` so that Neutron gets informed about which RP"},{"line_number":493,"context_line":"provided which group of resources. This means the following structure in the"},{"line_number":494,"context_line":"``allocation`` key::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"678a3915_d3b39da9","line":491,"range":{"start_line":491,"start_character":27,"end_line":491,"end_character":37},"in_reply_to":"efcf5234_3cd92732","updated":"2021-05-06 15:47:05.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":529,"context_line":""},{"line_number":530,"context_line":"The changes in the Neutron server - OVS agent communication means that during"},{"line_number":531,"context_line":"rolling upgrade upgraded OVS agents might send the new"},{"line_number":532,"context_line":"``packet_processing_capacity`` key in the hearth beat while old agents will not"},{"line_number":533,"context_line":"send it. So Neutron server needs to consider this new key as optional."},{"line_number":534,"context_line":""},{"line_number":535,"context_line":"The manipulation of the  new minimum_packet_rate QoS policy rule and changes in"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d6b6bdaf_ed055bcd","line":532,"range":{"start_line":532,"start_character":42,"end_line":532,"end_character":53},"updated":"2021-05-03 11:45:04.000000000","message":"nit: heartbeat","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":529,"context_line":""},{"line_number":530,"context_line":"The changes in the Neutron server - OVS agent communication means that during"},{"line_number":531,"context_line":"rolling upgrade upgraded OVS agents might send the new"},{"line_number":532,"context_line":"``packet_processing_capacity`` key in the hearth beat while old agents will not"},{"line_number":533,"context_line":"send it. So Neutron server needs to consider this new key as optional."},{"line_number":534,"context_line":""},{"line_number":535,"context_line":"The manipulation of the  new minimum_packet_rate QoS policy rule and changes in"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b4c0ec89_5c8c7ca0","line":532,"range":{"start_line":532,"start_character":42,"end_line":532,"end_character":53},"in_reply_to":"d6b6bdaf_ed055bcd","updated":"2021-05-04 14:02:54.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"e45cd9b38cddbd4d4dcb89c42b9285bcf9c1c09d","unresolved":true,"context_lines":[{"line_number":538,"context_line":"already upgraded to Xena but Nova still on Wallaby version. As the old Nova"},{"line_number":539,"context_line":"cannot support the new ``resource_request`` format, Neutron needs to make this"},{"line_number":540,"context_line":"new API extension optional with a new configuration option in the neutron"},{"line_number":541,"context_line":"server configuration. This configuration should be deprecated from"},{"line_number":542,"context_line":"automatically and it can be removed during the Y release."},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"Testing"},{"line_number":545,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"0fbdf9f7_8306cde5","line":542,"range":{"start_line":541,"start_character":62,"end_line":542,"end_character":13},"updated":"2021-05-03 11:45:04.000000000","message":"already at introduction","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"92d2600bf3d6ff5d250227a825f8564705e4be99","unresolved":false,"context_lines":[{"line_number":538,"context_line":"already upgraded to Xena but Nova still on Wallaby version. As the old Nova"},{"line_number":539,"context_line":"cannot support the new ``resource_request`` format, Neutron needs to make this"},{"line_number":540,"context_line":"new API extension optional with a new configuration option in the neutron"},{"line_number":541,"context_line":"server configuration. This configuration should be deprecated from"},{"line_number":542,"context_line":"automatically and it can be removed during the Y release."},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"Testing"},{"line_number":545,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e8405c42_83cf9a0f","line":542,"range":{"start_line":541,"start_character":62,"end_line":542,"end_character":13},"in_reply_to":"0fbdf9f7_8306cde5","updated":"2021-05-04 14:02:54.000000000","message":"Done","commit_id":"c776d6b38693f45005b3bfcf873b2b1c44c6bf80"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"ec29c2ab4ada6052b95784020998b8ca7f1032ce","unresolved":true,"context_lines":[{"line_number":34,"context_line":"the placement of new workload."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"This spec focuses on managing the packet processing capacity of the soft switch"},{"line_number":37,"context_line":"(like OVS) running on or next to the hypervisor hosting the VM."},{"line_number":38,"context_line":"Managing packet processing capacity in other parts of the networking backend"},{"line_number":39,"context_line":"(like in Top-Of-Rack switches) are out of scope."},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"84d1c4b2_98d860b2","line":37,"updated":"2021-05-10 12:15:31.000000000","message":"can we please clarify what we mean by \u0027next to hypervisor\u0027 here?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":false,"context_lines":[{"line_number":34,"context_line":"the placement of new workload."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"This spec focuses on managing the packet processing capacity of the soft switch"},{"line_number":37,"context_line":"(like OVS) running on or next to the hypervisor hosting the VM."},{"line_number":38,"context_line":"Managing packet processing capacity in other parts of the networking backend"},{"line_number":39,"context_line":"(like in Top-Of-Rack switches) are out of scope."},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"911421f2_b408c4c2","line":37,"in_reply_to":"4422722d_2314df45","updated":"2021-05-21 14:41:20.000000000","message":"Done","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":34,"context_line":"the placement of new workload."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"This spec focuses on managing the packet processing capacity of the soft switch"},{"line_number":37,"context_line":"(like OVS) running on or next to the hypervisor hosting the VM."},{"line_number":38,"context_line":"Managing packet processing capacity in other parts of the networking backend"},{"line_number":39,"context_line":"(like in Top-Of-Rack switches) are out of scope."},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"4422722d_2314df45","line":37,"in_reply_to":"84d1c4b2_98d860b2","updated":"2021-05-10 14:45:11.000000000","message":"I will remove the \"next to\" I think it running on the hypervisor host is better. The only purpose was to differentiate from any packet processing happening elsewhere in the networks. See the next sentence clarify that.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"ec29c2ab4ada6052b95784020998b8ca7f1032ce","unresolved":true,"context_lines":[{"line_number":91,"context_line":"1) The packet processing functionality is implemented on the compute host CPUs"},{"line_number":92,"context_line":"   and therefore packets processed from both ingress and egress directions are"},{"line_number":93,"context_line":"   handled by the same set of CPU cores. This is the case in the non hardware"},{"line_number":94,"context_line":"   offloaded OVS deployments. In this scenario OVS represents a single packet"},{"line_number":95,"context_line":"   processing resource pool. Which can be represented with a single new"},{"line_number":96,"context_line":"   resource class, ``NET_PACKET_RATE_KILOPACKET_PER_SEC``."},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"ad1992f6_8778722f","line":94,"updated":"2021-05-10 12:15:31.000000000","message":"non-hardware-offloaded","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":91,"context_line":"1) The packet processing functionality is implemented on the compute host CPUs"},{"line_number":92,"context_line":"   and therefore packets processed from both ingress and egress directions are"},{"line_number":93,"context_line":"   handled by the same set of CPU cores. This is the case in the non hardware"},{"line_number":94,"context_line":"   offloaded OVS deployments. In this scenario OVS represents a single packet"},{"line_number":95,"context_line":"   processing resource pool. Which can be represented with a single new"},{"line_number":96,"context_line":"   resource class, ``NET_PACKET_RATE_KILOPACKET_PER_SEC``."},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"b29eb29e_029809e7","line":94,"in_reply_to":"ad1992f6_8778722f","updated":"2021-05-10 14:45:11.000000000","message":"Done here and in other occurrences including the nova spec. (Not pushed yet as waiting for the other open question to settle before I update)","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":false,"context_lines":[{"line_number":91,"context_line":"1) The packet processing functionality is implemented on the compute host CPUs"},{"line_number":92,"context_line":"   and therefore packets processed from both ingress and egress directions are"},{"line_number":93,"context_line":"   handled by the same set of CPU cores. This is the case in the non hardware"},{"line_number":94,"context_line":"   offloaded OVS deployments. In this scenario OVS represents a single packet"},{"line_number":95,"context_line":"   processing resource pool. Which can be represented with a single new"},{"line_number":96,"context_line":"   resource class, ``NET_PACKET_RATE_KILOPACKET_PER_SEC``."},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"099b2440_393f9200","line":94,"in_reply_to":"b29eb29e_029809e7","updated":"2021-05-21 14:41:20.000000000","message":"Done","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":199,"context_line":"                    \u0027default\u0027: None,"},{"line_number":200,"context_line":"                    \u0027validate\u0027: {"},{"line_number":201,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":202,"context_line":"                            None,"},{"line_number":203,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":204,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":205,"context_line":"                        )"}],"source_content_type":"text/x-rst","patch_set":6,"id":"d9247f6f_a7b0dcc2","line":202,"updated":"2021-05-10 14:45:11.000000000","message":"@Vivek: Do you mean replace this with constants.BOTH_DIRECTION ?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"1bcc47459b5bc471c1fdb0aff6882c5b7c8a19c6","unresolved":true,"context_lines":[{"line_number":199,"context_line":"                    \u0027default\u0027: None,"},{"line_number":200,"context_line":"                    \u0027validate\u0027: {"},{"line_number":201,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":202,"context_line":"                            None,"},{"line_number":203,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":204,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":205,"context_line":"                        )"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fd5fec62_96fb44fa","line":202,"in_reply_to":"d9247f6f_a7b0dcc2","updated":"2021-05-21 12:25:42.000000000","message":"Yeah, instead of \u0027None\u0027 value indicating directionless, can\u0027t we add one more constant \"BOTH\".","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":false,"context_lines":[{"line_number":199,"context_line":"                    \u0027default\u0027: None,"},{"line_number":200,"context_line":"                    \u0027validate\u0027: {"},{"line_number":201,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":202,"context_line":"                            None,"},{"line_number":203,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":204,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":205,"context_line":"                        )"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5312fb00_b586da6f","line":202,"in_reply_to":"fd5fec62_96fb44fa","updated":"2021-05-21 14:41:20.000000000","message":"Done","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"ec29c2ab4ada6052b95784020998b8ca7f1032ce","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"714031f9_21def7da","line":219,"updated":"2021-05-10 12:15:31.000000000","message":"Since packets are always direction oriented ,  using \u0027directionless\u0027 doesn\u0027t seem augur well with a tenant user understanding.  \n\nWhy can\u0027t this be \u0027BOTH\u0027 and we similarly upswing this BOTH paradigm to the neutron parameters like\n\nPACKET_PROCESSING_CAPACITY\u003d hypervisor:x\n\nPACKET_PROCESSING_CAPACITY_WITH_DIRECTION\u003dhypervisor:egr:ing\n\nHaven\u0027t seen something \u0027directionless\u0027 in neutron and this might be the first spec proposing so?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"f7288e958336b68920fd2fb9592e18e486d93e0f","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"c771b099_afc2d040","line":219,"in_reply_to":"2ee00816_63de5ddd","updated":"2021-05-26 10:42:30.000000000","message":"To me using None or a string to express the situation what we previously called \u0027directionless\u0027 are equally good. However I find the particular string \u0027both\u0027 misleading: when we say 1 kpps both, we do not request 1-1 kpps in both directions, but 1 kpps capacity independent of the direction. Can we find a better word for this?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"1bcc47459b5bc471c1fdb0aff6882c5b7c8a19c6","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"79802f48_2f5cebd7","line":219,"in_reply_to":"4cda1dd5_24cceb80","updated":"2021-05-21 12:25:42.000000000","message":"yes a new enum BOTH representing the fact that the value applies to traffic in BOTH directions.     \n\nI was thinking it would be simpler to have only one parameter:\n\nPACKET_PROCESSING_CAPACITY\u003d \u003cvalue\u003e\n\nand possible \u003cvalue\u003e formats be\n\nhypervisor:x  \n\nor\n\nhypervisor:y:z\n\nIf the cloud admin has configured as \u0027hypervisor:x\u0027,  we encode it internally direction as enum BOTH.\n\nIf the cloud admin has configured as \u0027hypervisor:y:z\u0027  we encode it internally separately for INGRESS and EGRESS.\n\nWould that enable us to completely remove PACKET_PROCESSING_WITH_DIRECTION?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"4cda1dd5_24cceb80","line":219,"in_reply_to":"714031f9_21def7da","updated":"2021-05-10 14:45:11.000000000","message":"Do you mean add a new enum value to the direction field on the API called \"both\" and use that value to indicate that the QoS policy rule is applied to both ingress and egress directions? \n\nIf yes, then:\nI think the only reason I used None instead of a new enum value is that the enum is shared between all the other QoS rules. I can add \"both\" sure.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"2ee00816_63de5ddd","line":219,"in_reply_to":"79802f48_2f5cebd7","updated":"2021-05-21 14:41:20.000000000","message":"Even in a HW offloaded deployment the admin could decide to only define the inventory in a single direction. This means hypervisor:x would be ambiguous. It would either mean NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC\u003dx and NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC\u003d0 or NET_PACKET_RATE_KILOPACKET_PER_SEC\u003dx. So I think we need to keep the config options separate. Or alternatively we need a separate config option that clarifies the meaning of the packet_processing_capacity config option in the ambiguous case.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e454032c9ca001ba7ae4bf81479622f593489d0f","unresolved":true,"context_lines":[{"line_number":216,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":217,"context_line":"``direction`` field of the new QoS policy rule to be omitted (set to None) to"},{"line_number":218,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":219,"context_line":"accounting is directionless."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Mixing direction aware and directionless minimum packet rate rules in the same"},{"line_number":222,"context_line":"QoS policy will always result in a NoValidHost error during scheduling as no"}],"source_content_type":"text/x-rst","patch_set":6,"id":"db5456b0_e32fd3a4","line":219,"in_reply_to":"c771b099_afc2d040","updated":"2021-05-26 13:07:31.000000000","message":"Good point. I agree that BOTH can be misleading. What about SHARED?","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"ec29c2ab4ada6052b95784020998b8ca7f1032ce","unresolved":true,"context_lines":[{"line_number":261,"context_line":""},{"line_number":262,"context_line":"    {"},{"line_number":263,"context_line":"      \"minimum_packet_rate_rule\": {"},{"line_number":264,"context_line":"          \"min_kpps\": 1000"},{"line_number":265,"context_line":"      }"},{"line_number":266,"context_line":"    }"},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"64b25f48_52f65227","line":264,"updated":"2021-05-10 12:15:31.000000000","message":"IMHO when a direction is not supplied, we should implicitly qualify this to be applicable for both directions.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":261,"context_line":""},{"line_number":262,"context_line":"    {"},{"line_number":263,"context_line":"      \"minimum_packet_rate_rule\": {"},{"line_number":264,"context_line":"          \"min_kpps\": 1000"},{"line_number":265,"context_line":"      }"},{"line_number":266,"context_line":"    }"},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"71412d35_e09afde0","line":264,"in_reply_to":"64b25f48_52f65227","updated":"2021-05-10 14:45:11.000000000","message":"Sure. If I add a new enum value for both direction, then we can make that the default on the API. But then I can also make the field mandatory to force a conscious decision from the user to decide.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":false,"context_lines":[{"line_number":261,"context_line":""},{"line_number":262,"context_line":"    {"},{"line_number":263,"context_line":"      \"minimum_packet_rate_rule\": {"},{"line_number":264,"context_line":"          \"min_kpps\": 1000"},{"line_number":265,"context_line":"      }"},{"line_number":266,"context_line":"    }"},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"64604553_015c2c11","line":264,"in_reply_to":"71412d35_e09afde0","updated":"2021-05-21 14:41:20.000000000","message":"Done","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":271,"context_line":"      \"minimum_packet_rate_rule\": {"},{"line_number":272,"context_line":"          \"id\": \"5f126d84-551a-4dcf-bb01-0e9c0df0c793\","},{"line_number":273,"context_line":"          \"min_kpps\": 1000,"},{"line_number":274,"context_line":"          \"direction\": \"egress\""},{"line_number":275,"context_line":"      }"},{"line_number":276,"context_line":"    }"},{"line_number":277,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"445694ad_f87081c8","line":274,"updated":"2021-05-10 14:45:11.000000000","message":"This is a bug in the spec. It should have been None now based on the above API def as the direction is not provided in the request.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0a33aefc31413ff966e54ae7b886e6e6b642f98a","unresolved":false,"context_lines":[{"line_number":271,"context_line":"      \"minimum_packet_rate_rule\": {"},{"line_number":272,"context_line":"          \"id\": \"5f126d84-551a-4dcf-bb01-0e9c0df0c793\","},{"line_number":273,"context_line":"          \"min_kpps\": 1000,"},{"line_number":274,"context_line":"          \"direction\": \"egress\""},{"line_number":275,"context_line":"      }"},{"line_number":276,"context_line":"    }"},{"line_number":277,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"0d478297_8b09bad5","line":274,"in_reply_to":"445694ad_f87081c8","updated":"2021-05-21 14:41:20.000000000","message":"Done","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d68dc6451feb6bc1aff15831b3aa66aae9389be4","unresolved":true,"context_lines":[{"line_number":333,"context_line":"            sa.Column(\u0027qos_policy_id\u0027, sa.String(36),"},{"line_number":334,"context_line":"                      nullable\u003dFalse, index\u003dTrue),"},{"line_number":335,"context_line":"            sa.Column(\u0027min_kpps\u0027, sa.Integer()),"},{"line_number":336,"context_line":"            sa.Column(\u0027direction\u0027, sa.Enum(constants.EGRESS_DIRECTION,"},{"line_number":337,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":338,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":339,"context_line":"                      nullable\u003dTrue,"},{"line_number":340,"context_line":"                      server_default\u003dNone),"},{"line_number":341,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"}],"source_content_type":"text/x-rst","patch_set":6,"id":"73951750_fb9b184d","line":338,"range":{"start_line":336,"start_character":35,"end_line":338,"end_character":61},"updated":"2021-05-10 14:45:11.000000000","message":"@Vivek: this is the enum I\u0027m referring to in the above comments.","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":9361,"name":"Vivekanandan Narasimhan","email":"n.vivekanandan@ericsson.com","username":"viveknarasimhan"},"change_message_id":"1bcc47459b5bc471c1fdb0aff6882c5b7c8a19c6","unresolved":false,"context_lines":[{"line_number":333,"context_line":"            sa.Column(\u0027qos_policy_id\u0027, sa.String(36),"},{"line_number":334,"context_line":"                      nullable\u003dFalse, index\u003dTrue),"},{"line_number":335,"context_line":"            sa.Column(\u0027min_kpps\u0027, sa.Integer()),"},{"line_number":336,"context_line":"            sa.Column(\u0027direction\u0027, sa.Enum(constants.EGRESS_DIRECTION,"},{"line_number":337,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":338,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":339,"context_line":"                      nullable\u003dTrue,"},{"line_number":340,"context_line":"                      server_default\u003dNone),"},{"line_number":341,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"}],"source_content_type":"text/x-rst","patch_set":6,"id":"a5cd90af_82e7728b","line":338,"range":{"start_line":336,"start_character":35,"end_line":338,"end_character":61},"in_reply_to":"73951750_fb9b184d","updated":"2021-05-21 12:25:42.000000000","message":"Ack","commit_id":"31d9f43e2c8993f811bdb55e411cfb02cdb9b800"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e80b59192eb299e17a11e2f119e0e3b525d2f942","unresolved":true,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"de8b4c8a_219d8392","line":134,"updated":"2021-05-27 08:27:47.000000000","message":"nit: do we really need 2 options? Maybe we can combine them in one and add in the code logic which will be able to check if there are 2 directions or only 1 configured.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"53bc33a6e53372e3815d6583ec9e6bc2baf1f811","unresolved":true,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"45c43cf2_9c09f41f","line":134,"in_reply_to":"0d4fe62e_8e8ae0a3","updated":"2021-05-27 16:06:13.000000000","message":"I\u0027m OK to change the name as Rodolfo suggests.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"6b74f0aafc1772dda8bcd370f5a7d17420472014","unresolved":true,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b782465e_1927eda7","line":134,"in_reply_to":"45c43cf2_9c09f41f","updated":"2021-05-31 08:02:58.000000000","message":"I\u0027m not pushing to combine both options into one, but it could be also something like:\n\n    resource_provider_packet_processing \u003d \u003chypervisor\u003e:\u003cegress\u003e:\u003cingress\u003e\n\nand ingress/egress could be emtpy - in such case it would be directionless, something like:\n\n    resource_provider_packet_processing \u003d ::0\n\nBut I\u0027m ok with 2 config options as well.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"26dddd6c_c9599715","line":134,"in_reply_to":"b782465e_1927eda7","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"10ad818b77b36586f9526b2ab2bf49e834109437","unresolved":true,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0d4fe62e_8e8ae0a3","line":134,"in_reply_to":"daf581b4_22e7e604","updated":"2021-05-27 15:05:08.000000000","message":"(just a comment) I\u0027m not sure neither of what to choose. Maybe we can have both, as we have here, to differentiate them.\n\nBTW, let\u0027s keep a naming consistency here. We have \"resource_provider_bandwidths\", \"resource_provider_hypervisors\" and \"resource_provider_inventory_defaults\"\n\nI propose:\n- resource_provider_packet_processing_with_direction\n- resource_provider_packet_processing_without_direction\n\nI\u0027ve removed the work \"capacity\" to reduce the already long name.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":131,"context_line":"    # packet_processing_capacity_without_direction and the"},{"line_number":132,"context_line":"    # packet_processing_capacity_with_direction"},{"line_number":133,"context_line":"    # are mutually exclusive options."},{"line_number":134,"context_line":"    # packet_processing_capacity_with_direction \u003d :0:0"},{"line_number":135,"context_line":"    #"},{"line_number":136,"context_line":"    # Key:value pairs to specify defaults used while reporting packet rate"},{"line_number":137,"context_line":"    # inventories. Possible keys with their types: allocation_ratio:float,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"daf581b4_22e7e604","line":134,"in_reply_to":"de8b4c8a_219d8392","updated":"2021-05-27 12:52:29.000000000","message":"Even in an offloaded OVS case the admin could decide not to provide any inventory for a certain direction. E.g she provides only \":100\". Then we have no way to distinguish between the cases\n1) it is a non offloaded case and the configured value is for the common resource pool\n2) it is an offloaded case and the configured value is for the resource pool for the egress direction\n\nIf  we make it mandatory to provide config value for both direction, even if it is 0, in the offloaded case then we could combine the config. Still that would make the documentation of the config option pretty complex.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"80b8cf4f_f55bec83","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"updated":"2021-05-26 14:39:26.000000000","message":"why not? rule values (min_kbps, dscp mark, max_kpbs) can be updated (not direction)","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"35632c72_dca46740","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"07ca393d_6045b48c","updated":"2021-05-27 12:52:29.000000000","message":"Allowing in all cases needs extra care. But allowing the PUT if the rule is not used in any bound port is easy. So lets do the same as in case of the minimum bandwidth rule. If there rule is not used in any bound port then allow the PUT. Otherwise reject it with HTTP 501. I will updated the spec accordingly.\n\nJust to note this is different from the behavior when the qos_policy_id of a bound port is changed. There today we update the placement allocation for bandwidth and I\u0027m proposing to do so that for packet rate too.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d3e4f1adda71ab405da8c9a35087da383ebb5b64","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"393f11ca_e69b7e5a","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"0def7921_87fc7d75","updated":"2021-05-31 14:33:33.000000000","message":"@Slaweq: when you say \"more correct code\" is it HTTP 400 like in nova? \n\nI\u0027ve reported the doc bug about the missing doc for the HTTP 501 https://bugs.launchpad.net/neutron/+bug/1930283 and pushed the fix https://review.opendev.org/c/openstack/neutron-lib/+/793802","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"53bc33a6e53372e3815d6583ec9e6bc2baf1f811","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"895f9393_652e6984","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"1ea05fc9_8f40ae47","updated":"2021-05-27 16:06:13.000000000","message":"@Rodolfo: OK. I will propose to have the same check for pps as for bandwidth.\n\n@Sean: I know nova suggest to use HTTP 400. I\u0027m not sure if neutron has the same rules about the API response codes. So I defer to Slaweq, Rodolfo or any neutron core to propose what should be the response code \n* 501 as in case of bandwidth for symmetry\n* or 400 that is a bit more correct from the error code definition perspective.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"813030823b7a657846f1c3c22e6144d4de969272","unresolved":false,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8ebefc6c_a1419e10","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"22af6035_8e4a738a","updated":"2021-06-01 11:52:00.000000000","message":"Ack. Change this two occasion to 400 later will be simple. However finding all the other places resulting in HTTP 501 might not be trivial","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"10ad818b77b36586f9526b2ab2bf49e834109437","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1ea05fc9_8f40ae47","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"2ac3bc87_20f3686c","updated":"2021-05-27 15:05:08.000000000","message":"@Slawek yes in [1]. We can change that here but this is a difference from the other qos rules.\n\n@Balazs we can make this check in the Neutron QoS service, as we do now. If QoS rule is attached to a port, the command is aborted.\n\n[1]https://review.opendev.org/c/openstack/neutron/+/747774/22/releasenotes/notes/update_qos_allocation_for_bound_port-5358620322b66ae9.yaml","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"67d4b5f3f833ffa3987cae18ba7603c83f66fd8b","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2ac3bc87_20f3686c","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"35632c72_dca46740","updated":"2021-05-27 13:38:58.000000000","message":"i responded to this on patchset 4 for some reason \nhttps://review.opendev.org/c/openstack/neutron-specs/+/785236/4/specs/xena/qos-minimum-guaranteed-packet-rate.rst#183\nanyway tl;dr we should never us a 501 in this case.\nits an incorrect use fo that error code  and its covered here\nhttps://specs.openstack.org/openstack/api-sig/guidelines/http/response-codes.html#use-of-501-not-implemented\n\nwe shoudl use a 400","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"acc8127f_a6f2a0bb","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"393f11ca_e69b7e5a","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e80b59192eb299e17a11e2f119e0e3b525d2f942","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"07ca393d_6045b48c","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"80b8cf4f_f55bec83","updated":"2021-05-27 08:27:47.000000000","message":"@Rodolfo - and is it reflected in placement allocations in case of min_kbps?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"6b74f0aafc1772dda8bcd370f5a7d17420472014","unresolved":true,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0def7921_87fc7d75","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"895f9393_652e6984","updated":"2021-05-31 08:02:58.000000000","message":"It seems that we don\u0027t have documented that 501 in our api-ref now https://docs.openstack.org/api-ref/network/v2/#qos-minimum-bandwidth-rules so that\u0027s another issue which we probably should fix.\nAccording to this case, personally I think that we can go with 501 to be consistent with our existing API. But we should also open bug for that and try to fix all those places and return more correct code in all such cases. Wdyt?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"70b2b2a3cb425f18cf1a33d88537ba13bb6f26ea","unresolved":false,"context_lines":[{"line_number":184,"context_line":"            \u0027parameters\u0027: {"},{"line_number":185,"context_line":"                qos_apidef._QOS_RULE_COMMON_FIELDS,"},{"line_number":186,"context_line":"                \u0027min_kpps\u0027: {"},{"line_number":187,"context_line":"                    \u0027allow_post\u0027: True, \u0027allow_put\u0027: False,"},{"line_number":188,"context_line":"                    \u0027convert_to\u0027: converters.convert_to_int,"},{"line_number":189,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":190,"context_line":"                    \u0027is_filter\u0027: True,"}],"source_content_type":"text/x-rst","patch_set":7,"id":"22af6035_8e4a738a","line":187,"range":{"start_line":187,"start_character":53,"end_line":187,"end_character":58},"in_reply_to":"acc8127f_a6f2a0bb","updated":"2021-06-01 07:14:53.000000000","message":"Thx gibi. Yeah, I was thinking about changing it to 400 like in nova later for all those places.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4fe5cee3_15e883e7","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"updated":"2021-05-26 14:39:26.000000000","message":"We should not allow rules with both directions. That could break the current QoS API. If needed, you can create two rules.\n\nThis should be:\n                    \u0027validate\u0027: {\n                        \u0027type:values\u0027: constants.VALID_DIRECTIONS}","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"c7ae948ee53b1249d83c4fa281c72121620363fa","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"20ba86be_af075036","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"162023d6_11d56b51","updated":"2021-05-31 08:22:57.000000000","message":"Ok, so let\u0027s use \"any\" for brevity. If we accept this third parameter, we should have something like (from neutron-lib.constants): \n\nINGRESS_DIRECTION \u003d \u0027ingress\u0027\nEGRESS_DIRECTION \u003d \u0027egress\u0027\nANY_DIRECTION \u003d \u0027any\u0027\nVALID_DIRECTIONS \u003d (INGRESS_DIRECTION, EGRESS_DIRECTION)\nVALID_DIRECTIONS_AND_ANY \u003d (INGRESS_DIRECTION, EGRESS_DIRECTION, ANY_DIRECTION)\n\n\n\nAnd we should not accept None as direction. This parameter cannot be None if we accept \"any\", because None value has no sense.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d3e4f1adda71ab405da8c9a35087da383ebb5b64","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"34ef06b9_3eaf31fd","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"20ba86be_af075036","updated":"2021-05-31 14:33:33.000000000","message":"Thanks for the agreement. I will update the spec accordingly.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"eaf63414_6cf92512","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"34ef06b9_3eaf31fd","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e80b59192eb299e17a11e2f119e0e3b525d2f942","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b4277f82_e2e4658c","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"4fe5cee3_15e883e7","updated":"2021-05-27 08:27:47.000000000","message":"I agree with Rodolfo that will be more consistent with our current API even, if in case of non offloaded OVS that really doesn\u0027t makes much sense as no matter which direction user will choose, resources will be consumed from the same pool.\n\nFrom the other hand however, to reflect that case with non hardware offloaded ovs, 3rd value like e.g. ANY could be useful. And actually, we may have potentially way to e.g. validate it and e.g. allow only direction ANY for non hw offloaded drivers and direction INGRESS and EGRESS in the other case. Probably we could use mechanism with supported rules: https://github.com/openstack/neutron/blob/master/neutron/services/qos/drivers/openvswitch/driver.py#L30 which already checks directions. Maybe it would need to be slightly modified to be able to distinguish between offloaded and non offloaded OVS.\n\nSo finally I would personally vote for direction ANY (or BOTH if You prefer that name) as 3rd option and on improved validation of rules later in the code - what do You think?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"6b74f0aafc1772dda8bcd370f5a7d17420472014","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"162023d6_11d56b51","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"9834b6fa_71fe6938","updated":"2021-05-31 08:02:58.000000000","message":"I agree with Gibi and Vivek here - value None can be confusing for users IMHO. Having some other option could be easier to understand what it means. So I still think that DIRECTIONLESS or ANY would be better option than None.\n\nAccording to validation - we already have validation which works during the port binding or associating qos policy to the port/network. Then it checks bound ports if rules from the QoS policy can be used with that port or not. And I think we should be able to reuse this validation mechanism in this case as well.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"10ad818b77b36586f9526b2ab2bf49e834109437","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f84ac863_ab640a39","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"a15343ef_76920fac","updated":"2021-05-27 15:05:08.000000000","message":"If we accept having a \"ternary flag\", I would suggest to allow \"ingress\", \"egress\" and None.\n\nIf None is provided to \"direction\", that means this rule is directionless. I do not recommend, if we allow it, to add another value like \"both\" or \"directionless\".\n\nBut, IMO, we can use only \"ingress\" and \"egress\", using a default one (in Neutron is \"egress\") for the directionless case, using only one configuration variable (what Slawek proposed).\n\nIn case of CPU OVS, the resource will have only an egress value:\n  phy1:1000:0\n\nIn case of HW OVS, the resource will have both:\n  phy1:1000:2000\n\nThe admin can create two different qos policies with only egress (CPU OVS) or egress/ingress (HW OVS) depending on what is needed.\n\nThe only \"problem\" here is the documentation: the admin needs to be aware of what is described with each variable. This solution (1) reduces the number of config vars and (2) keeps the direction value as a binary flag.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a15343ef_76920fac","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"b4277f82_e2e4658c","updated":"2021-05-27 12:52:29.000000000","message":"@Rodolfo: \nIt is not clear to me how the existing QoS API will break if we extend the valid values of the direction field only for this new QoS rule. This could be some technicality in neutron implementation that I\u0027m not aware of. Or is this just to keep the rules similar? But the dscp_marking_rule already directionless so we already have some asymmetry. \n\nThe original alternative was to have direction aware rules and implement logic in neutron to summarize the request if the vnic_type suggest a direction less inventory. But when we further thought about this we realized that:\n\n*) The vnic_type - direction awareness relationship is accidental and not fundamental. So while it can be used today, it might not be future proof. I.e. there can be a backend supporting vnic_type normal where the different directions are handled by different dedicated cpus. \n\n*) Also qos rules and policies are created by the admins and admins already know better what type of deployment they have so they can create the proper rule for the end user.\n\n\n@Slaweq:\nYes, BOTH is not the best word. I talked to Lajos and Bence and we come up with SHARED and DIRECTIONLESS. But ANY also make sense. \n\nRegarding validation: We cannot validate at rule creation time as a deployment both can have computes with offloaded an non offload OVS configs. When the qos policy linked to a port then we know the vnic_type and we can make assumptions about the OVS setup. However as I mentioned above the vnic_type - direction awareness is not a fundamental connection. Moreover we have an ultimate validation happening in placement during the scheduling anyhow. If the port requests direction aware resources but the deployment only has directionless resources then nova will return NoValidHost. I would go with the validation during scheduling.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"53bc33a6e53372e3815d6583ec9e6bc2baf1f811","unresolved":true,"context_lines":[{"line_number":196,"context_line":"                    \u0027allow_post\u0027: True,"},{"line_number":197,"context_line":"                    \u0027allow_put\u0027: False,"},{"line_number":198,"context_line":"                    \u0027is_visible\u0027: True,"},{"line_number":199,"context_line":"                    \u0027validate\u0027: {"},{"line_number":200,"context_line":"                        \u0027type:values\u0027: ("},{"line_number":201,"context_line":"                            constants.BOTH_DIRECTION,"},{"line_number":202,"context_line":"                            constants.INGRESS_DIRECTION,"},{"line_number":203,"context_line":"                            constants.EGRESS_DIRECTION"},{"line_number":204,"context_line":"                        )"},{"line_number":205,"context_line":"                    }"},{"line_number":206,"context_line":"                }"},{"line_number":207,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9834b6fa_71fe6938","line":204,"range":{"start_line":199,"start_character":20,"end_line":204,"end_character":25},"in_reply_to":"f84ac863_ab640a39","updated":"2021-05-27 16:06:13.000000000","message":"\u003e If we accept having a \"ternary flag\", I would suggest to allow \"ingress\", \"egress\" and None.\n\u003e \n\u003e If None is provided to \"direction\", that means this rule is directionless. I do not recommend, if we allow it, to add another value like \"both\" or \"directionless\".\n\u003e \n\u003e But, IMO, we can use only \"ingress\" and \"egress\", using a default one (in Neutron is \"egress\") for the directionless case, using only one configuration variable (what Slawek proposed).\n\u003e \n\nI don\u0027t like reusing \"egress\" to mean directionless. That would cause that the same qos rule mean two different thing depending on which type of OVS the port is bound using the rule.\n\nI can accept the value None. It was the proposal at some point but then Vivek pointed out that a proper third value (like ANY) would have been more explicit and self documenting than None.\n\n\u003e In case of CPU OVS, the resource will have only an egress value:\n\u003e   phy1:1000:0\n\u003e \n\u003e In case of HW OVS, the resource will have both:\n\u003e   phy1:1000:2000\n\u003e \n\nI think you misunderstood the config proposal. The format is \u003chypervisor_hostname\u003e:\u003cdirectionless capacity\u003e and \u003chypervisor_hostname\u003e:\u003cegress capacity\u003e:\u003cingress capacity\u003e. We don\u0027t map packet rate capacity to physnets as the resource is not physnet specific, the resource is generic for the whole OVS instance.\n\n\u003e The admin can create two different qos policies with only egress (CPU OVS) or egress/ingress (HW OVS) depending on what is needed.\n\u003e \n\nBut then QoS policy created with only the default egress direction is still usable for both CPU OVS and HW OVS but it means different things in the different cases. I think this is confusing for the end user selecting from the available policies. \n\n\u003e The only \"problem\" here is the documentation: the admin needs to be aware of what is described with each variable. This solution (1) reduces the number of config vars and (2) keeps the direction value as a binary flag.\n\nInstead of reducing the impact by reducing the number of variables and values I would aim for a more understandable system. So I\u0027d like to keep everything explicit both for the admin and for the end user.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":213,"context_line":"that at least 1000 packets can enter the VM via the given port per second."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":216,"context_line":"``direction`` field of the new QoS policy rule to be set to ``both`` to"},{"line_number":217,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":218,"context_line":"accounting is directionless."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"caef6ce1_36571253","line":216,"range":{"start_line":216,"start_character":62,"end_line":216,"end_character":66},"updated":"2021-05-26 14:39:26.000000000","message":"I don\u0027t agree with this. The \"rule.direction\" parameter only allows \"ingress\" or \"egress\". That could break the current QoS API.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"813030823b7a657846f1c3c22e6144d4de969272","unresolved":true,"context_lines":[{"line_number":213,"context_line":"that at least 1000 packets can enter the VM via the given port per second."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":216,"context_line":"``direction`` field of the new QoS policy rule to be set to ``both`` to"},{"line_number":217,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":218,"context_line":"accounting is directionless."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"e950d94e_e6de9075","line":216,"range":{"start_line":216,"start_character":62,"end_line":216,"end_character":66},"in_reply_to":"0de50614_52424c72","updated":"2021-06-01 11:52:00.000000000","message":"I hope so. Anyhow I consider adding a new constant as an implementation details. :)","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"ebac9d7083002e5a9ee5ade2c27df59fc929637d","unresolved":true,"context_lines":[{"line_number":213,"context_line":"that at least 1000 packets can enter the VM via the given port per second."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":216,"context_line":"``direction`` field of the new QoS policy rule to be set to ``both`` to"},{"line_number":217,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":218,"context_line":"accounting is directionless."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"0de50614_52424c72","line":216,"range":{"start_line":216,"start_character":62,"end_line":216,"end_character":66},"in_reply_to":"a2d57d6d_1c835b03","updated":"2021-05-31 15:09:09.000000000","message":"We use VALID_DIRECTIONS (https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/constants.py#L363 ) for other rules, so we can have a VALID_PPS_DIRECTIONS perhaps and that will used only for pps, isn\u0027t that a way to avoid breaking old rule\u0027s API?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":213,"context_line":"that at least 1000 packets can enter the VM via the given port per second."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":216,"context_line":"``direction`` field of the new QoS policy rule to be set to ``both`` to"},{"line_number":217,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":218,"context_line":"accounting is directionless."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"cbf20083_5e2a3e6a","line":216,"range":{"start_line":216,"start_character":62,"end_line":216,"end_character":66},"in_reply_to":"caef6ce1_36571253","updated":"2021-05-27 12:52:29.000000000","message":"lets discuss it in the above comment.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"6b74f0aafc1772dda8bcd370f5a7d17420472014","unresolved":true,"context_lines":[{"line_number":213,"context_line":"that at least 1000 packets can enter the VM via the given port per second."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To support the two different OVS deployment scenarios we need to allow that the"},{"line_number":216,"context_line":"``direction`` field of the new QoS policy rule to be set to ``both`` to"},{"line_number":217,"context_line":"indicate that this QoS rule is valid in the normal OVS case where the resource"},{"line_number":218,"context_line":"accounting is directionless."},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"a2d57d6d_1c835b03","line":216,"range":{"start_line":216,"start_character":62,"end_line":216,"end_character":66},"in_reply_to":"cbf20083_5e2a3e6a","updated":"2021-05-31 08:02:58.000000000","message":"@Rodolfo - is it possible to allow that new value for direction only for new rule type? Or will it always be available for all types of rules?\nI know we have validation which can check allowed direction per rule type and per driver but that works when policy is associated with port/network. Not on the creation of network.\nI think that we should ensure that this third value of the direction field will be accepted only for that new rule type and not for others. Do You agree with that?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":338,"context_line":"                                           constants.EGRESS_DIRECTION,"},{"line_number":339,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":340,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":341,"context_line":"                      nullable\u003dTrue,"},{"line_number":342,"context_line":"                      server_default\u003dNone),"},{"line_number":343,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":344,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":7,"id":"da9d75f5_084b0928","line":341,"range":{"start_line":341,"start_character":22,"end_line":341,"end_character":35},"updated":"2021-05-26 14:39:26.000000000","message":"direction parameter cannot be null, either the user defines a direction or we provide a default one, same as the other rules\n\n                              default\u003dconstants.EGRESS_DIRECTION,\n                              server_default\u003dconstants.EGRESS_DIRECTION","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":338,"context_line":"                                           constants.EGRESS_DIRECTION,"},{"line_number":339,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":340,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":341,"context_line":"                      nullable\u003dTrue,"},{"line_number":342,"context_line":"                      server_default\u003dNone),"},{"line_number":343,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":344,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1cd37188_387108e5","line":341,"range":{"start_line":341,"start_character":22,"end_line":341,"end_character":35},"in_reply_to":"7e5dc7a2_8fe8ad24","updated":"2021-05-31 16:09:49.000000000","message":"changed to nullable\u003dFalse","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"53bc33a6e53372e3815d6583ec9e6bc2baf1f811","unresolved":true,"context_lines":[{"line_number":338,"context_line":"                                           constants.EGRESS_DIRECTION,"},{"line_number":339,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":340,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":341,"context_line":"                      nullable\u003dTrue,"},{"line_number":342,"context_line":"                      server_default\u003dNone),"},{"line_number":343,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":344,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7e5dc7a2_8fe8ad24","line":341,"range":{"start_line":341,"start_character":22,"end_line":341,"end_character":35},"in_reply_to":"896eede3_41626e76","updated":"2021-05-27 16:06:13.000000000","message":"@Rodolfo: in your above comment at L204 now mentioned that it can be None. So I\u0027m a bit confused. Is it technically not possible to make this nullable, or you just not recommended it?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":338,"context_line":"                                           constants.EGRESS_DIRECTION,"},{"line_number":339,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":340,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":341,"context_line":"                      nullable\u003dTrue,"},{"line_number":342,"context_line":"                      server_default\u003dNone),"},{"line_number":343,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":344,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":7,"id":"896eede3_41626e76","line":341,"range":{"start_line":341,"start_character":22,"end_line":341,"end_character":35},"in_reply_to":"9803b531_7b7d2dfd","updated":"2021-05-27 12:52:29.000000000","message":"OK, then we cannot use None as a direction. If we agree above on the value (ANY, DIRECTIONLESS, SHARED) then I will update this","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e80b59192eb299e17a11e2f119e0e3b525d2f942","unresolved":true,"context_lines":[{"line_number":338,"context_line":"                                           constants.EGRESS_DIRECTION,"},{"line_number":339,"context_line":"                                           constants.INGRESS_DIRECTION,"},{"line_number":340,"context_line":"                                           name\u003d\"directions\"),"},{"line_number":341,"context_line":"                      nullable\u003dTrue,"},{"line_number":342,"context_line":"                      server_default\u003dNone),"},{"line_number":343,"context_line":"            sa.PrimaryKeyConstraint(\u0027id\u0027),"},{"line_number":344,"context_line":"            sa.ForeignKeyConstraint([\u0027qos_policy_id\u0027], [\u0027qos_policies.id\u0027],"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9803b531_7b7d2dfd","line":341,"range":{"start_line":341,"start_character":22,"end_line":341,"end_character":35},"in_reply_to":"da9d75f5_084b0928","updated":"2021-05-27 08:27:47.000000000","message":"+1","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":380,"context_line":"field::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"},{"line_number":384,"context_line":"        ["},{"line_number":385,"context_line":"            {"},{"line_number":386,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9989af3d_c872e8f8","line":383,"range":{"start_line":383,"start_character":8,"end_line":383,"end_character":25},"updated":"2021-05-26 14:39:26.000000000","message":"If the old interface (provide a single dictionary) going to be deprecated?\n\nCan we pass one single dictionary in this list?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":380,"context_line":"field::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"},{"line_number":384,"context_line":"        ["},{"line_number":385,"context_line":"            {"},{"line_number":386,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"}],"source_content_type":"text/x-rst","patch_set":7,"id":"fc8d65a2_3c477678","line":383,"range":{"start_line":383,"start_character":8,"end_line":383,"end_character":25},"in_reply_to":"9989af3d_c872e8f8","updated":"2021-05-27 12:52:29.000000000","message":"\u003e If the old interface (provide a single dictionary) going to be deprecated?\n\nWith a new api extension we replace the old format with the new format. Nova will support both format, depending on the api extension, for at least in Xena to support upgrade. But later on it would be good to make the new format is the only supported one. E.g. deprecate the old api extension in favor of the new api extension. Then nova can drop the compatibility code.\n\n\u003e \n\u003e Can we pass one single dictionary in this list?\n\nYes. This API is now supports any number of dicts in the request_groups list. Realistically neutron will provide 0 (no qos), 1 (either bw or pps qos) or 2 groups (both bw and pps qos). But nova will not assume 0-2 range, it will support 0-N.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":380,"context_line":"field::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"},{"line_number":384,"context_line":"        ["},{"line_number":385,"context_line":"            {"},{"line_number":386,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"}],"source_content_type":"text/x-rst","patch_set":7,"id":"46efa471_e7cac593","line":383,"range":{"start_line":383,"start_character":8,"end_line":383,"end_character":25},"in_reply_to":"d32e9f9d_63551ea3","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"10ad818b77b36586f9526b2ab2bf49e834109437","unresolved":true,"context_lines":[{"line_number":380,"context_line":"field::"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"    {"},{"line_number":383,"context_line":"        \"request_groups\":"},{"line_number":384,"context_line":"        ["},{"line_number":385,"context_line":"            {"},{"line_number":386,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d32e9f9d_63551ea3","line":383,"range":{"start_line":383,"start_character":8,"end_line":383,"end_character":25},"in_reply_to":"fc8d65a2_3c477678","updated":"2021-05-27 15:05:08.000000000","message":"Cool, I agree with using only one format, the new one.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":421,"context_line":"express that the two groups of resources should be fulfilled from two RPs in"},{"line_number":422,"context_line":"the same subtree (in our case from the subtree rooted by the OVS agent RP)"},{"line_number":423,"context_line":"placement needs extra information in the request. Placement supports a"},{"line_number":424,"context_line":"``same_subtree`` parameter that can express what we need. Neutron needs to add"},{"line_number":425,"context_line":"a new top level key ``same_subtree`` to the ``resource_request``"},{"line_number":426,"context_line":"dict. I.e.::"},{"line_number":427,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dd0ecd77_840ac105","line":424,"range":{"start_line":424,"start_character":2,"end_line":424,"end_character":14},"updated":"2021-05-26 14:39:26.000000000","message":"I must be misunderstanding what you commented before. When two or more requests are passed in the same list, I though all of them should be requested from the same RP (OVS, SR-IOV, etc.).\n\nIf no RP can fulfill this request (as commented in L474), the port creation is aborted.\n\nSorry, what I\u0027m missing here?","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":421,"context_line":"express that the two groups of resources should be fulfilled from two RPs in"},{"line_number":422,"context_line":"the same subtree (in our case from the subtree rooted by the OVS agent RP)"},{"line_number":423,"context_line":"placement needs extra information in the request. Placement supports a"},{"line_number":424,"context_line":"``same_subtree`` parameter that can express what we need. Neutron needs to add"},{"line_number":425,"context_line":"a new top level key ``same_subtree`` to the ``resource_request``"},{"line_number":426,"context_line":"dict. I.e.::"},{"line_number":427,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"13805230_6a076923","line":424,"range":{"start_line":424,"start_character":2,"end_line":424,"end_character":14},"in_reply_to":"0375074b_24af0b88","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":421,"context_line":"express that the two groups of resources should be fulfilled from two RPs in"},{"line_number":422,"context_line":"the same subtree (in our case from the subtree rooted by the OVS agent RP)"},{"line_number":423,"context_line":"placement needs extra information in the request. Placement supports a"},{"line_number":424,"context_line":"``same_subtree`` parameter that can express what we need. Neutron needs to add"},{"line_number":425,"context_line":"a new top level key ``same_subtree`` to the ``resource_request``"},{"line_number":426,"context_line":"dict. I.e.::"},{"line_number":427,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"0375074b_24af0b88","line":424,"range":{"start_line":424,"start_character":2,"end_line":424,"end_character":14},"in_reply_to":"5f9ac2fa_1e383117","updated":"2021-05-27 12:52:29.000000000","message":"It is complex. Let\u0027s explain it via a full example:\n\nSo we have a port with a QoS policy that has both bw and pps rules. Then the neutron request will look like this:\n\n    {\n        \"request_groups\":\n        [\n            {\n                \"id\": \"uuid-port-request-group-due-to-min-pps\",\n                \"required\": [CUSTOM_VNIC_TYPE_NORMAL],\n                \"resources\":\n                {\n                    NET_PACKET_RATE_KILOPACKET_PER_SEC: 300,\n                }\n            },\n            {\n                \"id\": \"uuid-port-request-group-due-to-min-bw\",\n                \"required\": [CUSTOM_PHYSNET_PHY0,\n                             CUSTOM_VNIC_TYPE_NORMAL],\n                \"resources\":\n                {\n                    NET_BW_EGR_KILOBIT_PER_SEC: 1000,\n                    NET_BW_IGR_KILOBIT_PER_SEC: 1000,\n                }\n            },\n        ],\n        \"same_subtree\":\n        [\n            \"uuid-port-request-group-due-to-min-pps\",\n            \"uuid-port-request-group-due-to-min-bw\"\n        ]\n    }\n\nThis instructs placement (via nova) to \n* allocate both NET_BW_EGR_KILOBIT_PER_SEC and NET_BW_IGR_KILOBIT_PER_SEC from the same RP as they are requested in the same group.\n* allocate NET_PACKET_RATE_KILOPACKET_PER_SEC from an RP that might or might not be the same as the RP at the previous bullet as it is requested in a different group.\n* same_subtree expresses that the two RPs from the above two bullet points needs to come from the same subtree. More precisely at least one of the RP must be an ancestor of the rest.\n\nSo we need separate groups as to allow BW and PPS to come from different providers. \nBut we need same_subtree to ensure that BW and PPS does not come from two different agents.\n\nIn our specific case the pps resource will be on the agent RP and the bw will be on a bridge RP under the agent RP. This makes using same_subtree easy. If the two resources would come from two RPs that are siblings then in the same_subtree list we would have to add another group that identifies the requested common ancestor of these two RPs.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"65765e08e6ee7f2dcde66580c4a84170f1578679","unresolved":true,"context_lines":[{"line_number":421,"context_line":"express that the two groups of resources should be fulfilled from two RPs in"},{"line_number":422,"context_line":"the same subtree (in our case from the subtree rooted by the OVS agent RP)"},{"line_number":423,"context_line":"placement needs extra information in the request. Placement supports a"},{"line_number":424,"context_line":"``same_subtree`` parameter that can express what we need. Neutron needs to add"},{"line_number":425,"context_line":"a new top level key ``same_subtree`` to the ``resource_request``"},{"line_number":426,"context_line":"dict. I.e.::"},{"line_number":427,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f9ac2fa_1e383117","line":424,"range":{"start_line":424,"start_character":2,"end_line":424,"end_character":14},"in_reply_to":"dd0ecd77_840ac105","updated":"2021-05-26 15:47:06.000000000","message":"Not the RP, but the parent resource provider that should be the agent (OVS, SRIOV, etc.).","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"e80b59192eb299e17a11e2f119e0e3b525d2f942","unresolved":true,"context_lines":[{"line_number":499,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":500,"context_line":""},{"line_number":501,"context_line":"The API extension is the selected alternative as that feels like the standard"},{"line_number":502,"context_line":"way in Neutron to signal API change."},{"line_number":503,"context_line":""},{"line_number":504,"context_line":"Port binding"},{"line_number":505,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4e53fe86_e4a896b8","line":502,"updated":"2021-05-27 08:27:47.000000000","message":"+1 for that","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":499,"context_line":"  key can be used in Nova to detect the new format."},{"line_number":500,"context_line":""},{"line_number":501,"context_line":"The API extension is the selected alternative as that feels like the standard"},{"line_number":502,"context_line":"way in Neutron to signal API change."},{"line_number":503,"context_line":""},{"line_number":504,"context_line":"Port binding"},{"line_number":505,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"efb1ca8b_66146344","line":502,"in_reply_to":"4e53fe86_e4a896b8","updated":"2021-05-31 16:09:49.000000000","message":"Ack","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"3a0d907d5244cc34b08e389022ae893c17f90217","unresolved":true,"context_lines":[{"line_number":530,"context_line":"Only those group id keys are present in this dict that are present in the"},{"line_number":531,"context_line":"``resource_request`` field as ``id``."},{"line_number":532,"context_line":""},{"line_number":533,"context_line":"*Alternatively* we could  ignore the problem for now. Only OVS supports packet"},{"line_number":534,"context_line":"rate inventory for now and the packet rate inventory is global for the whole"},{"line_number":535,"context_line":"OVS instance. A single ``binding:host_id`` always maps to a single OVS"},{"line_number":536,"context_line":"instance, so Neutron can always assume that the minimum packet rate resource"},{"line_number":537,"context_line":"are allocated from the OVS agent resource provider that belongs to the"},{"line_number":538,"context_line":"compute node the port is requested to bound to. So the UUID of the packet"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0644da3e_b97a68a6","line":535,"range":{"start_line":533,"start_character":54,"end_line":535,"end_character":12},"updated":"2021-05-26 14:39:26.000000000","message":"nit: this is just a matter of providing this support for each backend, same as with min-BW (now I\u0027m trying to implement it for OVN, for example)","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dec42d4ff3ad67a06cac6a8f948b0f40e18c1fa6","unresolved":true,"context_lines":[{"line_number":530,"context_line":"Only those group id keys are present in this dict that are present in the"},{"line_number":531,"context_line":"``resource_request`` field as ``id``."},{"line_number":532,"context_line":""},{"line_number":533,"context_line":"*Alternatively* we could  ignore the problem for now. Only OVS supports packet"},{"line_number":534,"context_line":"rate inventory for now and the packet rate inventory is global for the whole"},{"line_number":535,"context_line":"OVS instance. A single ``binding:host_id`` always maps to a single OVS"},{"line_number":536,"context_line":"instance, so Neutron can always assume that the minimum packet rate resource"},{"line_number":537,"context_line":"are allocated from the OVS agent resource provider that belongs to the"},{"line_number":538,"context_line":"compute node the port is requested to bound to. So the UUID of the packet"}],"source_content_type":"text/x-rst","patch_set":7,"id":"19fbb23c_64b4789f","line":535,"range":{"start_line":533,"start_character":54,"end_line":535,"end_character":12},"in_reply_to":"0644da3e_b97a68a6","updated":"2021-05-27 12:52:29.000000000","message":"Yes, this is one of the reason not to chose the this alternative. As soon as SRIOV agent starts implementing pps resources we are forced to use the extended syntax anyhow.","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"33234d57b6217187eb6e393764f2005f43479193","unresolved":false,"context_lines":[{"line_number":530,"context_line":"Only those group id keys are present in this dict that are present in the"},{"line_number":531,"context_line":"``resource_request`` field as ``id``."},{"line_number":532,"context_line":""},{"line_number":533,"context_line":"*Alternatively* we could  ignore the problem for now. Only OVS supports packet"},{"line_number":534,"context_line":"rate inventory for now and the packet rate inventory is global for the whole"},{"line_number":535,"context_line":"OVS instance. A single ``binding:host_id`` always maps to a single OVS"},{"line_number":536,"context_line":"instance, so Neutron can always assume that the minimum packet rate resource"},{"line_number":537,"context_line":"are allocated from the OVS agent resource provider that belongs to the"},{"line_number":538,"context_line":"compute node the port is requested to bound to. So the UUID of the packet"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d661cad1_49887949","line":535,"range":{"start_line":533,"start_character":54,"end_line":535,"end_character":12},"in_reply_to":"19fbb23c_64b4789f","updated":"2021-05-31 16:09:49.000000000","message":"Done","commit_id":"1bea39155fa65c19e6a898b8768ef5b0bb4cd821"}]}