On 04/23/2018 05:51 PM, Arvind N wrote:
Thanks for the detailed options Matt/eric/jay.
Just few of my thoughts,
For #1, we can make the explanation very clear that we rejected the
request because the original traits specified in the original image and
the new traits specified in the new image do not match and hence rebuild
is not supported.
I believe I had suggested that on the spec amendment patch. Matt had
concerns about an error message being a poor user experience (I don't
necessarily disagree with that) and I had suggested a clearer error
message to try and make that user experience slightly less sucky.
For #3,
Even though it handles the nested provider, there is a potential issue.
Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1),
another one with some kind of offload feature(VF2).(Described by alex)
Initial instance launch happens with VF:1 allocated, rebuild launches
with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want
the instance to be allocated VF2.
But the original allocation happens against VF1 and since in rebuild the
original allocations are not changed, we have wrong allocations.
Yep, that is certainly an issue. The only solution to this that I can
see would be to have the conductor ask the compute node to do the
pre-flight check. The compute node already has the entire tree of
providers, their inventories and traits, along with information about
providers that share resources with the compute node. It has this
information in the ProviderTree object in the reportclient that is
contained in the compute node resource tracker.
The pre-flight check, if run on the compute node, would be able to grab
the allocation records for the instance and determine if the required
traits for the new image are present on the actual resource providers
allocated against for the instance (and not including any child
providers not allocated against).
Or... we chalk this up as a "too bad" situation and just either go with
option #1 or simply don't care about it.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
