Open Stack

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-output-based-numa-scheduling.html
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/input-output-based-numa-scheduling.html

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/share-pci-between-numa-nodes.html

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
> 
> 
> 
> 
>