)]}'
{"specs/xena/approved/qos-minimum-guaranteed-packet-rate.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"430666afd737eb8e269a384e9546dc370c9c541a","unresolved":true,"context_lines":[{"line_number":156,"context_line":"  that a single placement request group is fulfilled by a single resource"},{"line_number":157,"context_line":"  provider as that is an unchanged Placement behavior."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"These Nova changes needs to be applied to every code patch in Nova that results"},{"line_number":160,"context_line":"in a new scheduling attempt including:"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"* server create, delete"}],"source_content_type":"text/x-rst","patch_set":2,"id":"65fbf180_465ef0c1","line":159,"range":{"start_line":159,"start_character":53,"end_line":159,"end_character":58},"updated":"2021-04-20 15:19:50.000000000","message":"path","commit_id":"22a8cc5e4651ba7945c39f9d38e8d4558853a9b9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":156,"context_line":"  that a single placement request group is fulfilled by a single resource"},{"line_number":157,"context_line":"  provider as that is an unchanged Placement behavior."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"These Nova changes needs to be applied to every code patch in Nova that results"},{"line_number":160,"context_line":"in a new scheduling attempt including:"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"* server create, delete"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f1fd4ae_bb2920e6","line":159,"range":{"start_line":159,"start_character":53,"end_line":159,"end_character":58},"in_reply_to":"65fbf180_465ef0c1","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"22a8cc5e4651ba7945c39f9d38e8d4558853a9b9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"afcf4cbcf034073aad73a2b582201140027ae2fe","unresolved":true,"context_lines":[{"line_number":302,"context_line":""},{"line_number":303,"context_line":"  * Enable the operation by removing the automatic rejection and keeping only"},{"line_number":304,"context_line":"    the service version check."},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"Dependencies"},{"line_number":307,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":308,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ca4f5a3d_d1824019","line":305,"updated":"2021-04-20 12:03:00.000000000","message":"the implementation of nova-manage placement heal_allocation CLI needs to be adapted to the new resource_request format.","commit_id":"22a8cc5e4651ba7945c39f9d38e8d4558853a9b9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":302,"context_line":""},{"line_number":303,"context_line":"  * Enable the operation by removing the automatic rejection and keeping only"},{"line_number":304,"context_line":"    the service version check."},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"Dependencies"},{"line_number":307,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":308,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1845b478_921f0882","line":305,"in_reply_to":"ca4f5a3d_d1824019","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"22a8cc5e4651ba7945c39f9d38e8d4558853a9b9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":89,"context_line":"  .. note::"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"67cb81bc_a6a350a1","line":92,"updated":"2021-04-26 15:05:51.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":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":89,"context_line":"  .. note::"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ccd1145_b5311929","line":92,"in_reply_to":"67cb81bc_a6a350a1","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Neutron QoS API needs to be extended with the new minimum packet rate QoS"},{"line_number":97,"context_line":"  rule type. The rules of this type need to be persisted in the neutron DB"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfc6fb1a_4ad5ec0b","line":94,"range":{"start_line":94,"start_character":34,"end_line":94,"end_character":77},"updated":"2021-04-26 15:05:51.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":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Neutron QoS API needs to be extended with the new minimum packet rate QoS"},{"line_number":97,"context_line":"  rule type. The rules of this type need to be persisted in the neutron DB"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7cd3c243_e32f09b5","line":94,"updated":"2021-04-26 15:05:51.000000000","message":"see the comment above about the OVS offload case","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Neutron QoS API needs to be extended with the new minimum packet rate QoS"},{"line_number":97,"context_line":"  rule type. The rules of this type need to be persisted in the neutron DB"}],"source_content_type":"text/x-rst","patch_set":3,"id":"63e66bba_2329f5c9","line":94,"in_reply_to":"7cd3c243_e32f09b5","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":91,"context_line":"     While the ``NET_BW_[E|I]GR_KILOBIT_PER_SEC`` inventories are defined"},{"line_number":92,"context_line":"     per bridge / physical device the ``NET_KILOPACKET_PER_SEC`` inventory is"},{"line_number":93,"context_line":"     applied globally to the whole OVS instance. Also while the bandwidth"},{"line_number":94,"context_line":"     inventory is direction aware the packet rate inventory is directionless."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"* Neutron QoS API needs to be extended with the new minimum packet rate QoS"},{"line_number":97,"context_line":"  rule type. The rules of this type need to be persisted in the neutron DB"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0be935d4_03026ed2","line":94,"range":{"start_line":94,"start_character":34,"end_line":94,"end_character":77},"in_reply_to":"dfc6fb1a_4ad5ec0b","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"  .. note::"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"     This is an optional change as the current spec only propose to support"},{"line_number":138,"context_line":"     OVS. A single ``binding:host_id`` always maps to a single OVS instance, so"},{"line_number":139,"context_line":"     Neutron can always assume that the minimum packet rate resource are"},{"line_number":140,"context_line":"     allocated from the OVS agent resource provider that belongs to the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f31506a4_f5a6480d","line":137,"range":{"start_line":137,"start_character":5,"end_line":137,"end_character":31},"updated":"2021-04-26 15:05:51.000000000","message":"feedback from the PTG: agreed to change the allocation dict format to keep it symmetric with the resource_request format.","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"  .. note::"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"     This is an optional change as the current spec only propose to support"},{"line_number":138,"context_line":"     OVS. A single ``binding:host_id`` always maps to a single OVS instance, so"},{"line_number":139,"context_line":"     Neutron can always assume that the minimum packet rate resource are"},{"line_number":140,"context_line":"     allocated from the OVS agent resource provider that belongs to the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"694341dc_50d03383","line":137,"range":{"start_line":137,"start_character":5,"end_line":137,"end_character":31},"in_reply_to":"f31506a4_f5a6480d","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":173,"context_line":"This spec only aiming to give VM scheduling time guarantees for the packet"},{"line_number":174,"context_line":"rate. The data plane enforcement of the new policy is out of scope. Later a"},{"line_number":175,"context_line":"basic data plane enforcement solution can be developed based on the data plane"},{"line_number":176,"context_line":"enforcement implementation of the `packet rate limit policy rule`_."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e4789e74_98869ed7","line":176,"updated":"2021-04-26 15:05:51.000000000","message":"feedback from the PTG: 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":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":173,"context_line":"This spec only aiming to give VM scheduling time guarantees for the packet"},{"line_number":174,"context_line":"rate. The data plane enforcement of the new policy is out of scope. Later a"},{"line_number":175,"context_line":"basic data plane enforcement solution can be developed based on the data plane"},{"line_number":176,"context_line":"enforcement implementation of the `packet rate limit policy rule`_."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c4071e55_89e7e450","line":176,"in_reply_to":"e4789e74_98869ed7","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4891535d194fbe1e8ffaee997bf0ef62273ff3cd","unresolved":true,"context_lines":[{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Neutron will introduce a new API extension that will change the structure and"},{"line_number":260,"context_line":"the semantic of the ``resource_request`` field of the port. Nova needs to"},{"line_number":261,"context_line":"check the existence of the new API extension and parse the field accordingly."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":264,"context_line":"after Xena, the API extension can be made mandatory in Neutron. Then the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b2050277_56362619","line":261,"updated":"2021-04-26 15:05:51.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.\nAlso Xena Nova should keep supporting the old resource_request format as Wallaby Neutron only sends that.","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1017230fc10fdc1fb8774fc42010c12969d6755d","unresolved":false,"context_lines":[{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Neutron will introduce a new API extension that will change the structure and"},{"line_number":260,"context_line":"the semantic of the ``resource_request`` field of the port. Nova needs to"},{"line_number":261,"context_line":"check the existence of the new API extension and parse the field accordingly."},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":264,"context_line":"after Xena, the API extension can be made mandatory in Neutron. Then the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2b1a3af1_da1f9853","line":261,"in_reply_to":"b2050277_56362619","updated":"2021-04-28 16:57:12.000000000","message":"Done","commit_id":"796534a500c817f9ba51e7184bba5218f65f8072"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d3e87d9536b918d9aa2f35ded06867d65a593940","unresolved":true,"context_lines":[{"line_number":76,"context_line":"   hardware resources. This is the case for hardware offloaded OVS. In this"},{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes ``NET_EGR_KILOPACKET_PER_SEC``"},{"line_number":80,"context_line":"   and ``NET_IGR_KILOPACKET_PER_SEC``."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. note::"},{"line_number":83,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"b3f7ca41_803f2f39","line":80,"range":{"start_line":79,"start_character":48,"end_line":80,"end_character":38},"updated":"2021-04-29 18:27:21.000000000","message":"im not 100% sure i like these names but the concept makes sense\n\ni might have gong with NET_KPPS_INGRESS and NET_KPPS_EGRESS and NET_KPPS_TOTAL\n\nthis is because of the module/folder structure of the resouce_classes repo\n\nthe other thing to consider is i and e often have the same sounds in different lanagues e.g. english vs spanish so i think this would be confuing to some as currently written.\n\nif you dont want to spell out ingress and egress specifically we could use \"IN/OUT\" or \"RX/TX\" isntead.\n\nthe other think we shoud note is the dreiction shoudl be form the point of view of the VM not the switch\nto match our exisitng rules for bandwith adn security gorups.\n\ningress to the vm is egress form the switch and exgress form vm is ingress to the swtich.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":true,"context_lines":[{"line_number":76,"context_line":"   hardware resources. This is the case for hardware offloaded OVS. In this"},{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes ``NET_EGR_KILOPACKET_PER_SEC``"},{"line_number":80,"context_line":"   and ``NET_IGR_KILOPACKET_PER_SEC``."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. note::"},{"line_number":83,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"d4f8b002_2fcc5d61","line":80,"range":{"start_line":79,"start_character":48,"end_line":80,"end_character":38},"in_reply_to":"74c5c946_73861687","updated":"2021-05-04 13:59:58.000000000","message":"I think the current proposal is aligned with the neutron terminology. Also the config proposal states the meaning of the direction being from the VM perspective. https://review.opendev.org/c/openstack/neutron-specs/+/785236/4/specs/xena/qos-minimum-guaranteed-packet-rate.rst#129\n\nthe actual name of the resource class it is pretty internal to the system (even though it is visible to the admin via the placement and neutron API). I proposed the current naming as I wanted to be symmetric with the bandwidth resource class https://github.com/openstack/os-resource-classes/blob/145ed791d050725394dbd786a5d45600da656812/os_resource_classes/__init__.py#L59-L62\n\nBut I guess I failed as NET_BW_EGR_KILOBIT_PER_SEC has the form of \u003cwhat_in-unit\u003e so the fully symmetric name would be NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC. \n\nI would like to go with egress and ingress naming instead of in/out rx/tx as the QoS API also use the ingress and egress direction terminology and I would like to keep them in sync.\n\n\u003e this is because of the module/folder structure of the resouce_classes repo\n\nI think you thought about the os-traits repo, the os-resource-classes repo has no extra folder structure.\n\n--\n\nSo what about NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC ?\n\nI\u0027m open to have NET_PACKET_RATE_TOTAL_KILOPACKET_PER_SEC instead of NET_PACKET_RATE_KILOPACKET_PER_SEC for the directionless variant if that removes a possible confusion.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"6b5368ca01c05555f3c1a2db6c7d5680befe3046","unresolved":true,"context_lines":[{"line_number":76,"context_line":"   hardware resources. This is the case for hardware offloaded OVS. In this"},{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes ``NET_EGR_KILOPACKET_PER_SEC``"},{"line_number":80,"context_line":"   and ``NET_IGR_KILOPACKET_PER_SEC``."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. note::"},{"line_number":83,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"74c5c946_73861687","line":80,"range":{"start_line":79,"start_character":48,"end_line":80,"end_character":38},"in_reply_to":"b3f7ca41_803f2f39","updated":"2021-05-03 07:32:57.000000000","message":"For the direction we should follow Neutron terminology to have the same names with the same meaning across all resources:\nhttps://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_firewall.html#ingress-egress-terminology","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"36b01fbbcd01894828da9c6f24e904d03680cfaa","unresolved":false,"context_lines":[{"line_number":76,"context_line":"   hardware resources. This is the case for hardware offloaded OVS. In this"},{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes ``NET_EGR_KILOPACKET_PER_SEC``"},{"line_number":80,"context_line":"   and ``NET_IGR_KILOPACKET_PER_SEC``."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. note::"},{"line_number":83,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."}],"source_content_type":"text/x-rst","patch_set":4,"id":"8b26a26a_c7dd816f","line":80,"range":{"start_line":79,"start_character":48,"end_line":80,"end_character":38},"in_reply_to":"d4f8b002_2fcc5d61","updated":"2021-05-07 09:57:22.000000000","message":"I renamed the RCs in both spec to NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC. @Sean let me know how you feel about it","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"285c55d40f769f0b55f24efba6ce5e5101a97be6","unresolved":true,"context_lines":[{"line_number":160,"context_line":"minimum guaranteed QoS rule types. One which is directionless to support the"},{"line_number":161,"context_line":"case when the resource is also directionless. And two other that are direction"},{"line_number":162,"context_line":"aware to support the other deployment case where the pps resource are also"},{"line_number":163,"context_line":"direction aware."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"*Alternatively* it was suggested that it would be enough to have a single set"},{"line_number":166,"context_line":"of direction aware QoS rule types. Then in case of the normal OVS deployment"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e70a68a3_e66a27b2","line":163,"updated":"2021-04-29 14:53:45.000000000","message":"vnic_type correlates quite well with the resource having a direction or not, however it\u0027s not a logical connection, so I find it cleaner to take the user\u0027s input for direction/less.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":false,"context_lines":[{"line_number":160,"context_line":"minimum guaranteed QoS rule types. One which is directionless to support the"},{"line_number":161,"context_line":"case when the resource is also directionless. And two other that are direction"},{"line_number":162,"context_line":"aware to support the other deployment case where the pps resource are also"},{"line_number":163,"context_line":"direction aware."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"*Alternatively* it was suggested that it would be enough to have a single set"},{"line_number":166,"context_line":"of direction aware QoS rule types. Then in case of the normal OVS deployment"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1f2670ff_626bdbf3","line":163,"in_reply_to":"e70a68a3_e66a27b2","updated":"2021-05-04 13:59:58.000000000","message":"Ack","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"285c55d40f769f0b55f24efba6ce5e5101a97be6","unresolved":true,"context_lines":[{"line_number":184,"context_line":"including the ports of the server. So far the port can only have bandwidth"},{"line_number":185,"context_line":"resource request."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":188,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":189,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":190,"context_line":"``resource_request`` is translated to a single, named Placement request group"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a3b9802c_d0756622","line":187,"range":{"start_line":187,"start_character":40,"end_line":187,"end_character":51},"updated":"2021-04-29 14:53:45.000000000","message":"conceptual nit: I believe the resource_request is only disguised as a Neutron API. Logically it belongs to Nova. It\u0027s a request-response protocol where _Nova_ processes the request (either by itself or delegating parts of it to Placement). For example think about what would happen if multiple other OpenStack components/resources would want to add their resource_requests? Would you want them to each define their own resource request formats or would you want Nova to prescribe a resource_request format for all?\n\nAnd yes, we had to piggyback the resource_request on some pre-existing Nova-Neutron communication channel. Because of that the resource_request field had to become part of the Neutron API too. But Neutron is only a server here as an HTTP-server, for the resource_request logically it\u0027s the other way around, Neutron is the client of Nova.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"9554fce5d750bef72c7ff5dd1810818a54f036c4","unresolved":true,"context_lines":[{"line_number":184,"context_line":"including the ports of the server. So far the port can only have bandwidth"},{"line_number":185,"context_line":"resource request."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":188,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":189,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":190,"context_line":"``resource_request`` is translated to a single, named Placement request group"}],"source_content_type":"text/x-rst","patch_set":4,"id":"478083f6_bcb5ea89","line":187,"range":{"start_line":187,"start_character":40,"end_line":187,"end_character":51},"in_reply_to":"03b0aa8c_e116bb9b","updated":"2021-05-05 11:42:56.000000000","message":"Thanks. Maybe this documentation will help avoid introducing even more custom formats.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"36b01fbbcd01894828da9c6f24e904d03680cfaa","unresolved":false,"context_lines":[{"line_number":184,"context_line":"including the ports of the server. So far the port can only have bandwidth"},{"line_number":185,"context_line":"resource request."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":188,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":189,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":190,"context_line":"``resource_request`` is translated to a single, named Placement request group"}],"source_content_type":"text/x-rst","patch_set":4,"id":"63f168a8_9bcb737b","line":187,"range":{"start_line":187,"start_character":40,"end_line":187,"end_character":51},"in_reply_to":"478083f6_bcb5ea89","updated":"2021-05-07 09:57:22.000000000","message":"Done","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d90d3430a490bb2dc31d1aafe5ee44d45d0240d0","unresolved":true,"context_lines":[{"line_number":184,"context_line":"including the ports of the server. So far the port can only have bandwidth"},{"line_number":185,"context_line":"resource request."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":188,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":189,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":190,"context_line":"``resource_request`` is translated to a single, named Placement request group"}],"source_content_type":"text/x-rst","patch_set":4,"id":"03b0aa8c_e116bb9b","line":187,"range":{"start_line":187,"start_character":40,"end_line":187,"end_character":51},"in_reply_to":"489b4d7c_bd9688f0","updated":"2021-05-05 08:44:22.000000000","message":"After talking to Bence:\n* I will duplicate the final resource_request format in the nova spec to document it\n* I will add a doc impact do document the resource_request in the nova developer doc","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":true,"context_lines":[{"line_number":184,"context_line":"including the ports of the server. So far the port can only have bandwidth"},{"line_number":185,"context_line":"resource request."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":188,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":189,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":190,"context_line":"``resource_request`` is translated to a single, named Placement request group"}],"source_content_type":"text/x-rst","patch_set":4,"id":"489b4d7c_bd9688f0","line":187,"range":{"start_line":187,"start_character":40,"end_line":187,"end_character":51},"in_reply_to":"a3b9802c_d0756622","updated":"2021-05-04 13:59:58.000000000","message":"While I agree with your viewpoint I think Nova team does not enforce the one-true-resource-request format. See the resource request for a cyborg device: https://docs.openstack.org/api-ref/accelerator/v2/index.html?expanded\u003dget-one-device-profile-detail#get-one-device-profile\n\nAlso another point of view is that Neutron API is already providing all the necessary information (vnic_type, phynet name, qos policy and rules) that is needed for nova to figure out what resource are needed, but we decided to put the burden on neutron to re-frame this originally huma facing data to be a more machine readable data for Nova.\n\nAnyhow other than agreeing with the sentiment I don\u0027t see what else I can do here in the spec.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"285c55d40f769f0b55f24efba6ce5e5101a97be6","unresolved":true,"context_lines":[{"line_number":193,"context_line":"while the packet rate resource is allocated from the whole OVS instance the two"},{"line_number":194,"context_line":"groups of resources need to be requested separately. The technical reason to"},{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate needs to"},{"line_number":197,"context_line":"be allocated from different providers then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6ae6e175_1c42f98f","line":197,"range":{"start_line":196,"start_character":71,"end_line":197,"end_character":37},"updated":"2021-04-29 14:53:45.000000000","message":"nit: I believe it\u0027s a (planned) implementation detail that they will be allocated from different providers. In the request we only need to express that we _don\u0027t care_ whether they will be allocated from the same rp or not.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"685d43cfffe14762adee7cd26fc4a384ed7ea878","unresolved":false,"context_lines":[{"line_number":193,"context_line":"while the packet rate resource is allocated from the whole OVS instance the two"},{"line_number":194,"context_line":"groups of resources need to be requested separately. The technical reason to"},{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate needs to"},{"line_number":197,"context_line":"be allocated from different providers then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":4,"id":"924fe883_830ed76a","line":197,"range":{"start_line":196,"start_character":71,"end_line":197,"end_character":37},"in_reply_to":"2243f8de_ef60fb8f","updated":"2021-05-05 14:09:59.000000000","message":"group policy is basically unusable we can never really set it to anything other then none\n\nwe need to replace it at some point with a way of expressing it between groups or just remove it entirely.\n\nisolate can very rarely be used correctly if we have request form multiple sources(flavor, port, cyborg/cinder)","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":false,"context_lines":[{"line_number":193,"context_line":"while the packet rate resource is allocated from the whole OVS instance the two"},{"line_number":194,"context_line":"groups of resources need to be requested separately. The technical reason to"},{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate needs to"},{"line_number":197,"context_line":"be allocated from different providers then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2243f8de_ef60fb8f","line":197,"range":{"start_line":196,"start_character":71,"end_line":197,"end_character":37},"in_reply_to":"6ae6e175_1c42f98f","updated":"2021-05-04 13:59:58.000000000","message":"Good point. What we have to avoid here is to express that we want to have them allocated from the same provider. If we put them in the same group then we force placement to allocated them from the same provider. \n\nI\u0027ve clarified this now.\n\nWhen we put the resources into two separate groups then placement either let the groups overlap or strictly allocate them on different providers. Placement has a configuration knob on the GET /allocation_candidates API. The group_policy [1]. Unfortunately group_policy is a request global parameter (unlike same_subtree where you can define which groups needs to be in the same subtree) so Nova has to do some logic to figure out which group_policy value to use in the query. Today it is defaulted to None, so it allows overlapping. While the admin can override it via the flavor extra_spec to isolate all groups.\n\n[1] https://docs.openstack.org/api-ref/placement/?expanded\u003dlist-allocation-candidates-detail#list-allocation-candidates","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2d0bdf73c8aecaa29497ad72f195cb44c1d99818","unresolved":false,"context_lines":[{"line_number":193,"context_line":"while the packet rate resource is allocated from the whole OVS instance the two"},{"line_number":194,"context_line":"groups of resources need to be requested separately. The technical reason to"},{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate needs to"},{"line_number":197,"context_line":"be allocated from different providers then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a1d59807_caf65e0e","line":197,"range":{"start_line":196,"start_character":71,"end_line":197,"end_character":37},"in_reply_to":"924fe883_830ed76a","updated":"2021-05-06 07:45:12.000000000","message":"I agree.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"285c55d40f769f0b55f24efba6ce5e5101a97be6","unresolved":true,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"The RequestGroup object does not assume anything about the format of the"},{"line_number":267,"context_line":"``requester_id`` field. However other parts of nova might assume that it is the"},{"line_number":268,"context_line":"port_id of the Neutron port. To facilitate distinction between different"},{"line_number":269,"context_line":"groups requested by the same port this assumption might need to be removed."},{"line_number":270,"context_line":"See the changes in the handling of the ``allocation`` key in the port\u0027s"},{"line_number":271,"context_line":"``binding:profile`` how this might change in the `Neutron specification`_"},{"line_number":272,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1a7d99d7_d2065a2e","line":269,"range":{"start_line":268,"start_character":29,"end_line":269,"end_character":75},"updated":"2021-04-29 14:53:45.000000000","message":"At some point these objects may be re-used to support a resource_request coming from a 3rd (non Neutron) component (or for a different Neutron resource). In that case the object is only re-usable if it does not contain such assumptions. Overall Nova may have such assumptions, but because it knows _where_ the resource_request came from (here for example neutron/ports).","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"The RequestGroup object does not assume anything about the format of the"},{"line_number":267,"context_line":"``requester_id`` field. However other parts of nova might assume that it is the"},{"line_number":268,"context_line":"port_id of the Neutron port. To facilitate distinction between different"},{"line_number":269,"context_line":"groups requested by the same port this assumption might need to be removed."},{"line_number":270,"context_line":"See the changes in the handling of the ``allocation`` key in the port\u0027s"},{"line_number":271,"context_line":"``binding:profile`` how this might change in the `Neutron specification`_"},{"line_number":272,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"48bfb7fd_32354edd","line":269,"range":{"start_line":268,"start_character":29,"end_line":269,"end_character":75},"in_reply_to":"1a7d99d7_d2065a2e","updated":"2021-05-04 13:59:58.000000000","message":"Yes. I think we already has the situation that request groups coming from cyborg has a different requester_id [1] while reusing the same RequestGroup object. So at least in the nova-placement interaction, where the groups from neutron and cyborg are mixed, the object works well. There is one networking specific connection though. The InstancePCIRequest.requester_id is also the port_uuid. And we use the RequestSpec.requester_id, which is today also the port_uuid, to look up a corresponding InstancePCIRequest in [2]. This needs to be changed.\n\n[1] https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/accelerator/cyborg.py#L62\n[2] https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/compute/utils.py#L1512","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"285c55d40f769f0b55f24efba6ce5e5101a97be6","unresolved":true,"context_lines":[{"line_number":271,"context_line":"``binding:profile`` how this might change in the `Neutron specification`_"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"The Neutron related resource provider model in Placement needs to be extended"},{"line_number":274,"context_line":"with a new inventory of ``NET_KILOPACKET_PER_SEC`` resource on the OVS agent"},{"line_number":275,"context_line":"resource providers if such resource inventory is configured in the related"},{"line_number":276,"context_line":"agent configuration by the administrator. Also the ``CUSTOM_VNIC_TYPE_`` and"},{"line_number":277,"context_line":"``CUSTOM_PHYSNET_`` traits that today applied only to the bridge and device RPs"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ed6f88b_9b174dae","line":274,"range":{"start_line":274,"start_character":26,"end_line":274,"end_character":48},"updated":"2021-04-29 14:53:45.000000000","message":"Plus the variants with a direction.","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":false,"context_lines":[{"line_number":271,"context_line":"``binding:profile`` how this might change in the `Neutron specification`_"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"The Neutron related resource provider model in Placement needs to be extended"},{"line_number":274,"context_line":"with a new inventory of ``NET_KILOPACKET_PER_SEC`` resource on the OVS agent"},{"line_number":275,"context_line":"resource providers if such resource inventory is configured in the related"},{"line_number":276,"context_line":"agent configuration by the administrator. Also the ``CUSTOM_VNIC_TYPE_`` and"},{"line_number":277,"context_line":"``CUSTOM_PHYSNET_`` traits that today applied only to the bridge and device RPs"}],"source_content_type":"text/x-rst","patch_set":4,"id":"d7296282_6a7fe907","line":274,"range":{"start_line":274,"start_character":26,"end_line":274,"end_character":48},"in_reply_to":"9ed6f88b_9b174dae","updated":"2021-05-04 13:59:58.000000000","message":"Done","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"6b5368ca01c05555f3c1a2db6c7d5680befe3046","unresolved":true,"context_lines":[{"line_number":377,"context_line":"  operation. This way whenever we hit feature freeze we will have a consistent"},{"line_number":378,"context_line":"  system that rejects what is not supported."},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"* Propose the new resource classed to Placement\u0027s os-resource-classes library"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"* Enhance the ``resource_request`` parsing logic to support the new format"},{"line_number":383,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"2fbbd412_76f959fd","line":380,"range":{"start_line":380,"start_character":27,"end_line":380,"end_character":34},"updated":"2021-05-03 07:32:57.000000000","message":"nit: classes","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"935bf793f7f7fa439517288ec33a52a78cdef72a","unresolved":false,"context_lines":[{"line_number":377,"context_line":"  operation. This way whenever we hit feature freeze we will have a consistent"},{"line_number":378,"context_line":"  system that rejects what is not supported."},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"* Propose the new resource classed to Placement\u0027s os-resource-classes library"},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"* Enhance the ``resource_request`` parsing logic to support the new format"},{"line_number":383,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"d4bfde5f_fe9970c7","line":380,"range":{"start_line":380,"start_character":27,"end_line":380,"end_character":34},"in_reply_to":"2fbbd412_76f959fd","updated":"2021-05-04 13:59:58.000000000","message":"Done","commit_id":"adb06adc24cb51e8b41c90768acb76b7dc239be4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":36,"context_line":"---------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"I as an administrator want to define the maximum packet rate, in kilo packet"},{"line_number":39,"context_line":"per second (kpps), my OVS soft switch capable of handle per compute node, so"},{"line_number":40,"context_line":"that I can avoid overload on OVS."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"I as an end user want to define the minimum packet rate, in kilo packet per"}],"source_content_type":"text/x-rst","patch_set":5,"id":"29433df1_6aa11f9f","line":39,"range":{"start_line":39,"start_character":26,"end_line":39,"end_character":30},"updated":"2021-05-06 18:15:10.000000000","message":"nit: software","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":51,"context_line":"rejected in case the requested minimum packet rate guarantee of the Neutron"},{"line_number":52,"context_line":"ports of the server cannot be fulfilled on any otherwise eligible compute"},{"line_number":53,"context_line":"nodes, so that the OVS overload is avoided and application guarantees are kept."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"Proposed change"},{"line_number":56,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":57,"context_line":"The whole solution is very similar and the proposed implementation heavily"}],"source_content_type":"text/x-rst","patch_set":5,"id":"972e1405_c8cb75de","line":54,"updated":"2021-05-06 18:15:10.000000000","message":"+1 i think this is a good set of usescases for this feature","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"Proposed change"},{"line_number":56,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":57,"context_line":"The whole solution is very similar and the proposed implementation heavily"},{"line_number":58,"context_line":"rely on the already implemented `qos guaranteed minimum bandwidth feature`_."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":".. _`qos guaranteed minimum bandwidth feature`: https://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/bandwidth-resource-provider.html"},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"367f64d4_38d532ad","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":76},"updated":"2021-05-06 18:15:10.000000000","message":"nit: i understand what you are saying here but its reads somewhat strangely.\n\n\"As the problem statement is very similar to the guaranteed minimum bandwidth\nfeature, the design and implementation will mirror the design and reuse much of\nthe implementation of the existing minimum bandwidth feature.\"","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes ``NET_EGR_KILOPACKET_PER_SEC``"},{"line_number":80,"context_line":"   and ``NET_IGR_KILOPACKET_PER_SEC``."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. note::"},{"line_number":83,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"These new resource classes needs to be added to Placement\u0027s os-resource-classes"}],"source_content_type":"text/x-rst","patch_set":5,"id":"373385fa_75034a11","line":82,"updated":"2021-05-06 18:15:10.000000000","message":"I\u0027m still not a fan of the resource class names but as you pointed out its consistent with the names used for minimum bandwidth so +1","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":105,"context_line":"``resource_request`` and the ``binding:profile.allocation`` does not need to"},{"line_number":106,"context_line":"change. However there are a list of counter arguments against this direction:"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"* If we define packet processing capacity on the bridges then if there are"},{"line_number":109,"context_line":"  multiple bridges then the overall packet processing capacity of the whole OVS"},{"line_number":110,"context_line":"  would need to be statically split between the bridges, while the actual"},{"line_number":111,"context_line":"  resource usage of OVS are not split in that way in reality."},{"line_number":112,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":113,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":114,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":117,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":118,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":119,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":120,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":121,"context_line":"  reality well."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":5,"id":"8f09d2bf_1a3a7b17","line":121,"range":{"start_line":108,"start_character":1,"end_line":121,"end_character":15},"updated":"2021-05-06 18:15:10.000000000","message":"am dumb question but coudl we not jsut support bandiwth on the bride and model the whole swich as bandwith on br-int?\n\nthat might not work for a reason i have not tought of but it would give you the flexiblity of doing either approch but only one implemeation in code.\n\nwhen this si used with ovn there is alos only one bridge with all interfaces.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"572da655d03c4a6d1a7bd4487e0bb3c87509a285","unresolved":true,"context_lines":[{"line_number":105,"context_line":"``resource_request`` and the ``binding:profile.allocation`` does not need to"},{"line_number":106,"context_line":"change. However there are a list of counter arguments against this direction:"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"* If we define packet processing capacity on the bridges then if there are"},{"line_number":109,"context_line":"  multiple bridges then the overall packet processing capacity of the whole OVS"},{"line_number":110,"context_line":"  would need to be statically split between the bridges, while the actual"},{"line_number":111,"context_line":"  resource usage of OVS are not split in that way in reality."},{"line_number":112,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":113,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":114,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":117,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":118,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":119,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":120,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":121,"context_line":"  reality well."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3afd1374_6e1b3b16","line":121,"range":{"start_line":108,"start_character":1,"end_line":121,"end_character":15},"in_reply_to":"2cc10a1a_7429c67a","updated":"2021-05-07 12:48:00.000000000","message":"so yes i was suggesting br-int would be a new RP used for pps and optionally the tunnenel network bandwith inventoires.\n\nwhere do we currently moddel bandeith invetories for vxlan?\n\nthis was just an idea that occured to me by the way so i had not fully tought it trough so i totally accpet that there may be reason not to take this approch just wanted to ensure it was considered.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d9b6150c9fe922aeba11ad48ccc87d218f49aedb","unresolved":true,"context_lines":[{"line_number":105,"context_line":"``resource_request`` and the ``binding:profile.allocation`` does not need to"},{"line_number":106,"context_line":"change. However there are a list of counter arguments against this direction:"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"* If we define packet processing capacity on the bridges then if there are"},{"line_number":109,"context_line":"  multiple bridges then the overall packet processing capacity of the whole OVS"},{"line_number":110,"context_line":"  would need to be statically split between the bridges, while the actual"},{"line_number":111,"context_line":"  resource usage of OVS are not split in that way in reality."},{"line_number":112,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":113,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":114,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":117,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":118,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":119,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":120,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":121,"context_line":"  reality well."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f2362e6_4a2b3f61","line":121,"range":{"start_line":108,"start_character":1,"end_line":121,"end_character":15},"in_reply_to":"3afd1374_6e1b3b16","updated":"2021-05-07 16:06:36.000000000","message":"Nowhere. It is not supported today. See the second bullet point in [1]\n\n[1]https://docs.openstack.org/neutron/latest/admin/config-qos-min-bw.html#limitations","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"36b01fbbcd01894828da9c6f24e904d03680cfaa","unresolved":true,"context_lines":[{"line_number":105,"context_line":"``resource_request`` and the ``binding:profile.allocation`` does not need to"},{"line_number":106,"context_line":"change. However there are a list of counter arguments against this direction:"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"* If we define packet processing capacity on the bridges then if there are"},{"line_number":109,"context_line":"  multiple bridges then the overall packet processing capacity of the whole OVS"},{"line_number":110,"context_line":"  would need to be statically split between the bridges, while the actual"},{"line_number":111,"context_line":"  resource usage of OVS are not split in that way in reality."},{"line_number":112,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":113,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":114,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":117,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":118,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":119,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":120,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":121,"context_line":"  reality well."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":5,"id":"2cc10a1a_7429c67a","line":121,"range":{"start_line":108,"start_character":1,"end_line":121,"end_character":15},"in_reply_to":"8f09d2bf_1a3a7b17","updated":"2021-05-07 09:57:22.000000000","message":"As far as I understand there could be multiple physnet bridges behind a single OVS and each bridge can have different physical interface with independent bandwidth. So in the bandwidth case the per bridge separation make sense. \n\nIf you are proposing to have the packet processing inventory assigned to the br-int and represent br-int as an RP. Then yes, that could be done. That would mean there is a new RP under the agent RP for br-int and the pps resource is always reported on that RP. For the rest of the implementation this does not simplify anything I think. We still need two separate groups as bw and pps are on different RPs. We still need to use same_subtree to avoid bw and pps allocated from different agents for the same port. We can only reduce the implementation complexity if the bw and the pps resources are on the _same_ bridge RP. But that is not the case.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* While the currently proposed design change is significant it makes the"},{"line_number":127,"context_line":"  solution more future proof. E.g. for the case when the IP pool resource"},{"line_number":128,"context_line":"  handling will be refactored to use the port\u0027s resource_request then we anyhow"}],"source_content_type":"text/x-rst","patch_set":5,"id":"001d9ffb_80be831b","line":125,"updated":"2021-05-06 18:15:10.000000000","message":"yep which is modeled correctly in the bandwith on br-int case\n\nthe main issue with bandwith on br-int is phsynets but you coudl tag the br-int rp will all the phsynets avaiabel on that host to work around that.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"36b01fbbcd01894828da9c6f24e904d03680cfaa","unresolved":true,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* While the currently proposed design change is significant it makes the"},{"line_number":127,"context_line":"  solution more future proof. E.g. for the case when the IP pool resource"},{"line_number":128,"context_line":"  handling will be refactored to use the port\u0027s resource_request then we anyhow"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e77ecb24_929bf677","line":125,"in_reply_to":"001d9ffb_80be831b","updated":"2021-05-07 09:57:22.000000000","message":"see my response to your previous comment.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"572da655d03c4a6d1a7bd4487e0bb3c87509a285","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":124,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"* While the currently proposed design change is significant it makes the"},{"line_number":127,"context_line":"  solution more future proof. E.g. for the case when the IP pool resource"},{"line_number":128,"context_line":"  handling will be refactored to use the port\u0027s resource_request then we anyhow"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fc6c6764_3d2b1dd3","line":125,"in_reply_to":"e77ecb24_929bf677","updated":"2021-05-07 12:48:00.000000000","message":"Ack","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"80d7c9569b705bd3a16d90edd1807e1f36bdfdc9","unresolved":true,"context_lines":[{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate does not"},{"line_number":197,"context_line":"need to come from the same resource provider then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"},{"line_number":201,"context_line":"key in the ``binding:profile`` of the port is used by Nova to communicate the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"88835ab1_c392db5e","line":198,"updated":"2021-05-06 18:15:10.000000000","message":"different request groups but wee need to use same subtree right\n\nalthough im still a little uncertain if that works for with multiple ports\n\nport a request ovs with min bandwith 1G and 100kpps and port b request sriov with 5G and 10kpps\n\n\nsame subtree will pregent the sriov bandwith coming form the ovs provider or vise versa but i dont know if that is suffince in all cases. it might be i just have not though it true fully.\n\n\ni agree they need to be seperate groups and we cannot use group policy.\n\nit feels like a seperate plcement construct like nested_group_#:group_name1:group_name2:...:\u003cgroup policy\u003e; could make this simpler to reaosn about but im not sure its requried today.\nbasicaly a way to express a group polciy only between a set of groups rater then globally\nsame subtree feels like it should be enough but that is what worries me most about this interaction.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"36b01fbbcd01894828da9c6f24e904d03680cfaa","unresolved":true,"context_lines":[{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate does not"},{"line_number":197,"context_line":"need to come from the same resource provider then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"},{"line_number":201,"context_line":"key in the ``binding:profile`` of the port is used by Nova to communicate the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"d0949a0e_ef2873fc","line":198,"in_reply_to":"88835ab1_c392db5e","updated":"2021-05-07 09:57:22.000000000","message":"\u003e different request groups but wee need to use same subtree right\n\nYes see later in the spec.\n\n\u003e \n\u003e although im still a little uncertain if that works for with multiple ports\n\u003e \n\u003e port a request ovs with min bandwith 1G and 100kpps and port b request sriov with 5G and 10kpps\n\u003e \n\u003e \n\u003e same subtree will pregent the sriov bandwith coming form the ovs provider or vise versa but i dont know if that is suffince in all cases. it might be i just have not though it true fully.\n\u003e \n\nIn this case each port defines its own same_subtree requirement in the resource_request. The resulting a_c query will have two separate and independent same_subtree query args, one for port A and one for port B. \n\n\u003e \n\u003e i agree they need to be seperate groups and we cannot use group policy.\n\nThe current Nova impl already adds group_policy\u003dNone to the a_c query if there are neutron ports in the request and no policy is define the the flavor.\n\n\u003e \n\u003e it feels like a seperate plcement construct like nested_group_#:group_name1:group_name2:...:\u003cgroup policy\u003e; could make this simpler to reaosn about but im not sure its requried today.\n\u003e basicaly a way to express a group polciy only between a set of groups rater then globally\n\u003e same subtree feels like it should be enough but that is what worries me most about this interaction.\n\nYeah if we ever want to express anti-affinity between ports, like port A should be allocated from different PF than port B, then we need a more granular group_policy construct in placement.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d9b6150c9fe922aeba11ad48ccc87d218f49aedb","unresolved":true,"context_lines":[{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate does not"},{"line_number":197,"context_line":"need to come from the same resource provider then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"},{"line_number":201,"context_line":"key in the ``binding:profile`` of the port is used by Nova to communicate the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fc0584e3_c978d696","line":198,"in_reply_to":"a92151cd_1abfc59d","updated":"2021-05-07 16:06:36.000000000","message":"Yes. So correctness can be achieved with group_policy\u003dnone today.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"572da655d03c4a6d1a7bd4487e0bb3c87509a285","unresolved":true,"context_lines":[{"line_number":195,"context_line":"this is that a single named resource request group is always allocated from a"},{"line_number":196,"context_line":"single resource provider in Placement. So if bandwidth and packet rate does not"},{"line_number":197,"context_line":"need to come from the same resource provider then they should be requested in"},{"line_number":198,"context_line":"different resource request groups."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"},{"line_number":201,"context_line":"key in the ``binding:profile`` of the port is used by Nova to communicate the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a92151cd_1abfc59d","line":198,"in_reply_to":"d0949a0e_ef2873fc","updated":"2021-05-07 12:48:00.000000000","message":"we agree that while it would be nice now we dont need to implementat that more granular group_policy in placment to move forward with this though correct?\n\nit just makes it simpler to reason about but not actully a requirement for correctness with the current design.","commit_id":"d1d706e451c8454d49ff77e2ce6e8203c10982af"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Similarly how bandwidth can be a limiting factor of a network interface, packet"},{"line_number":14,"context_line":"processing capacity tend to be a limiting factor of the soft switching"},{"line_number":15,"context_line":"solutions like OVS. In the same time certain applications are dependent on not"},{"line_number":16,"context_line":"just guaranteed bandwidth but also on guaranteed packet rate to function"}],"source_content_type":"text/x-rst","patch_set":7,"id":"cf2703db_296d0dc9","line":13,"range":{"start_line":13,"start_character":9,"end_line":13,"end_character":10},"updated":"2021-05-19 16:56:58.000000000","message":"to","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Similarly how bandwidth can be a limiting factor of a network interface, packet"},{"line_number":14,"context_line":"processing capacity tend to be a limiting factor of the soft switching"},{"line_number":15,"context_line":"solutions like OVS. In the same time certain applications are dependent on not"},{"line_number":16,"context_line":"just guaranteed bandwidth but also on guaranteed packet rate to function"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7aa57d4e_be703373","line":13,"range":{"start_line":13,"start_character":9,"end_line":13,"end_character":10},"in_reply_to":"cf2703db_296d0dc9","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"---------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"I as an administrator want to define the maximum packet rate, in kilo packet"},{"line_number":39,"context_line":"per second (kpps), my OVS soft switch capable of handle per compute node, so"},{"line_number":40,"context_line":"that I can avoid overload on OVS."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"ec065433_c232d71e","line":38,"range":{"start_line":38,"start_character":37,"end_line":38,"end_character":76},"updated":"2021-05-19 16:56:58.000000000","message":"Super dumb question, but this will be entirely dependent on the packet size, right? Bigger packets \u003d lower PPS. Are we just assuming that packet size will be/must be consistent across hosts/switches?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"43587af925b2e582fe9cdb78c354850a240a053d","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"---------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"I as an administrator want to define the maximum packet rate, in kilo packet"},{"line_number":39,"context_line":"per second (kpps), my OVS soft switch capable of handle per compute node, so"},{"line_number":40,"context_line":"that I can avoid overload on OVS."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"96a12664_b3c5c28a","line":38,"range":{"start_line":38,"start_character":37,"end_line":38,"end_character":76},"in_reply_to":"6e77bde7_27b9fe8a","updated":"2021-05-20 12:37:54.000000000","message":"Ack","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2092c246634a33172bb8733fe49339eab827a9b8","unresolved":true,"context_lines":[{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"---------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"I as an administrator want to define the maximum packet rate, in kilo packet"},{"line_number":39,"context_line":"per second (kpps), my OVS soft switch capable of handle per compute node, so"},{"line_number":40,"context_line":"that I can avoid overload on OVS."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"6e77bde7_27b9fe8a","line":38,"range":{"start_line":38,"start_character":37,"end_line":38,"end_character":76},"in_reply_to":"ec065433_c232d71e","updated":"2021-05-19 17:49:15.000000000","message":"not nessisarly.\n\nof you take ovs it can proces somewhaare in the region of 1.6-2 mpps\n\nit is more or less the same regardless of if you are usign 9k jumbo frames or 64byte packets.\nthe reasom for this is the bottlenek in packet porcessing is the matching and processign of the packet headers. not the copying of the packet data.\n\nso if you nic bandwith is not not your botte neck for example if you use a 200G nic with kernel ovs and you vary the packet size between 64 and 9k the throughput will change liniarly with the size of the packets but provide your switch is not reaching line rate with your larges packet size reducing the packet size likely wont incease your througput.  the bottleneck is in clasifation and caluating how to forward the packet not in the data transfer.\n\n\nso tl;dr the data processing rate in terms of pps is indepented of packet size provide we are not reaching the bandwith limits or our phsyical interface. so in generally we can ignore packet size in the scenario.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9d302469_88fa4bd3","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"updated":"2021-05-19 16:56:58.000000000","message":"is EGR a common abbreviation for egress? IF not, are we gaining much by shortening it?\n\n(SEC is a common abbreviation of course. In fact, it might even be an official unit)\n\nLater: ah, of course we use this for bandwidth already so this ship has already sailed. Ignore this.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e41d8d9a284f5baf533fa48537386b616446e57f","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"83cb8d2c_2ab2a686","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"255855d6_12ff7cba","updated":"2021-05-20 13:50:27.000000000","message":"soo looking back at teh history the approved design for minimum bandwidth was to use the expanded names but during implemation we deviated \nhttps://review.opendev.org/c/openstack/nova/+/570847/10/nova/rc_fields.py#45\n\ni think this is yet another example of something we shoudl not do in an impmeation wehn it come to any atribute of the destin that is user facing.\nif we wanted to make that change we shoudl have reopend the spec for review and discussed it there.\n\nanyway unless your 100% against the the long name i think we should not use EGR as a contraction.\n\nso we shoudl use NET_PACKET_RATE_EGRESS_KILO_PACKET_PER_SEC or if we want to use a contraction  NET_KPPS_EGRESS,  NET_EGRESS_KPPS\n\nim not going to block on this point but if we had not already release support for minium bandwith feature or specifical release os-resouce classes with NET_BW_EGR_KILOBIT_PER_SEC\ni woudl be argugin that we should do an imidate revert and restore what was appoved in the spec.\n\ni had taken part in the discussion in the resocue class naming on irc and the PTG and i had advocted for the long names.\n\nthe code review happend when i was pulled away form upstream work due to internal intel changes and i would have object strongly to it at the time if i had been aware.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"61d2b7a7_551134cf","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"2bad31de_5c47cedc","updated":"2021-05-21 14:11:18.000000000","message":"If you are OK with the symmetric name then I will keep those. I thought you are blocking on the name.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d4eb586a817f8fd3230ddb284270070260f152eb","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9fcf6409_4b6192e1","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"83cb8d2c_2ab2a686","updated":"2021-05-20 13:58:06.000000000","message":"I\u0027m fine having NET_PACKET_RATE_EGRESS_KILO_PACKET_PER_SEC as the RC name.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2092c246634a33172bb8733fe49339eab827a9b8","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"be4d66b9_3855bd11","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"9d302469_88fa4bd3","updated":"2021-05-19 17:49:15.000000000","message":"i did not think it was which is why i orignally asked for ti to be expanded also .\n\nkpps and mpps are commone abreations however which we are not using.\n\ni would much prefer if we used short names like \nNET_KPPS_EGRESS,  NET_EGRESS_KPPS\n\nincluding PACKET_RATE ii dont think add any value wehn we have kilopacket per second in the name\n\nit just make it more irratating to type","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2bad31de_5c47cedc","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"9fcf6409_4b6192e1","updated":"2021-05-20 17:04:49.000000000","message":"we discussed this on irc and im going to abstain form the RC name.\ni have express my preference above and usually i really care about the nameing but\nim conflicted between maintianing consitency with a name i dissagree with and\nhaving a nice IMO name that breaks consitency.\n\nso ill leave that up to ye to decided.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"43587af925b2e582fe9cdb78c354850a240a053d","unresolved":false,"context_lines":[{"line_number":77,"context_line":"   scenario a single OVS has two independent resource pools one for the"},{"line_number":78,"context_line":"   incoming packets and one for the outgoing packets. Therefore these needs to"},{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":7,"id":"255855d6_12ff7cba","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":25},"in_reply_to":"be4d66b9_3855bd11","updated":"2021-05-20 12:37:54.000000000","message":"Maybe it is only my OCD but I\u0027d like to keep the naming symmetric with the bandwidth resources.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"4cce8c2a_3c26bd32","line":82,"updated":"2021-05-11 16:21:48.000000000","message":"you can\u0027t use both #1 and #2 resource classes then, I guess ?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f1ac5af05eaa4888d5657f72a3fedf75bfb96630","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"2695950a_6ed17c4c","line":82,"in_reply_to":"026689d0_5d3b60f4","updated":"2021-05-20 13:05:18.000000000","message":"Thanks it is clearer now. I will generalize away the CPU cores thingy and use the queue wording. thanks.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"9ce7b691_e6030a2b","line":82,"in_reply_to":"2695950a_6ed17c4c","updated":"2021-05-21 11:14:59.000000000","message":"Thanks","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"73213b9b151c4683eef6203b7002e166e3c5f26e","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"026689d0_5d3b60f4","line":82,"in_reply_to":"39c92fbf_ee11e6c3","updated":"2021-05-20 13:03:18.000000000","message":"Sort of. Could we change \"set of CPU cores\" in 1) for \"same hardware resources\"? It\u0027s possible that there is switch hardware  out there where incoming and outgoing packets are handled by the same hardware or that future OVS versions might allow you to put processing of incoming and outgoing packets on separate sets of CPU core, right?\n\nAlternatively, just ignore this. It\u0027s a nit, after all and I could be talking silly stuff","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"4d3ec07e_bf23ebc8","line":82,"in_reply_to":"4cce8c2a_3c26bd32","updated":"2021-05-13 15:24:55.000000000","message":"In the current neutron implementation as single OVS is either offloaded or not. So the two cases are mutually exclusive on a single compute. I will not that here.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"8e479f50_d6eb755a","line":82,"in_reply_to":"4d3ec07e_bf23ebc8","updated":"2021-05-19 16:56:58.000000000","message":"I assume the above is specific to OVS too. It\u0027s possible that there could be another vSwitch or future version of OVS that allows you to run ingress and egress processing on separate cores, in which case you\u0027d use #2.\n\nThis is kind of nitty, but perhaps it would be better to reword these to state the design of the switch that each solution addresses (i.e. one where ingress and egress queues are processed on the same hardware and therefore constrain each other, and one where they\u0027re separate) before giving OVS-based examples?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"43587af925b2e582fe9cdb78c354850a240a053d","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"39c92fbf_ee11e6c3","line":82,"in_reply_to":"8e479f50_d6eb755a","updated":"2021-05-20 12:37:54.000000000","message":"@Stephen: What you suggest is what I  tried to say. See the snippets from above:\n\n1) ... both ingress and egress directions are handled by the same set of CPU cores ...\n2) ... incoming and outgoing packets are handled by independent hardware resources ...\n\n\nI can add the word \"queue\" as that was missing from the wording. Is this what you are after?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":79,"context_line":"   be represented with two new resource classes"},{"line_number":80,"context_line":"   ``NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC`` and"},{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"e9df01a4_b4e1ea0d","line":82,"in_reply_to":"9ce7b691_e6030a2b","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"These new resource classes needs to be added to Placement\u0027s os-resource-classes"},{"line_number":87,"context_line":"library."}],"source_content_type":"text/x-rst","patch_set":7,"id":"13da718d_58852bb2","line":84,"range":{"start_line":84,"start_character":29,"end_line":84,"end_character":35},"updated":"2021-05-11 16:21:48.000000000","message":"nit: packet*s*","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":81,"context_line":"   ``NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC``."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":".. note::"},{"line_number":84,"context_line":"    1 kilo packet means 1000 packet in the context of packet rate resource."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"These new resource classes needs to be added to Placement\u0027s os-resource-classes"},{"line_number":87,"context_line":"library."}],"source_content_type":"text/x-rst","patch_set":7,"id":"c22157f8_b6a70d93","line":84,"range":{"start_line":84,"start_character":29,"end_line":84,"end_character":35},"in_reply_to":"13da718d_58852bb2","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0339760e_77b2c2eb","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"updated":"2021-05-11 16:21:48.000000000","message":"this assumption works, but then we tie our switch resource capacity on a specific assumption which could change later, meaning we\u0027d have to reshape existing allocations.\n\nBy design, I think we should tell that the inventories of those resource classes should be related to an OVS, not an agent (even if that means creating a child RP just for this)","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"455aa250_82cc1cc7","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"0339760e_77b2c2eb","updated":"2021-05-13 15:24:55.000000000","message":"You have a point. Technically neutron can report a new RP under the agent RP that represents the OVS instance itself. This would mean that the OVS bridge RPs that are under the agent RP today also needs to be moved under the new OVS instance RP. That is possible to do via re-parenting when that is supported in Placement via: https://review.opendev.org/c/openstack/nova-specs/+/788243 \n\nWould be nice to see other reviewer\u0027s view on this change.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"43587af925b2e582fe9cdb78c354850a240a053d","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7e867d65_a3b53154","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"166d6b98_60c056c8","updated":"2021-05-20 12:37:54.000000000","message":"Adding an OVS RP\nPros:\n* better modelling reality (the pps resource is provided by the OVS instance not the agent)\n* possible more future proof if we ever support more than one OVS per agent\nCons:\n* we need to do re-parenting now which is an extra dependency on a new placement feature\n* YAGNI \n\n\nOVN:\nI will keep OVN out of this spec. Today bandwidth is not supported by OVN banckend of neutron but work is ongoing in neutron to make that happen. I guess the assumption still holds that OVN will only manage one OVS instance per hypevisor host. So the current placement model will work for OVN too.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6c96ac44_821d91e0","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"455aa250_82cc1cc7","updated":"2021-05-19 16:56:58.000000000","message":"Is it remotely likely that neutron\u0027s agent will start managing more than a single OVS instance in the future? If not, perhaps YAGNI?\n\nOn another note, how does this work with OVN. Is there a neutron agent there or is it not necessary? I\u0027m not familiar with this aspect of neutron, but DevStack using OVN as the default networking solutions suggests we need to think about it","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18780e6a72459465ae66701ff4c10224bcedd91f","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"166d6b98_60c056c8","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"6c96ac44_821d91e0","updated":"2021-05-19 18:32:22.000000000","message":"the reason we have an ovs agent rp is to act as the aggreateion point.\nwe wont bwe supporting multiple ovs instnace on the same host ever if i have anything to say about it.\nit could happne but its not somethign we shoudl worry about.\n\n\nfor ovn there is only one ovs bringe that is managed by the the ovn nortd and ovs-vswitchd.\nto configure the pps ingentory you would have to poptulate the ovsdb or neutron db with the approate values so that they are valiebl to the ml2 driver.\n\nnormaly this info is pass by the agent to the neutron server via the agent report.\novn and odl resue this same mechanioum i a slightly modified form.\n\nthis is how you set host specific infor that would normally be set by the neutron l2 agent with networking-odl https://docs.openstack.org/networking-odl/ocata/devref/hostconfig.html\n\nbasically \nxport OVSUUID\u003d$(ovs-vsctl get Open_vSwitch . _uuid)\novs-vsctl set Open_vSwitch $OVSUUID external_ids:odl_os_hostconfig_hostid\u003dtest_host\novs-vsctl set Open_vSwitch $OVSUUID external_ids:odl_os_hostconfig_config_odl_l2 \u003d\n\"{“supported_vnic_types”: [{“vnic_type”: “normal”, “vif_type”: “ovs”, \"vif_details\": {} }], “allowed_network_types”: [“local”], “bridge_mappings”: {“physnet1\":\"br-ex”}}\"\n\n\ni believe ovn does something similar basically using pseudo agent reports\nhttps://docs.openstack.org/networking-ovn/latest/install/manual.html#compute-nodes\n\nthat being said im not sure it support minimum bandwidth qos or any feature that has required any complex per host config like this. \nthe bridge mappings are stored in teh external ids fiuld of the ovn southdb chassis table though\nhttps://docs.openstack.org/neutron/latest/admin/ovn/sriov.html#ovn-database-information\n\ni would expect the bandwith and pps inventory info to be stored there also.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"808a10d4_9db121ac","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"6cbf04b6_fd604a67","updated":"2021-05-21 11:14:59.000000000","message":"OK, we entered a 2-hour discussion about modeling those resouces and we eventually ended up agreeing on the fact that we have a resource provider that I\u0027d preferably call it \"a beast\" that would contain OVS-specific inventories.\n\nFor the sake of brevity, no other resources that are agent-specific are already defined on this \u0027beast\u0027.\nAlso, making an analogy with nova-compute service, the QEMU endpoint and our current ComputeNode ResourceProvider, this sounds acceptable to tie such things and defer the need of a specific \u0027agent\u0027 RP later on if someone feels fancy writing it.\n\nhttp://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2021-05-21.log.html#t2021-05-21T10:33:22","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":true,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6cbf04b6_fd604a67","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"7e867d65_a3b53154","updated":"2021-05-20 17:04:49.000000000","message":"without a lot of change to nova and neutron we cannot support more then one ovs on a host.\n\nfor example the ml2 driver would have to passh the ovs connection info as part of the port binding detail from neutron to\nnova so that we know which ovs to talk to.\n\nprior to https://review.opendev.org/c/openstack/nova/+/602432 it was not possible at all since libvirt will use ovs-vsctl directly and had no support for specifying how to connect to ovs to my knowledge.\n\ni also agree that we likely should keep ovn out of the spec but im in the camp that we probably dont need ovs RP either. if we did i would argue we do not need the agent RP at all.\nhaving both feels redundant to me so if we added the ovs RP i would remove the agent RP.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":94,"context_line":"As the packet processing resource is provided by the OVS service itself"},{"line_number":95,"context_line":"therefore the packet processing resource needs to be modeled on an entity that"},{"line_number":96,"context_line":"is global for the whole OVS service. Today we have such entity, the Neutron OVS"},{"line_number":97,"context_line":"agent itself. This assumes that one Neutron OVS agent only handles one OVS"},{"line_number":98,"context_line":"which is true today."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":101,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0588e7bb_f192f4b7","line":98,"range":{"start_line":97,"start_character":14,"end_line":98,"end_character":20},"in_reply_to":"808a10d4_9db121ac","updated":"2021-05-21 14:11:18.000000000","message":"Thanks again for the discussion. I added the link to the spec for reference.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":true,"context_lines":[{"line_number":113,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":114,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":115,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":118,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c104a443_6108a7f3","line":116,"updated":"2021-05-20 17:04:49.000000000","message":"again unless we defien the switch banding on the integration bridge (br-int) alone\nas all traffic to and from vms will pass though that bridge regardless of if it is vxlan or vlan.\nyou dont need to add that as an alternative but i wanted to point out that modelign the pps on an ovs bridge does not mean we would our should\nmodel it on the provider bridge with the nics or the br-tun that is use for tunneled traffic.\n\ni was originally suggesting modelign it on the br-int to model the over all swich  packet rate.\n\nas i said you dont have to add this alternitive but if you mention modelign it on the bridge i think it should be included.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Configuration with multiple bridges are possible today, even in the"},{"line_number":114,"context_line":"  frequently used case of having one phynet bridge for VLAN traffic and one"},{"line_number":115,"context_line":"  tunneling bridge for the VXLAN traffic."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* In case of bandwidth the actual resource is behind the physnet bridge, the"},{"line_number":118,"context_line":"  physical interface the bridge is connected to, so the resource is dedicated"},{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"}],"source_content_type":"text/x-rst","patch_set":7,"id":"182e36c1_4c823ec4","line":116,"in_reply_to":"c104a443_6108a7f3","updated":"2021-05-21 14:11:18.000000000","message":"Added as a separate alternative.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":120,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":121,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":122,"context_line":"  reality well."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":125,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"377fb6ea_bfc8015c","line":122,"updated":"2021-05-11 16:21:48.000000000","message":"To be clear, the resource value is really restricted by the OVS performance, not the bridge, right? To me, if so, that\u0027s also why we do care counting the resources on the OVS agent and not on the bridge, as where the real limitations and performance are.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":120,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":121,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":122,"context_line":"  reality well."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":125,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"4051c39c_6492c883","line":122,"in_reply_to":"377fb6ea_bfc8015c","updated":"2021-05-13 15:24:55.000000000","message":"yes, this is what I wanted to say with \"the resource is not at all dedicated to the given bridge\". I can add to that \"But it is dedicated to the whole OVS instance.\"","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":120,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":121,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":122,"context_line":"  reality well."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":125,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"60ec3350_90a25b00","line":122,"in_reply_to":"4051c39c_6492c883","updated":"2021-05-19 16:56:58.000000000","message":"@gibi that would be a good addition","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":119,"context_line":"  to the bridge. But in case of packet processing the actual resource is not at"},{"line_number":120,"context_line":"  all dedicated to the given bridge. So while we can assign a portion of the"},{"line_number":121,"context_line":"  overall resource to the bridge this assignment would never represent the"},{"line_number":122,"context_line":"  reality well."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* Traffic between the VMs on the same host does not flow through the physnet or"},{"line_number":125,"context_line":"  tunneling bridges but it does impact the capacity of the OVS on the host."}],"source_content_type":"text/x-rst","patch_set":7,"id":"eabe511a_ccdacda2","line":122,"in_reply_to":"60ec3350_90a25b00","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":136,"context_line":"----------------------------"},{"line_number":137,"context_line":"For details of these Neutron changes please see the `Neutron specification`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Neutron OVS agent needs to provide configuration options for the"},{"line_number":140,"context_line":"  administrator to define the maximum packet processing capacity of the OVS"},{"line_number":141,"context_line":"  per compute node. Depending on the deployment scenario this might mean a"},{"line_number":142,"context_line":"  single directionless inventory value, or two direction aware values."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ddb3283c_6602cfa3","line":141,"range":{"start_line":139,"start_character":2,"end_line":141,"end_character":19},"updated":"2021-05-11 16:21:48.000000000","message":"just to make it clear, the configuration option would be for the capacity of the switch, not the agent directly, right?\n\nI\u0027m asking this, because, as you said, you can at the moment only have one OVS per agent but I wouldn\u0027t want us restricting on the agent because of this.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":true,"context_lines":[{"line_number":136,"context_line":"----------------------------"},{"line_number":137,"context_line":"For details of these Neutron changes please see the `Neutron specification`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Neutron OVS agent needs to provide configuration options for the"},{"line_number":140,"context_line":"  administrator to define the maximum packet processing capacity of the OVS"},{"line_number":141,"context_line":"  per compute node. Depending on the deployment scenario this might mean a"},{"line_number":142,"context_line":"  single directionless inventory value, or two direction aware values."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6b7c7061_13995877","line":141,"range":{"start_line":139,"start_character":2,"end_line":141,"end_character":19},"in_reply_to":"2b3bff52_f73d0a51","updated":"2021-05-20 17:04:49.000000000","message":"partly although i will point out that unless we are talkd about ovs with dpdk the capasity of ovs is really limited by the ovs kernel module which is istself multi thread.\n\nso if we had multiple ovs instanf that all used the kernel data plane it would not increase the capasisty as far as im aware.\n\nthe only way that multiple ovs insntace on the same hsot would increase capastiy is if you had a mix of kernel ovs, dpdk ovs and hardware offloaded ovs.\n\nhardware offloaded ovs actully supprot vnic type normal as well by the way in shich case those vnic_type normal port are hanedl by kernel ovs datapath where as the vnic_type direct interfaces woudl be handeld in hardware.\n\n\na singel ovs-vswithcd process and ovsdb process can handel multiple datapaths concurrently but each brdige must be only one data path and ovs patch patch ports cannot be used to interconnect port in different data paths.\n\nso unless you are going to have intervm traffic on the same host but differnt ovs data path comunicate via teh phycial networ via the top of rack switch there is no real utilitiy in running ovs with dpdk an kernel ovs on the same host. and since you can already using kernel ovs with hardware offloaded and non offloaded ports on the same host today i dont see any reason to run a seocn ovs instnace in that case either.\n\n\nso form my pint of view modleing the capsiaty as the capastiy the agent has vs the vswtich has the same sematics. there will be a 1:1 mapping between teh too unless things radically cahnge.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":136,"context_line":"----------------------------"},{"line_number":137,"context_line":"For details of these Neutron changes please see the `Neutron specification`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Neutron OVS agent needs to provide configuration options for the"},{"line_number":140,"context_line":"  administrator to define the maximum packet processing capacity of the OVS"},{"line_number":141,"context_line":"  per compute node. Depending on the deployment scenario this might mean a"},{"line_number":142,"context_line":"  single directionless inventory value, or two direction aware values."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a2f1ef4e_d4934ad0","line":141,"range":{"start_line":139,"start_character":2,"end_line":141,"end_character":19},"in_reply_to":"3a5688d7_0e4dbbc2","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":true,"context_lines":[{"line_number":136,"context_line":"----------------------------"},{"line_number":137,"context_line":"For details of these Neutron changes please see the `Neutron specification`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Neutron OVS agent needs to provide configuration options for the"},{"line_number":140,"context_line":"  administrator to define the maximum packet processing capacity of the OVS"},{"line_number":141,"context_line":"  per compute node. Depending on the deployment scenario this might mean a"},{"line_number":142,"context_line":"  single directionless inventory value, or two direction aware values."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3a5688d7_0e4dbbc2","line":141,"range":{"start_line":139,"start_character":2,"end_line":141,"end_character":19},"in_reply_to":"6b7c7061_13995877","updated":"2021-05-21 11:14:59.000000000","message":"See my last comment above.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":136,"context_line":"----------------------------"},{"line_number":137,"context_line":"For details of these Neutron changes please see the `Neutron specification`_."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"* Neutron OVS agent needs to provide configuration options for the"},{"line_number":140,"context_line":"  administrator to define the maximum packet processing capacity of the OVS"},{"line_number":141,"context_line":"  per compute node. Depending on the deployment scenario this might mean a"},{"line_number":142,"context_line":"  single directionless inventory value, or two direction aware values."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2b3bff52_f73d0a51","line":141,"range":{"start_line":139,"start_character":2,"end_line":141,"end_character":19},"in_reply_to":"ddb3283c_6602cfa3","updated":"2021-05-13 15:24:55.000000000","message":"True. It this is the capacity of the OVS instance not the capacity of the OVS agent.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":145,"context_line":"  server via the agent hearth beat."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":148,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":149,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Requesting minimum packet rate guarantees"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8633dd34_6a044407","line":149,"range":{"start_line":148,"start_character":49,"end_line":149,"end_character":42},"updated":"2021-05-11 16:21:48.000000000","message":"that\u0027s where I possibly disagree. The performance is not coming from the agent, but from the switch itself, so the inventory should be related to it.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":true,"context_lines":[{"line_number":145,"context_line":"  server via the agent hearth beat."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":148,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":149,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Requesting minimum packet rate guarantees"}],"source_content_type":"text/x-rst","patch_set":7,"id":"e8351441_f8280a7f","line":149,"range":{"start_line":148,"start_character":49,"end_line":149,"end_character":42},"in_reply_to":"5947d323_1c5f6ca6","updated":"2021-05-20 17:04:49.000000000","message":"actully if we are being pedantic its proably an atribute of the dataplane used by the indivgual bridges and wthere its offoladed or not and to what degree to hardware and if you are using dpdk or the ovs kernel dataplane\n\nunless you are using the unaccaltreate netdev data plane which has always been experimental the ovs-vswichd process is generally not respocnibel for any fo the actul data proceeing.\n\nthat is either don in the ovs kernel modle or in the dpdk pmd or in hardware.\n\nso the permacie is determein by the dataplane implation  and ovs as in the ovs-vswichd and ovsdb are cable of using multiple bridge with different dataplen concucnetly on the same host.\n\n\nbut as i mentioned above i dont hink its realistic to expect there to be a mix of multiple dataplanes on the same host.\nit feel like a premature optimisation to desgin for that usecase.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":145,"context_line":"  server via the agent hearth beat."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":148,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":149,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Requesting minimum packet rate guarantees"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5947d323_1c5f6ca6","line":149,"range":{"start_line":148,"start_character":49,"end_line":149,"end_character":42},"in_reply_to":"8633dd34_6a044407","updated":"2021-05-13 15:24:55.000000000","message":"I see your point. See my response to your similar comment at L98","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  server via the agent hearth beat."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":148,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":149,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Requesting minimum packet rate guarantees"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d406241a_55ec911f","line":149,"range":{"start_line":148,"start_character":49,"end_line":149,"end_character":42},"in_reply_to":"cfb924e2_b90d09a1","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":true,"context_lines":[{"line_number":145,"context_line":"  server via the agent hearth beat."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":148,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":149,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Requesting minimum packet rate guarantees"}],"source_content_type":"text/x-rst","patch_set":7,"id":"cfb924e2_b90d09a1","line":149,"range":{"start_line":148,"start_character":49,"end_line":149,"end_character":42},"in_reply_to":"e8351441_f8280a7f","updated":"2021-05-21 11:14:59.000000000","message":"Again, I adressed my concern above.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c2a891b3316813d7aa2e0246277f8a8c83a53f3","unresolved":true,"context_lines":[{"line_number":163,"context_line":"aware to support the other deployment case where the pps resource are also"},{"line_number":164,"context_line":"direction aware."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"*Alternatively* it was suggested that it would be enough to have a single set"},{"line_number":167,"context_line":"of direction aware QoS rule types. Then in case of the normal OVS deployment"},{"line_number":168,"context_line":"scenario, where the resource is directionless, the resource requests from the"},{"line_number":169,"context_line":"direction aware QoS rules could be added together before matched against the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba1e2a20_31caa84e","line":166,"range":{"start_line":166,"start_character":0,"end_line":166,"end_character":16},"updated":"2021-05-20 17:04:49.000000000","message":"are you going to put these secont in the alternitive section later by the way.\n\ni think these shoudl be move before the final version to make the final document clearer but it would be nice to keep them for context and to note what we discarded and why.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":true,"context_lines":[{"line_number":163,"context_line":"aware to support the other deployment case where the pps resource are also"},{"line_number":164,"context_line":"direction aware."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"*Alternatively* it was suggested that it would be enough to have a single set"},{"line_number":167,"context_line":"of direction aware QoS rule types. Then in case of the normal OVS deployment"},{"line_number":168,"context_line":"scenario, where the resource is directionless, the resource requests from the"},{"line_number":169,"context_line":"direction aware QoS rules could be added together before matched against the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d05ccfdc_8f81dde5","line":166,"range":{"start_line":166,"start_character":0,"end_line":166,"end_character":16},"in_reply_to":"ba1e2a20_31caa84e","updated":"2021-05-21 14:11:18.000000000","message":"Is it OK if I put a separate cleanup patch top of this that do the move? That way we can keep the context to any further discussion on this spec in place, but the later published document about our agreement will be cleaner.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":186,"context_line":"resource request."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":189,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":190,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":191,"context_line":"``resource_request`` is translated to a single, named Placement request group"},{"line_number":192,"context_line":"during scheduling. As a single port can have both bandwidth and packet rate QoS"},{"line_number":193,"context_line":"applied and because bandwidth is allocated from the bridge / physical device"}],"source_content_type":"text/x-rst","patch_set":7,"id":"300df871_71c50702","line":190,"range":{"start_line":189,"start_character":53,"end_line":190,"end_character":52},"updated":"2021-05-11 16:21:48.000000000","message":"yup, that\u0027s the crux of the change.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":false,"context_lines":[{"line_number":186,"context_line":"resource request."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"To support the new packet rate resource Neutron API needs to be changed so that"},{"line_number":189,"context_line":"the ``resource_request`` read only field of the port could contain more than"},{"line_number":190,"context_line":"one group of requested resources and required traits. Today the content of the"},{"line_number":191,"context_line":"``resource_request`` is translated to a single, named Placement request group"},{"line_number":192,"context_line":"during scheduling. As a single port can have both bandwidth and packet rate QoS"},{"line_number":193,"context_line":"applied and because bandwidth is allocated from the bridge / physical device"}],"source_content_type":"text/x-rst","patch_set":7,"id":"72608e9a_af6a0d20","line":190,"range":{"start_line":189,"start_character":53,"end_line":190,"end_character":52},"in_reply_to":"300df871_71c50702","updated":"2021-05-13 15:24:55.000000000","message":"Ack","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":229,"context_line":"            \u003cid of the second group from above\u003e"},{"line_number":230,"context_line":"        ]"},{"line_number":231,"context_line":"    }"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"For the reasoning why we need this format see the `Neutron specification`_"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":7,"id":"18aed61b_40891745","line":232,"updated":"2021-05-11 16:21:48.000000000","message":"++","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":false,"context_lines":[{"line_number":229,"context_line":"            \u003cid of the second group from above\u003e"},{"line_number":230,"context_line":"        ]"},{"line_number":231,"context_line":"    }"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"For the reasoning why we need this format see the `Neutron specification`_"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f3ec956a_a2b82b50","line":232,"in_reply_to":"18aed61b_40891745","updated":"2021-05-13 15:24:55.000000000","message":"Ack","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":251,"context_line":"* Nova needs to adapt to the changes in the structure and semantics of the"},{"line_number":252,"context_line":"  ``resource_request`` field of the neutron port. Today Nova translates this"},{"line_number":253,"context_line":"  field to a single named resource request group. After the Neutron changes"},{"line_number":254,"context_line":"  this field will communicate a list of such request groups."},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* Nova also assumes today that a port only allocates resource from a single"},{"line_number":257,"context_line":"  resource provider. This assumption needs to be removed and the implementation"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bf259d29_4f71246f","line":254,"updated":"2021-05-11 16:21:48.000000000","message":"I\u0027m unclear, would that mean it would change the query for existing requested bandwidth ? (when you don\u0027t ask for pps performance, like now)","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":false,"context_lines":[{"line_number":251,"context_line":"* Nova needs to adapt to the changes in the structure and semantics of the"},{"line_number":252,"context_line":"  ``resource_request`` field of the neutron port. Today Nova translates this"},{"line_number":253,"context_line":"  field to a single named resource request group. After the Neutron changes"},{"line_number":254,"context_line":"  this field will communicate a list of such request groups."},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* Nova also assumes today that a port only allocates resource from a single"},{"line_number":257,"context_line":"  resource provider. This assumption needs to be removed and the implementation"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9f68e862_355998e8","line":254,"in_reply_to":"0cd1cd08_77692ab5","updated":"2021-05-21 11:14:59.000000000","message":"Thanks.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":251,"context_line":"* Nova needs to adapt to the changes in the structure and semantics of the"},{"line_number":252,"context_line":"  ``resource_request`` field of the neutron port. Today Nova translates this"},{"line_number":253,"context_line":"  field to a single named resource request group. After the Neutron changes"},{"line_number":254,"context_line":"  this field will communicate a list of such request groups."},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* Nova also assumes today that a port only allocates resource from a single"},{"line_number":257,"context_line":"  resource provider. This assumption needs to be removed and the implementation"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0cd1cd08_77692ab5","line":254,"in_reply_to":"bf259d29_4f71246f","updated":"2021-05-13 15:24:55.000000000","message":"The format of the resource_request needs to change to accommodate the case when both pps and bandwidth is requested for the same port. Therefore we need a list. When only bandwidth or only pps is requested we still use the same format, a list, but it will only have a single request group in that list. \n\nSo in short, yes the format of the resource_request will change for the case when only bandwidth is requested. The meaning of the request will not change.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":271,"context_line":"What is out of scope"},{"line_number":272,"context_line":"--------------------"},{"line_number":273,"context_line":"Supporting minimum packet rate policy for other than OVS backends are out of"},{"line_number":274,"context_line":"scope but can be handled later with a similar proposal."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"This spec only aiming to give scheduling time guarantees for the packet"},{"line_number":277,"context_line":"rate. The data plane enforcement of the new policy is out of scope. When the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"02128502_7e671c52","line":274,"updated":"2021-05-11 16:21:48.000000000","message":"well, sec. How an end user can know that if their want to provide a pps query for a port, this would or wouldn\u0027t work, then ? Would they get some exception when defining the port if the neutron port isn\u0027t OVS backed ?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":271,"context_line":"What is out of scope"},{"line_number":272,"context_line":"--------------------"},{"line_number":273,"context_line":"Supporting minimum packet rate policy for other than OVS backends are out of"},{"line_number":274,"context_line":"scope but can be handled later with a similar proposal."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"This spec only aiming to give scheduling time guarantees for the packet"},{"line_number":277,"context_line":"rate. The data plane enforcement of the new policy is out of scope. When the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"282e637d_2db68b0f","line":274,"in_reply_to":"02128502_7e671c52","updated":"2021-05-13 15:24:55.000000000","message":"Mostly via documentation and via the admin who creates the QoS policies for the end user.\n\nSimilarly, today nothing prevents you to request bandwidth in a cloud that does not have bandwidth inventory. Or nothing prevents you to request VGPU even if there is no VGPU inventory. It will result in a NoValidHost during scheduling. \n\nSimilarly nova does not prevent you to create a flavor that will never fit to any existing compute in the system. \n\nIf you create a QoS policy with pps, and then attach that to a neutron port with vnic_type\u003ddirect-physical (the only vnic type OVS does not support today if so configured) then the boot with that port will result in placement returning zero allocation candidates.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":false,"context_lines":[{"line_number":271,"context_line":"What is out of scope"},{"line_number":272,"context_line":"--------------------"},{"line_number":273,"context_line":"Supporting minimum packet rate policy for other than OVS backends are out of"},{"line_number":274,"context_line":"scope but can be handled later with a similar proposal."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"This spec only aiming to give scheduling time guarantees for the packet"},{"line_number":277,"context_line":"rate. The data plane enforcement of the new policy is out of scope. When the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"afe4952d_a6fa1f36","line":274,"in_reply_to":"282e637d_2db68b0f","updated":"2021-05-21 11:14:59.000000000","message":"Discoverability is a big thing but we said we\u0027re not gonna address it in this spec.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":338,"context_line":"``TBD:`` In Nova a new microversion can be provided to signal the support of"},{"line_number":339,"context_line":"the new Neutron API extension. However the Nova REST API is not structurally"},{"line_number":340,"context_line":"impacted. If such microversion is required then requests with old microversion"},{"line_number":341,"context_line":"needs to be rejected if a the new Neutron API extension is enabled."},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":344,"context_line":"implemented in the current release cycle then those operations will be rejected"}],"source_content_type":"text/x-rst","patch_set":7,"id":"da1094e4_e091dc37","line":341,"updated":"2021-05-11 16:21:48.000000000","message":"this looks to me an implementation detail.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":338,"context_line":"``TBD:`` In Nova a new microversion can be provided to signal the support of"},{"line_number":339,"context_line":"the new Neutron API extension. However the Nova REST API is not structurally"},{"line_number":340,"context_line":"impacted. If such microversion is required then requests with old microversion"},{"line_number":341,"context_line":"needs to be rejected if a the new Neutron API extension is enabled."},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":344,"context_line":"implemented in the current release cycle then those operations will be rejected"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7f32d3d1_d9c4c7a3","line":341,"in_reply_to":"99e87c98_d4b0de3d","updated":"2021-05-21 14:11:18.000000000","message":"Thanks. I added the IRC log as a reference.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ef4e1e95ac790ac9f21efe9e492c672ffdcb65","unresolved":true,"context_lines":[{"line_number":338,"context_line":"``TBD:`` In Nova a new microversion can be provided to signal the support of"},{"line_number":339,"context_line":"the new Neutron API extension. However the Nova REST API is not structurally"},{"line_number":340,"context_line":"impacted. If such microversion is required then requests with old microversion"},{"line_number":341,"context_line":"needs to be rejected if a the new Neutron API extension is enabled."},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":344,"context_line":"implemented in the current release cycle then those operations will be rejected"}],"source_content_type":"text/x-rst","patch_set":7,"id":"99e87c98_d4b0de3d","line":341,"in_reply_to":"c87ee7b1_4ad70b94","updated":"2021-05-21 11:14:59.000000000","message":"Discussed in http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2021-05-21.log.html#t2021-05-21T10:51:46\n\nWe said we ain\u0027t gonna need it.\nIf other people disagree, please shout.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":true,"context_lines":[{"line_number":338,"context_line":"``TBD:`` In Nova a new microversion can be provided to signal the support of"},{"line_number":339,"context_line":"the new Neutron API extension. However the Nova REST API is not structurally"},{"line_number":340,"context_line":"impacted. If such microversion is required then requests with old microversion"},{"line_number":341,"context_line":"needs to be rejected if a the new Neutron API extension is enabled."},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":344,"context_line":"implemented in the current release cycle then those operations will be rejected"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c87ee7b1_4ad70b94","line":341,"in_reply_to":"da1094e4_e091dc37","updated":"2021-05-13 15:24:55.000000000","message":"I think first we need to agree. Do we need nova API microversion for this change?","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f6adb9ed3534aec38bd35b04e8fad16d505ed1a5","unresolved":true,"context_lines":[{"line_number":365,"context_line":"server lifecycle operations to detect which format of the ``resource_request``"},{"line_number":366,"context_line":"is used by Neutron and what format the ``binding:profile.allocation`` is"},{"line_number":367,"context_line":"expected by Neutron. This is temporary to support an upgrade scenario where"},{"line_number":368,"context_line":"Nova is already upgraded to Xena but Neutron doesn\u0027t. In Y release we can"},{"line_number":369,"context_line":"remove the extra call and assume that Neutron always returns the new format."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"a3c9d324_2c15d645","line":368,"range":{"start_line":368,"start_character":45,"end_line":368,"end_character":50},"updated":"2021-05-19 16:56:58.000000000","message":"isn\u0027t","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cd947de998e760fa34b32930823c7ed943967705","unresolved":false,"context_lines":[{"line_number":365,"context_line":"server lifecycle operations to detect which format of the ``resource_request``"},{"line_number":366,"context_line":"is used by Neutron and what format the ``binding:profile.allocation`` is"},{"line_number":367,"context_line":"expected by Neutron. This is temporary to support an upgrade scenario where"},{"line_number":368,"context_line":"Nova is already upgraded to Xena but Neutron doesn\u0027t. In Y release we can"},{"line_number":369,"context_line":"remove the extra call and assume that Neutron always returns the new format."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"bad366ed_51408e8d","line":368,"range":{"start_line":368,"start_character":45,"end_line":368,"end_character":50},"in_reply_to":"a3c9d324_2c15d645","updated":"2021-05-21 14:11:18.000000000","message":"Done","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c40a82e8d71298965ae203f4bb0119b069ed4f5d","unresolved":true,"context_lines":[{"line_number":399,"context_line":""},{"line_number":400,"context_line":"In the other hand Xena Nova needs to understand both the old Neutron API if"},{"line_number":401,"context_line":"Neutron is still on Wallaby level, and the new API if Neutron is also upgraded"},{"line_number":402,"context_line":"to Xena."},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":405,"context_line":"after Xena, the Neutron API extension can be made mandatory in Neutron. Then"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bbd51930_f3d87be5","line":402,"updated":"2021-05-11 16:21:48.000000000","message":"YUUUUP.","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ba2ec497e24f92135b26137fbf510e7d455c2cc9","unresolved":false,"context_lines":[{"line_number":399,"context_line":""},{"line_number":400,"context_line":"In the other hand Xena Nova needs to understand both the old Neutron API if"},{"line_number":401,"context_line":"Neutron is still on Wallaby level, and the new API if Neutron is also upgraded"},{"line_number":402,"context_line":"to Xena."},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":405,"context_line":"after Xena, the Neutron API extension can be made mandatory in Neutron. Then"}],"source_content_type":"text/x-rst","patch_set":7,"id":"05f3d91e_3d6af7f0","line":402,"in_reply_to":"bbd51930_f3d87be5","updated":"2021-05-13 15:24:55.000000000","message":"Ack","commit_id":"c36e025b8edc296a4416df571988836cf24cca2d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c20221a18f633994951266164dac2c031c5c06d1","unresolved":false,"context_lines":[{"line_number":69,"context_line":"   queues are handled by the same hardware resources. This is the case in the"},{"line_number":70,"context_line":"   non-hardware-offloaded OVS deployments. In this scenario OVS represents a"},{"line_number":71,"context_line":"   single packet processing resource pool. Which can be represented with a"},{"line_number":72,"context_line":"   single new resource class, ``NET_PACKET_RATE_KILOPACKET_PER_SEC``."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"2) The packet processing functionality is implemented in a specialized hardware"},{"line_number":75,"context_line":"   where the ingress and egress queues are processed by independent"}],"source_content_type":"text/x-rst","patch_set":8,"id":"98e7f708_f8299570","line":72,"updated":"2021-05-25 16:57:25.000000000","message":"++","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"be29596a299fa8e56a5eba8ffede072b827d74cc","unresolved":true,"context_lines":[{"line_number":98,"context_line":"which is true today. We think this assumption is strong one. If later on two"},{"line_number":99,"context_line":"vswitches are needed on the same compute host then we think it is easier to"},{"line_number":100,"context_line":"duplicate the agents handling them separately than enhancing the current agent"},{"line_number":101,"context_line":"to handle two switches."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"*Alternatively* it was suggested to define the packet processing inventory"},{"line_number":104,"context_line":"on the OVS bridge level. The big advantage of having the pps resource"}],"source_content_type":"text/x-rst","patch_set":8,"id":"0261c593_c4e073f5","line":101,"updated":"2021-05-25 09:33:00.000000000","message":"++","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"be29596a299fa8e56a5eba8ffede072b827d74cc","unresolved":true,"context_lines":[{"line_number":143,"context_line":"Placement with the resource provider hierarchy. Logically it is not different"},{"line_number":144,"context_line":"from that we rename today\u0027s OVS Agent RP to br-int RP. However `we agreed`_"},{"line_number":145,"context_line":"that keep this as a future exercise if and when more OVS instances would be"},{"line_number":146,"context_line":"needed per OVS agent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":".. _we agreed: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2021-05-21.log.html#t2021-05-21T10:33:22"},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"13fd682e_7622005e","line":146,"updated":"2021-05-25 09:33:00.000000000","message":"and personnally, I think we should never tell about some Neutron internal name like br-int.\nFor Nova, we only know that we have a neutron agent that uses a switch using a bridge for all the internal ports (for all the internal instances) and another one for the external ports.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":143,"context_line":"Placement with the resource provider hierarchy. Logically it is not different"},{"line_number":144,"context_line":"from that we rename today\u0027s OVS Agent RP to br-int RP. However `we agreed`_"},{"line_number":145,"context_line":"that keep this as a future exercise if and when more OVS instances would be"},{"line_number":146,"context_line":"needed per OVS agent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":".. _we agreed: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2021-05-21.log.html#t2021-05-21T10:33:22"},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"98f6b8d4_d7c5a00c","line":146,"in_reply_to":"13fd682e_7622005e","updated":"2021-05-26 14:20:20.000000000","message":"well br-int is the default name in the config and its name is passed to use in the ml2 port binding driver.\n\ni consider it as standard terminology in the same way that OVS is standard termonlgy for Open vSwitch.  br-int is just short hand for the integration bridge.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":158,"context_line":""},{"line_number":159,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"},{"line_number":160,"context_line":"  server via the agent hearth beat."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":163,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":164,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."}],"source_content_type":"text/x-rst","patch_set":8,"id":"6c635eb8_0ff7fa32","line":161,"updated":"2021-05-26 14:20:20.000000000","message":"out of scope of this spec there is existing presedent for odl and ovn to use a psuedo agent report to similar report per host information reusing this same mechnaium. so while ovn is out of scope this should be possibel to use for it also.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":false,"context_lines":[{"line_number":158,"context_line":""},{"line_number":159,"context_line":"* Neutron agent needs to communicate the configured capacity to the Neutron"},{"line_number":160,"context_line":"  server via the agent hearth beat."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"* Neutron server needs to report ``NET_PACKET_RATE_KILOPACKET_PER_SEC`` or"},{"line_number":163,"context_line":"  ``NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC`` resource inventory on the"},{"line_number":164,"context_line":"  ``Open vSwitch agent`` resource provider to Placement."}],"source_content_type":"text/x-rst","patch_set":8,"id":"a4370113_afcf5bcd","line":161,"in_reply_to":"6c635eb8_0ff7fa32","updated":"2021-05-26 15:53:40.000000000","message":"Ack","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":229,"context_line":"            },"},{"line_number":230,"context_line":"            {"},{"line_number":231,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":232,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":233,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":234,"context_line":"                \"resources\":"},{"line_number":235,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":8,"id":"348dac40_763ba49c","line":232,"range":{"start_line":232,"start_character":17,"end_line":232,"end_character":25},"updated":"2021-05-26 14:20:20.000000000","message":"nit we can trivaly extned this later but it might be nice too also supprot a forbiden trait list too.\n\nwe dont need that today but for sysmetry if we are makeing this exteion to the format it might be nice to future proof","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":true,"context_lines":[{"line_number":229,"context_line":"            },"},{"line_number":230,"context_line":"            {"},{"line_number":231,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":232,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":233,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":234,"context_line":"                \"resources\":"},{"line_number":235,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":8,"id":"af6750ab_3fcdbd14","line":232,"range":{"start_line":232,"start_character":17,"end_line":232,"end_character":25},"in_reply_to":"348dac40_763ba49c","updated":"2021-05-26 15:53:40.000000000","message":"Placement API only has the required key, and it uses ! in front of trait names to forbid them. So I guess supporting forbidden traits does not require a format change here.\n\nBut what about member_of or root_required ? I can imagine they could be useful in the future.\n\nAnyhow this is where YANGI can be applied again. We don\u0027t know when to use it so we might never will.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"406c53b33fb7c1e140e5370e87e534005b0cd110","unresolved":true,"context_lines":[{"line_number":229,"context_line":"            },"},{"line_number":230,"context_line":"            {"},{"line_number":231,"context_line":"                \"id\": \u003csome unique identifier string of the group\u003e"},{"line_number":232,"context_line":"                \"required\": [\u003cCUSTOM_PHYSNET_ traits\u003e,"},{"line_number":233,"context_line":"                             \u003cCUSTOM_VNIC_TYPE traits\u003e],"},{"line_number":234,"context_line":"                \"resources\":"},{"line_number":235,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":8,"id":"0cacf310_335be939","line":232,"range":{"start_line":232,"start_character":17,"end_line":232,"end_character":25},"in_reply_to":"af6750ab_3fcdbd14","updated":"2021-05-26 16:02:45.000000000","message":"ah right.\n\ni forgot we did !\u003ctrait\u003e in required in teh query string.\n\nok lets keep it to just what we need","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":244,"context_line":"            \u003cid of the second group from above\u003e"},{"line_number":245,"context_line":"        ]"},{"line_number":246,"context_line":"    }"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"For the reasoning why we need this format see the `Neutron specification`_"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"The Neutron port binding API needs to be extended. Today the ``allocation``"}],"source_content_type":"text/x-rst","patch_set":8,"id":"94d82095_d9b7e7e8","line":247,"updated":"2021-05-26 14:20:20.000000000","message":"+1","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":317,"context_line":"``requester_id`` field. However the parts of nova that drives the PCI claim"},{"line_number":318,"context_line":"based on the already allocated bandwidth assumes that the"},{"line_number":319,"context_line":"``InstancePCIRequest.requester_id`` is the same ``port_id`` as the"},{"line_number":320,"context_line":"``RequestGroup.requester_id``. To facilitate distinction between different"},{"line_number":321,"context_line":"groups requested by the same port this assumption needs to be removed. This"},{"line_number":322,"context_line":"needs a new field ``group_id`` in the RequestGroup object that stores the"},{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"}],"source_content_type":"text/x-rst","patch_set":8,"id":"874c841a_2a725732","line":321,"range":{"start_line":320,"start_character":31,"end_line":321,"end_character":70},"updated":"2021-05-26 14:20:20.000000000","message":"we need to do this carfully as we want to use the saem requester id to fix \nhttps://bugs.launchpad.net/nova/+bug/1851545\nhttps://review.opendev.org/c/openstack/nova/+/784168\nso we should not regress that","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":false,"context_lines":[{"line_number":317,"context_line":"``requester_id`` field. However the parts of nova that drives the PCI claim"},{"line_number":318,"context_line":"based on the already allocated bandwidth assumes that the"},{"line_number":319,"context_line":"``InstancePCIRequest.requester_id`` is the same ``port_id`` as the"},{"line_number":320,"context_line":"``RequestGroup.requester_id``. To facilitate distinction between different"},{"line_number":321,"context_line":"groups requested by the same port this assumption needs to be removed. This"},{"line_number":322,"context_line":"needs a new field ``group_id`` in the RequestGroup object that stores the"},{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"}],"source_content_type":"text/x-rst","patch_set":8,"id":"a961b067_e0312970","line":321,"range":{"start_line":320,"start_character":31,"end_line":321,"end_character":70},"in_reply_to":"874c841a_2a725732","updated":"2021-05-26 15:53:40.000000000","message":"Ack","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":320,"context_line":"``RequestGroup.requester_id``. To facilitate distinction between different"},{"line_number":321,"context_line":"groups requested by the same port this assumption needs to be removed. This"},{"line_number":322,"context_line":"needs a new field ``group_id`` in the RequestGroup object that stores the"},{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"},{"line_number":325,"context_line":"changed to use the group with the bandwidth resource to drive the PCI claim."},{"line_number":326,"context_line":"This creates an unfortunate dependency between the Nova code and the content"},{"line_number":327,"context_line":"of the ``resource_request``. We can remove this dependency one we start"}],"source_content_type":"text/x-rst","patch_set":8,"id":"49da4f19_550e2b85","line":324,"range":{"start_line":323,"start_character":42,"end_line":324,"end_character":31},"updated":"2021-05-26 14:20:20.000000000","message":"ack that will work :)","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":false,"context_lines":[{"line_number":320,"context_line":"``RequestGroup.requester_id``. To facilitate distinction between different"},{"line_number":321,"context_line":"groups requested by the same port this assumption needs to be removed. This"},{"line_number":322,"context_line":"needs a new field ``group_id`` in the RequestGroup object that stores the"},{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"},{"line_number":325,"context_line":"changed to use the group with the bandwidth resource to drive the PCI claim."},{"line_number":326,"context_line":"This creates an unfortunate dependency between the Nova code and the content"},{"line_number":327,"context_line":"of the ``resource_request``. We can remove this dependency one we start"}],"source_content_type":"text/x-rst","patch_set":8,"id":"2a9d0702_c32ee696","line":324,"range":{"start_line":323,"start_character":42,"end_line":324,"end_character":31},"in_reply_to":"49da4f19_550e2b85","updated":"2021-05-26 15:53:40.000000000","message":"yepp I did not want to go in and change the meaning of the already used field.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"},{"line_number":325,"context_line":"changed to use the group with the bandwidth resource to drive the PCI claim."},{"line_number":326,"context_line":"This creates an unfortunate dependency between the Nova code and the content"},{"line_number":327,"context_line":"of the ``resource_request``. We can remove this dependency one we start"},{"line_number":328,"context_line":"modeling PCI devices in Placement."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The RequestLevelParams object also needs to be extended to store a list of"},{"line_number":331,"context_line":"``same_subtree`` requests coming from the ``same_subtree`` field of the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"866e0628_455c4114","line":328,"range":{"start_line":326,"start_character":1,"end_line":328,"end_character":34},"updated":"2021-05-26 14:20:20.000000000","message":"this will be futrer complicated by modeling pci device in placment.\nonce we do that we will need to first ensure that we only look at device that mach the parent device with the VF allocation and then consider the the bandwith constraints.\n\ni think we can adress that in a followup when we agree on the desing of modeling pci devices in placment. note this might actully be simplifed if neutron incldued a resouce request for PF/VF RCs but that makes supporting pci device in placment more difficult so i wanted to avoid that initally.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":true,"context_lines":[{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"},{"line_number":325,"context_line":"changed to use the group with the bandwidth resource to drive the PCI claim."},{"line_number":326,"context_line":"This creates an unfortunate dependency between the Nova code and the content"},{"line_number":327,"context_line":"of the ``resource_request``. We can remove this dependency one we start"},{"line_number":328,"context_line":"modeling PCI devices in Placement."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The RequestLevelParams object also needs to be extended to store a list of"},{"line_number":331,"context_line":"``same_subtree`` requests coming from the ``same_subtree`` field of the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9131463a_c9ee0607","line":328,"range":{"start_line":326,"start_character":1,"end_line":328,"end_character":34},"in_reply_to":"866e0628_455c4114","updated":"2021-05-26 15:53:40.000000000","message":"Yes, I agree. I think we already in complicated situation with the need to correlate PCI in placement and in the resource tracker. So this step in pps is just cherry on top. I agree that the solution is to have neutron request VF RC in the resource_request in a \"good way\"(tm). But to what is the good way that depends on how we connect nova PCI RPs and netron PCI RPs in placement. So I suggest to continue this discussion in that placement PCI modelling spec.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"406c53b33fb7c1e140e5370e87e534005b0cd110","unresolved":false,"context_lines":[{"line_number":323,"context_line":"group id from the ``requested_resources`` while we keep the ``requester_id``"},{"line_number":324,"context_line":"to be the ``port_id`` as today. The PCI request update logic needs to be"},{"line_number":325,"context_line":"changed to use the group with the bandwidth resource to drive the PCI claim."},{"line_number":326,"context_line":"This creates an unfortunate dependency between the Nova code and the content"},{"line_number":327,"context_line":"of the ``resource_request``. We can remove this dependency one we start"},{"line_number":328,"context_line":"modeling PCI devices in Placement."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The RequestLevelParams object also needs to be extended to store a list of"},{"line_number":331,"context_line":"``same_subtree`` requests coming from the ``same_subtree`` field of the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"a313b366_95969ecb","line":328,"range":{"start_line":326,"start_character":1,"end_line":328,"end_character":34},"in_reply_to":"9131463a_c9ee0607","updated":"2021-05-26 16:02:45.000000000","message":"Ack","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"3093d2a92996b0ca8bd19446c699ab80d460645b","unresolved":true,"context_lines":[{"line_number":354,"context_line":"consume the new Neutron API extension. A Nova microversion alone could not"},{"line_number":355,"context_line":"signal the availability of the feature to the end user as with Wallaby Neutron"},{"line_number":356,"context_line":"and Xena Nova, even with latest Nova microversion, this feature will not be"},{"line_number":357,"context_line":"available. Therefore now microversion bump will be added. What we suggest"},{"line_number":358,"context_line":"instead is that the end users decide on feature availability based on what QoS"},{"line_number":359,"context_line":"policies the admin created for them. If QoS policies with the new minimum"},{"line_number":360,"context_line":"guaranteed QoS policy rule is available to the end users then they can be sure"}],"source_content_type":"text/x-rst","patch_set":8,"id":"2b8f4041_9cb04a6b","line":357,"range":{"start_line":357,"start_character":21,"end_line":357,"end_character":24},"updated":"2021-05-25 10:34:42.000000000","message":"no","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"be29596a299fa8e56a5eba8ffede072b827d74cc","unresolved":true,"context_lines":[{"line_number":360,"context_line":"guaranteed QoS policy rule is available to the end users then they can be sure"},{"line_number":361,"context_line":"that the feature is available. See the `IRC log`_ for further discussion."},{"line_number":362,"context_line":""},{"line_number":363,"context_line":".. _IRC log: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2021-05-21.log.html#t2021-05-21T10:51:46"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":366,"context_line":"implemented in the current release cycle then those operations will be rejected"}],"source_content_type":"text/x-rst","patch_set":8,"id":"6c3a4386_fa62d2d1","line":363,"updated":"2021-05-25 09:33:00.000000000","message":"Fair enough.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":365,"context_line":"If, due to scoping, support for some of the lifecycle operations is not"},{"line_number":366,"context_line":"implemented in the current release cycle then those operations will be rejected"},{"line_number":367,"context_line":"with HTTP 400."},{"line_number":368,"context_line":""},{"line_number":369,"context_line":""},{"line_number":370,"context_line":"Security impact"},{"line_number":371,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"502a163f_268951ed","line":368,"updated":"2021-05-26 14:20:20.000000000","message":"ack","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":389,"context_line":"expected by Neutron. This is temporary to support an upgrade scenario where"},{"line_number":390,"context_line":"Nova is already upgraded to Xena but Neutron isn\u0027t. In Y release we can"},{"line_number":391,"context_line":"remove the extra call and assume that Neutron always returns the new format."},{"line_number":392,"context_line":""},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"Other deployer impact"},{"line_number":395,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"0fa3b7ca_cb9e6421","line":392,"updated":"2021-05-26 14:20:20.000000000","message":"given we cache the extention list in nova i would hope that the new calls will have little impact but still good to note +1","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":true,"context_lines":[{"line_number":389,"context_line":"expected by Neutron. This is temporary to support an upgrade scenario where"},{"line_number":390,"context_line":"Nova is already upgraded to Xena but Neutron isn\u0027t. In Y release we can"},{"line_number":391,"context_line":"remove the extra call and assume that Neutron always returns the new format."},{"line_number":392,"context_line":""},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"Other deployer impact"},{"line_number":395,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f6a92b8f_b90a0c72","line":392,"in_reply_to":"0fa3b7ca_cb9e6421","updated":"2021-05-26 15:53:40.000000000","message":"Today we don\u0027t have a cache as far as I see, but if it turns out to be a problem then I can add one.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"406c53b33fb7c1e140e5370e87e534005b0cd110","unresolved":true,"context_lines":[{"line_number":389,"context_line":"expected by Neutron. This is temporary to support an upgrade scenario where"},{"line_number":390,"context_line":"Nova is already upgraded to Xena but Neutron isn\u0027t. In Y release we can"},{"line_number":391,"context_line":"remove the extra call and assume that Neutron always returns the new format."},{"line_number":392,"context_line":""},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"Other deployer impact"},{"line_number":395,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"cf770021_2ea0bef4","line":392,"in_reply_to":"f6a92b8f_b90a0c72","updated":"2021-05-26 16:02:45.000000000","message":"we do \nhttps://github.com/openstack/nova/blob/b0cd985f0c09088098f74cc0cb1df616cc0ef12b/nova/network/neutron.py#L1271-L1283\n\nhttps://github.com/openstack/nova/blob/b0cd985f0c09088098f74cc0cb1df616cc0ef12b/nova/network/neutron.py#L1236-L1247","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":424,"context_line":"to Xena."},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":427,"context_line":"after Xena, the Neutron API extension can be made mandatory in Neutron. Then"},{"line_number":428,"context_line":"the support for the old format of the ``resource_request`` field can be dropped"},{"line_number":429,"context_line":"from Nova."},{"line_number":430,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"bcd7dec9_19e03338","line":427,"range":{"start_line":427,"start_character":12,"end_line":427,"end_character":72},"updated":"2021-05-26 14:20:20.000000000","message":"nit: technially there is no formal porcess to do this in neutron today.\n\ni agree there should be one and we shoudl make this mandatory as we shoudl with \"port bridning extended\"  but just a note that we need to actully add a way to make exnetiosn required in neutron and use it before we can make this mandtory so we might need to keep support for both for an extended period of time.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":true,"context_lines":[{"line_number":424,"context_line":"to Xena."},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":427,"context_line":"after Xena, the Neutron API extension can be made mandatory in Neutron. Then"},{"line_number":428,"context_line":"the support for the old format of the ``resource_request`` field can be dropped"},{"line_number":429,"context_line":"from Nova."},{"line_number":430,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"e42f90f6_5e39eaaf","line":427,"range":{"start_line":427,"start_character":12,"end_line":427,"end_character":72},"in_reply_to":"bcd7dec9_19e03338","updated":"2021-05-26 15:53:40.000000000","message":"My aim here is to make this mandatory over the old port-resource-request extension. So the deployer can still choose to use the new resource extension or not. But she cannot use the old resource extension. So that nova can drop the support for the old format.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"406c53b33fb7c1e140e5370e87e534005b0cd110","unresolved":true,"context_lines":[{"line_number":424,"context_line":"to Xena."},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"After Nova gained full support for the new Neutron API extension, potentially"},{"line_number":427,"context_line":"after Xena, the Neutron API extension can be made mandatory in Neutron. Then"},{"line_number":428,"context_line":"the support for the old format of the ``resource_request`` field can be dropped"},{"line_number":429,"context_line":"from Nova."},{"line_number":430,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"483f0734_28fb89dc","line":427,"range":{"start_line":427,"start_character":12,"end_line":427,"end_character":72},"in_reply_to":"e42f90f6_5e39eaaf","updated":"2021-05-26 16:02:45.000000000","message":"yep i understand but we cannot actully do that today.\n\nthat was or intention with port-bindigns and port-bidnings-exteneded too but we still need to support both today becasue neutron does not ahve a way to make an extention required.\n\nsince the still allow plugins to replace teh core ml2 code and support monolitic plugings and there is no agrred way to make exteniosn mandataoy nova cannot drop support without dropping support for neutron backends.\n\ni think we should use this as a forcing fucntion to intoduce a way to make neutorn extnetion part of teh core api or mandatory.","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"18ff3e099653e3bf816c029547843ed842960207","unresolved":true,"context_lines":[{"line_number":451,"context_line":"  As we add support for each operation the rejection is removed from the given"},{"line_number":452,"context_line":"  operation. This way whenever we hit feature freeze we will have a consistent"},{"line_number":453,"context_line":"  system that rejects what is not supported."},{"line_number":454,"context_line":""},{"line_number":455,"context_line":"* Propose the new resource classes to Placement\u0027s os-resource-classes library"},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"* Enhance the ``resource_request`` parsing logic to support the new format"}],"source_content_type":"text/x-rst","patch_set":8,"id":"0c90096d_ec6623e5","line":454,"updated":"2021-05-26 14:20:20.000000000","message":"+1 we have started to do this more often so we might want to document this pattern somewhere going forward.\n\nperhaps inthe spec template?","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dbb69378b64ba4c8655bcbd0a615da672977083e","unresolved":true,"context_lines":[{"line_number":451,"context_line":"  As we add support for each operation the rejection is removed from the given"},{"line_number":452,"context_line":"  operation. This way whenever we hit feature freeze we will have a consistent"},{"line_number":453,"context_line":"  system that rejects what is not supported."},{"line_number":454,"context_line":""},{"line_number":455,"context_line":"* Propose the new resource classes to Placement\u0027s os-resource-classes library"},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"* Enhance the ``resource_request`` parsing logic to support the new format"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f785291d_e607c5aa","line":454,"in_reply_to":"0c90096d_ec6623e5","updated":"2021-05-26 15:53:40.000000000","message":"pushed a change on the template https://review.opendev.org/c/openstack/nova-specs/+/793197","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"406c53b33fb7c1e140e5370e87e534005b0cd110","unresolved":false,"context_lines":[{"line_number":451,"context_line":"  As we add support for each operation the rejection is removed from the given"},{"line_number":452,"context_line":"  operation. This way whenever we hit feature freeze we will have a consistent"},{"line_number":453,"context_line":"  system that rejects what is not supported."},{"line_number":454,"context_line":""},{"line_number":455,"context_line":"* Propose the new resource classes to Placement\u0027s os-resource-classes library"},{"line_number":456,"context_line":""},{"line_number":457,"context_line":"* Enhance the ``resource_request`` parsing logic to support the new format"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f04814c3_1b936c30","line":454,"in_reply_to":"f785291d_e607c5aa","updated":"2021-05-26 16:02:45.000000000","message":"Ack, thanks","commit_id":"51f1d0556cdacf66343855e891b8b574c988c083"}]}