<div dir="ltr">On 10 January 2014 15:30, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We seemed happy with the current system (roughly) around GPU passthrough:<br>
nova flavor-key <three_GPU_attached_30GB> set<br>
"pci_passthrough:alias"=" large_GPU:1,small_GPU:2"<br>
nova boot --image some_image --flavor <three_GPU_attached_30GB> <some_name><br>
</blockquote><div><br></div><div>Actually, I think we pretty solidly disagree on this point.  On the other hand, Yongli's current patch (with pci_flavor in the whitelist) is pretty OK.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

nova boot --flavor m1.large --image <image_id><br>
  --nic net-id=<net-id-1><br>
  --nic net-id=<net-id-2>,nic-type=fast </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  --nic net-id=<net-id-3>,nic-type=fast <vm-name><br>

</blockquote><div><br></div><div>With flavor defined (wherever it's defined):<br><br></div><div>nova boot ..<br></div>   --nic net-id=<net-id-1>,pci-flavor=xxx    # ok, presumably defaults to PCI passthrough<br>

<div>   --nic net-id=<net-id-1>,pci-flavor=xxx,vnic-attach=macvtap # ok<br>   --nic net-id=<net-id-1> # ok - no flavor = vnic<br></div>   --nic port-id=<net-id-1>,pci-flavor=xxx    # ok, gets vnic-attach from port<br>

<div>   --nic port-id=<net-id-1> # ok - no flavor = vnic<br></div><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
or<br>
<br>
neutron port-create<br>
  --fixed-ip subnet_id=<subnet-id>,ip_address=192.168.57.101<br>
  --nic-type=<slow | fast | foobar><br>
  <net-id><br>
nova boot --flavor m1.large --image <image_id> --nic port-id=<port-id><br></blockquote><div><br></div><div>No, I think not - specifically because flavors are a nova concept and not a neutron one, so putting them on the port is inappropriate. Conversely, vnic-attach is a Neutron concept (fine, nova implements it, but Neutron tells it how) so I think it *is* a port field, and we'd just set it on the newly created port when doing nova boot ..,vnic-attach=thing<br>

<br></div>2) Expand PCI alias information<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
{<br>
 "name":"NIC_fast",<br> 
sriov_info: {<br>
  "nic_type":"fast",<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  "network_ids": ["net-id-1", "net-id-2"]<br></blockquote><div><br></div><div>Why can't we use the flavor name in --nic (because multiple flavors might be on one NIC type, I guess)?  Where does e.g. switch/port information go, particularly since it's per-device (not per-group) and non-scheduling?  <br>

<br>I think the issue here is that you assume we group by flavor, then add extra info, then group into a NIC group.  But for a lot of use cases there is information that differs on every NIC port, so it makes more sense to add extra info to a device, then group into flavor and that can also be used for the --nic.<br>

<br>network_ids is interesting, but this is a nova config file and network_ids are (a) from Neutron (b) ephemeral, so we can't put them in config.  They could be provider network names, but that's not the same thing as a neutron network name and not easily discoverable, outside of Neutron i.e. before scheduling.<br>

<br></div><div>Again, Yongli's current change with pci-flavor in the whitelist records leads to a reasonable way to how to make this work here, I think; straightforward extra_info would be fine (though perhaps nice if it's easier to spot it as of a different type from the whitelist regex fields).<br>

</div><br></div></div></div>