sorry to top post but wanted to provide some feedback on the pdf. on future revisions of the pdf the live migration with pinning and numa topology item shoudl be updated to the stein version of the spec. https://review.openstack.org/#/c/599587 the main reson for me to respond however is the "SR-IOV/PT best effort scheduling policy" item. this feature was not completed in queens and is possibly broken. as part of the implementation the flavor extra specs and image metadata items that were part of the spec were removed meaning that neutron sriov port and numa affinity policies for hardware offloaded ovs where lost. the spec was retro activly updated to reflect what lanned in https://review.openstack.org/#/c/555000 the first spec to introduce the concpet of pci numa affintiy was https://specs.openstack.org/openstack/nova-specs/specs/juno/approved/input-o... which clearly calls out that this was inteded for NFV workloads and makes reference to the 2 specs intoducing neutron contoled sriov interface to nova and guest numa topologies for libvirt. at the time my team at intel had our own implemtations of hugepages,vhost user and we hand a complete working implmentation of pci numa affinity with 3 policys (strict affinity, best effort affinity and any device) when the spec was repropsed for kilo the neutron aspect was left out based on feedback that it added noise since neutron controled sriov was just anoter way of useing pci passthough. https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/inpu... in queens after an interlude where work on this got out sourced and abandoned twice we finally got around to proposing the policies that where in the original juno code https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/sh... if you look at the current version of that spec you will notice that flavor extras specs and image metadata values are missing but it was updated by https://review.openstack.org/#/c/555000 however it still contians the section decibing what happens if the flavor and image metadata dissagree "If both image and flavor properties are not set (equals None) the legacy policy will be used. If one of image or flavor property is not set (equals None) but the other property is set then the value of the set property will be used. In a case of conflicts between flavor and image properties (both properties are set and they are not equal) an exception will be raised." there have been report at the vacovour summit and more recently on mailing list http://lists.openstack.org/pipermail/openstack-dev/2018-November/136461.html that this fuctionality is broken even for the restrited case of using alias. there has also been a direct request/bug opened to track the neutron support https://bugs.launchpad.net/nova/+bug/1795920. so if we want to close this gap we have to first do an audit of the code an figure out what works/dosent and reprose the queens spec. ill be trying test this over the next two days but i wanted to highlight this a risk. On Wed, 2018-11-21 at 21:42 +0100, melanie witt wrote:
On Wed, 21 Nov 2018 20:34:09 +0000, Jeremy Stanley wrote:
On 2018-11-21 21:23:51 +0100 (+0100), melanie witt wrote: [...]
The vTPM support spec was merged about two weeks ago and we are awaiting implementation patches from cfriesen.
[...]
Thanks, I had somehow missed noticing this spec up to now. I'm curious to follow the implementation and find out how we go about making sure users don't get the impression that an emulated TPM provides anywhere near the same sorts of guarantees as real one.
Here's a link to the spec:
https://review.openstack.org/571111
and you can follow the implementation (once it's proposed) via the gerrit topic.
Cheers, -melanie