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@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@mlavalle.com] Sent: Thursday, November 22, 2018 2:12 AM To: openstack-discuss@lists.openstack.org; OpenStack Development Mailing List <openstack-dev@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