594 lines
27 KiB
Plaintext
594 lines
27 KiB
Plaintext
{
|
|
"comments": [
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "0dde6674_d2eb3a63",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "the folder shoud use the release name not the number by the way.\nin this case Antelope",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "5adbb492_bcc9a4c7",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 35239
|
|
},
|
|
"writtenOn": "2022-09-02T12:23:57Z",
|
|
"side": 1,
|
|
"message": "I\u0027m just using the folder that was given by sean-k-mooney",
|
|
"parentUuid": "0dde6674_d2eb3a63",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "afc45c21_673919dd",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 9,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "add support for multiqueue with hardware offloaded ovs.\n\n^ that seams to be your main usecase.",
|
|
"range": {
|
|
"startLine": 9,
|
|
"startChar": 0,
|
|
"endLine": 9,
|
|
"endChar": 52
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "5dc284ff_aa491039",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 23,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "multi queue is not officaly supproted with hardware offloads today.",
|
|
"range": {
|
|
"startLine": 23,
|
|
"startChar": 30,
|
|
"endLine": 23,
|
|
"endChar": 48
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "eeb37df1_7b00f3d3",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 35,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "not that unles these option are exposed in libvirt we cannot enable them in nova\n\nwe do not mangage qemu directly we use libvirt as an abstraction and the qemu command elements are not allowed to be used in nova.\n\nyou shoudl rewrite this in terms of the libvirt xml snipits.\n\npacked appear to be aviable as of 6.3.0\nquese is aviable for much longer.\nhttps://libvirt.org/formatdomain.html#virtio-related-options\n\nnot that nova does not allow the amount of resouce to vary based on teh host a server lands on and sinc ethe end user wont knwo",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e588d57a_836737d2",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 38,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "to acive this level or per port confugraiton would require the policy to be expres on a per port basie to enabel mutliqueu and or packing.\n\nthat will require a new neutron extension. more on this later.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "0e69e6a8_1c8b5479",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 47,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "that is something we currently do not want to supprot.\nat this time we do not want to mange VF with differnt configuration per VF\n\nwe discussed this as par to the pci device in placment spec\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html#pci-device-spec-configuration\n\n\"\"\"\nAs detailed in the Modeling PCI devices in Placement section, each physical device (PF) will be its own resource provider with inventories of the relevant PF and VF resource classes. As such traits cannot vary per VF device under the same parent PF. If VFs are individually matched by different device_spec entries, then defining different traits for different VFs under the same PF is a configuration error and will be rejected.\n\nWhile it would possible to support defining different resource_class names for different VFs under the same parent PF, this is considered bad practice and unnecessary complexity. Such configuration will be rejected.\n\"\"\"\n\nwhile we coudl simple support VFs from differnt PFs having differnt numbers fo queus in this model we do not want to have each VF tracked as a sperate resouce provider or pci pool.\n\nits possible we could group vf with the same atributes (number of queues) to minimise the number of RPs that are created.\n\nand then model the number of queues soemhow.\n\notherwise we would have ot split each VF into its own resouce provder which while possible is more complex then we likely need.\n\nwe will have to consider this two specs together carful to make sure this works properly.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "eb405523_febce80b",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 47,
|
|
"author": {
|
|
"id": 9708
|
|
},
|
|
"writtenOn": "2022-09-02T11:28:22Z",
|
|
"side": 1,
|
|
"message": "\u003e its possible we could group vf with the same atributes (number of queues) to minimise the number of RPs that are created.\n\u003e \n\u003e and then model the number of queues soemhow.\n\u003e \n\u003e otherwise we would have ot split each VF into its own resouce provder which while possible is more complex then we likely need.\n\u003e \n\u003e we will have to consider this two specs together carful to make sure this works properly.\n\nCurrently nova uses the parent_addr of VFs to structure them. If we need a different (more fine grained) grouping then we need a different key for that grouping. What would be that key?\n\n\u003e Each of the VFs exported by the SmartNIC might have different number of hardware queues configured.\n\n* How common to have different capabilities per VF from the same SmartNIC? \n* Who creates / configures these VFs and when?\n* Is it only the number of queues that can be different or there are other capabilities to consider?\n* Does libvirt exposes these VF capabilities today so that nova can detect them?",
|
|
"parentUuid": "0e69e6a8_1c8b5479",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "ff2e3542_56d5c000",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 47,
|
|
"author": {
|
|
"id": 35239
|
|
},
|
|
"writtenOn": "2022-09-02T12:23:57Z",
|
|
"side": 1,
|
|
"message": "\u003e \u003e Each of the VFs exported by the SmartNIC might have different number of hardware queues configured.\n\u003e \n\u003e * How common to have different capabilities per VF from the same SmartNIC?\n\nIt all depends on what the operator requires. When using Napatech SmartNICs, each device comes with X number of queues, that can be divided freely among the max VFs supported. Going multi-queue on some VFs reduces the total number of VFs possible.\n \n\u003e * Who creates / configures these VFs and when?\n\nTypically done at the server boot time by the operator. Dynamic reconfiguration is not possible.\n\n\u003e * Is it only the number of queues that can be different or there are other capabilities to consider?\n\nAs far as I\u0027m aware - yes. Furthermore, VFs with the same number of queues are interchangeable. So we can have statically configured pools called \"1q-VF\", \"2q-VF\", \"4q-VF\" and use that to select VFs.",
|
|
"parentUuid": "eb405523_febce80b",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "ac6960eb_592a1033",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 47,
|
|
"author": {
|
|
"id": 9708
|
|
},
|
|
"writtenOn": "2022-11-15T09:43:03Z",
|
|
"side": 1,
|
|
"message": "Thanks for the answers. This all points to the direction of the need to model VFs (or at least pools of VFs) from the same PF individually. To be able to do that the following prerequisite steps are needed:\n1) come up with a placement model that supports this as part of PCI in Placement[1] work. I suggest to look try to model this first as one pool of VFs per placement ResourceProvider. Feel free to describe the modeling proposal of this in the current spec for now. We can discuss it here and I will make sure it is aligned in the work in [1].\n2) finish the work described in [1]. We have patches[3], we just need to land them. So this is probably happen in Antelope independently of this multiqueue discussion.\n3) solve the too many placement allocation_candidate issue [2] as the VF pooling will further increase the number of possible candidates. This is something that can be worked on right now. I don\u0027t have the time to push this in Antelope. But we have ideas how to solve it described in [5] (starting around L290).\n4) Propose the next spec for the neutron port base SRIOV in placement. We have some ideas how that will look like described in [4] but we need a full spec for that and probably a cycle (B?, C?) to implement it.\n\nI know that this is a lot of prereqs. But I would like to see a placement based solution to this instead of bolting on this feature to the current nova PCI tracker only.\n\n[1] https://specs.openstack.org/openstack/nova-specs/specs/2023.1/approved/pci-device-tracking-in-placement.html\n[2] https://review.opendev.org/c/openstack/nova/+/855885\n[3] https://review.opendev.org/q/topic:bp%252Fpci-device-tracking-in-placement\n[4] https://specs.openstack.org/openstack/nova-specs/specs/2023.1/approved/pci-device-tracking-in-placement.html#neutron-sr-iov-ports-out-of-scope\n[5] https://etherpad.opendev.org/p/nova-antelope-ptg",
|
|
"parentUuid": "ff2e3542_56d5c000",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "7892651b_51aa2b95",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 52,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "can we discover if packed virtio queue are supproted from the host pf today?\nis that reproted in libvirt currently or ethtool?\n\nif not we would need to mark the interface in the device_spec as supprot packed queues.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "a181bab3_054b2ec9",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 52,
|
|
"author": {
|
|
"id": 35239
|
|
},
|
|
"writtenOn": "2022-09-02T12:23:57Z",
|
|
"side": 1,
|
|
"message": "Libvirt has a datamodel support for the \"packed\" option, but I\u0027m not aware of a way to discover support from the PF.",
|
|
"parentUuid": "7892651b_51aa2b95",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "aed1c251_891834ae",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 78,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "no driver_vectors and driver_mq were intetionally not exposed when we implemeted this orginally.\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-virtiomq.html\n\nthis is still too low level to expose in our api and not somethign we shoudl do via a host level config option.\n\nnova can caluate and set those values parhaps based on some uer input but thos are not options that shoudl be exposed directly.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "282cd6d1_26017547",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 78,
|
|
"author": {
|
|
"id": 9708
|
|
},
|
|
"writtenOn": "2022-09-02T11:28:22Z",
|
|
"side": 1,
|
|
"message": "I agree. We need to create abstractions.",
|
|
"parentUuid": "aed1c251_891834ae",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "05de0f07_4d789b61",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 80,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "this is not renamed to device_spec",
|
|
"range": {
|
|
"startLine": 80,
|
|
"startChar": 47,
|
|
"endLine": 80,
|
|
"endChar": 68
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "20fdeb99_abe263bb",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 82,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "this is really something i think we shoudl be able to discover via libvirt or sysfs.\n\nit might be ok to model this as a tag on the device spec as a fallback but if we were to take this approch i would prefer to discover this automatically and recored it in the exta_info column with the other device capablitys and vpd info.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "38643268_20ccb6cb",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 82,
|
|
"author": {
|
|
"id": 9708
|
|
},
|
|
"writtenOn": "2022-09-02T11:28:22Z",
|
|
"side": 1,
|
|
"message": "I\u0027m also would like to see this coming from libvirt as this is a capability of the device.",
|
|
"parentUuid": "20fdeb99_abe263bb",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "05ab5526_a1f685a6",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 86,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "the binding profile is admin only and it inappropate to pas this type of configuration via it.\n\nyou woudl need a new neutron extention.\n\nyou shoudl not model your propsoable aroudn how trusted vf or hard ware offloaded ovs works today.",
|
|
"range": {
|
|
"startLine": 86,
|
|
"startChar": 34,
|
|
"endLine": 86,
|
|
"endChar": 61
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "38b4361c_39e11e57",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 86,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:11:26Z",
|
|
"side": 1,
|
|
"message": "by the way im -2 on this part specifically but left a -1 over all.",
|
|
"parentUuid": "05ab5526_a1f685a6",
|
|
"range": {
|
|
"startLine": 86,
|
|
"startChar": 34,
|
|
"endLine": 86,
|
|
"endChar": 61
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "f72e5a5b_4cd227b1",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 87,
|
|
"author": {
|
|
"id": 9708
|
|
},
|
|
"writtenOn": "2022-09-02T11:28:22Z",
|
|
"side": 1,
|
|
"message": "If a neutron port would like to require resources then I think we should consider communicating that via the port.resource_request to nova to avoid creating N+1 different code path to translate a neutron port to scheduling request.",
|
|
"range": {
|
|
"startLine": 87,
|
|
"startChar": 32,
|
|
"endLine": 87,
|
|
"endChar": 71
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "cde84e11_d15c0ae4",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 87,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:50:27Z",
|
|
"side": 1,
|
|
"message": "+1 \ni was debating is we woudl want to model queues as a consumable resouces.\n\n\nif we had a placment RP per VF we coudl also have and inventory or queues\non that vf RP\n\nwe could use the vf PCI addres as the rp name.\n\nbut im not sure we want to do that.\n\nthat would be the most flexible approach but we will have a lot more RPs then we have today and that could least to a explosion of allocation candidate permutations.\n\n\nwhich si why i woudl be nervous fo takign that approch.",
|
|
"parentUuid": "f72e5a5b_4cd227b1",
|
|
"range": {
|
|
"startLine": 87,
|
|
"startChar": 32,
|
|
"endLine": 87,
|
|
"endChar": 71
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "a170f2c9_4fe3e437",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 93,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "this would just be an extention to the the exsiting pci fileter or more specificaly the share pci code that is used by both the pci and numa toplogy filters.\n\nso this would not be a new filter.\n\nwe woudl also need to consider how to expose this to placment for schduling.\nadn if we do this in placement or in nova or a mix of both.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "78aecb26_144442f0",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 97,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "-1 we shoudl not primalrly do this via the image. in fact we likely shoudl not enable multi queu via the falvor/image as we do today but that beside the point.\n\nif we proceed with thsi we shoudl add a new extension to neutron that allwos you to enable multiqueue and packed per port.\n\n\nthat will enable use to request this as a user and open the operturing to translat this into traits request for scheduling.\n\nif we have the livbirt driver report compute capablity traits for multi queue supprot ad or packed rings we can use the request on the port to schedule to hsot with that capablity without requiring all operators to update all there flavors and images.\n\nsriov ports already requires the port to be created in neutron anyway.\nthis exetntion could also allow for the numbner of queuse to be sepcifced.",
|
|
"range": {
|
|
"startLine": 95,
|
|
"startChar": 0,
|
|
"endLine": 97,
|
|
"endChar": 49
|
|
},
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "09b0185e_cae82237",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 103,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "that not really an alternitive.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "74d02405_f9e9724c",
|
|
"filename": "specs/2023.1/approved/improve-nova-multiqueue-adapter-support.rst",
|
|
"patchSetId": 6
|
|
},
|
|
"lineNbr": 161,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2022-09-02T11:08:13Z",
|
|
"side": 1,
|
|
"message": "generaly the implemation shoudl not be started until afer the design is at least mostly agreed.\n\nit can help to do early pocs of a feature but in this case i expect much of what you have start to be altered significantly.",
|
|
"revId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
}
|
|
],
|
|
"submitRequirementResults": [
|
|
{
|
|
"submitRequirement": {
|
|
"name": "Code-Review",
|
|
"description": {
|
|
"value": "Code reviewed by core reviewer"
|
|
},
|
|
"applicabilityExpression": {},
|
|
"submittabilityExpression": {
|
|
"expressionString": "label:Code-Review\u003dMAX AND -label:Code-Review\u003dMIN"
|
|
},
|
|
"overrideExpression": {},
|
|
"allowOverrideInChildProjects": true
|
|
},
|
|
"applicabilityExpressionResult": {},
|
|
"submittabilityExpressionResult": {
|
|
"value": {"expression":{"expressionString":"label:Code-Review=MAX AND -label:Code-Review=MIN"},"status":"FAIL","errorMessage":{"value":null},"passingAtoms":[],"failingAtoms":["label:Code-Review=MAX","label:Code-Review=MIN"]}
|
|
},
|
|
"overrideExpressionResult": {},
|
|
"patchSetCommitId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"legacy": {
|
|
"value": false
|
|
},
|
|
"forced": {},
|
|
"hidden": {}
|
|
},
|
|
{
|
|
"submitRequirement": {
|
|
"name": "Review-Priority",
|
|
"description": {
|
|
"value": "Review Priority"
|
|
},
|
|
"applicabilityExpression": {
|
|
"value": {
|
|
"expressionString": "is:false"
|
|
}
|
|
},
|
|
"submittabilityExpression": {
|
|
"expressionString": "is:true"
|
|
},
|
|
"overrideExpression": {},
|
|
"allowOverrideInChildProjects": false
|
|
},
|
|
"applicabilityExpressionResult": {
|
|
"value": {"expression":{"expressionString":"is:false"},"status":"FAIL","errorMessage":{"value":null},"passingAtoms":[],"failingAtoms":["is:false"]}
|
|
},
|
|
"submittabilityExpressionResult": {
|
|
"value": {"expression":{"expressionString":"is:true"},"status":"NOT_EVALUATED","errorMessage":{"value":null},"passingAtoms":[],"failingAtoms":[]}
|
|
},
|
|
"overrideExpressionResult": {},
|
|
"patchSetCommitId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"legacy": {
|
|
"value": false
|
|
},
|
|
"forced": {},
|
|
"hidden": {}
|
|
},
|
|
{
|
|
"submitRequirement": {
|
|
"name": "Verified",
|
|
"description": {
|
|
"value": "Verified in gate by CI"
|
|
},
|
|
"applicabilityExpression": {},
|
|
"submittabilityExpression": {
|
|
"expressionString": "label:Verified\u003dMAX AND -label:Verified\u003dMIN"
|
|
},
|
|
"overrideExpression": {},
|
|
"allowOverrideInChildProjects": false
|
|
},
|
|
"applicabilityExpressionResult": {},
|
|
"submittabilityExpressionResult": {
|
|
"value": {"expression":{"expressionString":"label:Verified=MAX AND -label:Verified=MIN"},"status":"FAIL","errorMessage":{"value":null},"passingAtoms":[],"failingAtoms":["label:Verified=MAX","label:Verified=MIN"]}
|
|
},
|
|
"overrideExpressionResult": {},
|
|
"patchSetCommitId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"legacy": {
|
|
"value": false
|
|
},
|
|
"forced": {},
|
|
"hidden": {}
|
|
},
|
|
{
|
|
"submitRequirement": {
|
|
"name": "Workflow",
|
|
"description": {
|
|
"value": "Approved for gate by core reviewer"
|
|
},
|
|
"applicabilityExpression": {},
|
|
"submittabilityExpression": {
|
|
"expressionString": "label:Workflow\u003dMAX AND -label:Workflow\u003dMIN"
|
|
},
|
|
"overrideExpression": {},
|
|
"allowOverrideInChildProjects": false
|
|
},
|
|
"applicabilityExpressionResult": {},
|
|
"submittabilityExpressionResult": {
|
|
"value": {"expression":{"expressionString":"label:Workflow=MAX AND -label:Workflow=MIN"},"status":"FAIL","errorMessage":{"value":null},"passingAtoms":[],"failingAtoms":["label:Workflow=MAX","label:Workflow=MIN"]}
|
|
},
|
|
"overrideExpressionResult": {},
|
|
"patchSetCommitId": "909b5c405d9f1c43a7ca0f3156e14e0239379727",
|
|
"legacy": {
|
|
"value": false
|
|
},
|
|
"forced": {},
|
|
"hidden": {}
|
|
}
|
|
]
|
|
} |