Open Stack

hi
just following up form yesterday.
i just finished testing the pci numa policy feature
and i can confirm that the prefer policy which allow use of non
local pci devices does not work.

the test case was relitively simple
1 host with 2 numa nodes
1 pci device attach to numa node 0
and vcpu pin set configured to allow only numa node 1
in this case booting a vm with a passthrough alias and a passthrough alias fails.

[stack at cloud-3 devstack]$ openstack flavor show 42
+----------------------------+-----------------------------------------------------+
| Field                      | Value                                               |
+----------------------------+-----------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False                                               |
| OS-FLV-EXT-DATA:ephemeral  | 0                                                   |
| access_project_ids         | None                                                |
| disk                       | 0                                                   |
| id                         | 42                                                  |
| name                       | m1.nano                                             |
| os-flavor-access:is_public | True                                                |
| properties                 | hw:numa_nodes='1', pci_passthrough:alias='nic-pf:1' |
| ram                        | 64                                                  |
| rxtx_factor                | 1.0                                                 |
| swap                       |                                                     |
| vcpus                      | 1                                                   |
+----------------------------+-----------------------------------------------------+


passthrough_whitelist = { "address": "0000:01:00.1" }
alias = { "vendor_id":"8086", "product_id":"10c9", "device_type":"type-PF", "name":"nic-pf", "numa_policy": "preferred"}


removeing the  hw:numa_nodes='1' extra spec allow the vm to boot as it nolonger has a numa topology.

the vm passes scheduling in both casess but when the vm has a virtual numa toplogy of 1 node
we fail in the resocue tracker on the compute node when claiming resouces for the instance.

i will submit a bug for this and repose the spec next week to track closing this gap.


On Thu, 2018-11-22 at 03:20 +0000, Xu, Chenjie wrote:
> Hi Miguel,
> There is another RFE “Add l2pop support for floating IP resources” proposed to Launchpad. This RFE also comes from
> StarlingX and the link is below:
> https://bugs.launchpad.net/neutron/+bug/1803494
> Could you please help review this RFE? I think this RFE can be added to the gap analysis. What’s more, there is a bug
> and a RFE relating to l2pop and neutron-dynamic-routing is being written and is expected to be released next week.
>  
> Best Regards,
> Xu, Chenjie
>  
> From: Miguel Lavalle [mailto:miguel at mlavalle.com] 
> Sent: Thursday, November 22, 2018 2:12 AM
> To: openstack-discuss at lists.openstack.org; OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] StarlingX gap analysis to converge with OpenStack master
>  
> Hi Stackers,
>  
> One of the key goals of StarlingX during the current cycle is to converge with the OpenStack projects master branches.
> In order to accomplish this goal, the Technical Steering Committee put together a gap analysis that shows the specs
> and patches that need to merge in the different OpenStack projects by the end of Stein. The attached PDF document
> shows this analysis. Although other projects are involved, most of the work has to be done in Nova, Neutron and
> Horizon. Hopefully all the involved projects will help StarlingX achieve this important goal.
>  
> It has to be noted that work is still on-going to refine this gap analysis, so there might be some updates to it in
> the near future. 
>  
> Best regards
>  
> Miguel