)]}'
{"specs/liberty/approved/libvirt-macvtap-vif.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":14,"context_line":"Add macvtap as new virtual interface (vif) type to Nova\u0027s libvirt driver."},{"line_number":15,"context_line":"This is required to attach libvirt managed KVM guests via macvtap to the hosts"},{"line_number":16,"context_line":"network. It will be exploited by a new macvtap ml2 plugin and agent, which will"},{"line_number":17,"context_line":"be hosted on stackforge, due to the Neutron vendor decomposition."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_92760b3d","line":17,"range":{"start_line":17,"start_character":0,"end_line":17,"end_character":65},"updated":"2015-06-12 13:59:46.000000000","message":"This is an important detail for me. Neutron deciding to kick out a bunch of drivers means that nova ends up having support in tree for things that are not in neutron itself. This makes me wonder if we will have issues supporting a given version of neutron and a given version of the neutron driver at the same time, as well as how it\u0027s ever going to be tested in a meaningful way, etc.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"92a7733c8bac07d9a1f0fd9f55481b146f611b03","unresolved":false,"context_lines":[{"line_number":14,"context_line":"Add macvtap as new virtual interface (vif) type to Nova\u0027s libvirt driver."},{"line_number":15,"context_line":"This is required to attach libvirt managed KVM guests via macvtap to the hosts"},{"line_number":16,"context_line":"network. It will be exploited by a new macvtap ml2 plugin and agent, which will"},{"line_number":17,"context_line":"be hosted on stackforge, due to the Neutron vendor decomposition."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_6a04b314","line":17,"in_reply_to":"1af86dd1_92760b3d","updated":"2015-06-12 15:47:45.000000000","message":"Dan - I believe the big picture is that, in addition to allowing VIF plugin scripts per https://review.openstack.org/#/c/162468/, Nova must (continue to) provide a set of basic VIF types: one for each pattern of required libvirt XML interface specification.  This is because Nova remains completely responsible for generating that XML.  I\u0027d see Nova\u0027s provision of this basic set - without necessarily knowing in detail who is going to use those - as similar to how libvirt provides various interface specification options.\n\nThat isn\u0027t to disagree with what you\u0027ve written, because you\u0027re right that the only user(s) of a particular VIF type might be out of tree - but in principle the set of basic VIF types needed should be smaller than the set of VIF types that we have today, because they will be 1 per config pattern, instead of 1 per (config pattern plus plug/unplug logic), and hence perhaps it\u0027s more likely that there will be _some_ in tree user of each basic VIF type.\n\nAnother thought, that might help, is that with the Neutron \u0027big tent\u0027, many users should be in openstack/networking-XXX or stackforge/networking-XXX projects, even if they aren\u0027t in Neutron itself.  So they are not so far away.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Use Cases"},{"line_number":46,"context_line":"----------"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Attaching libvirt/KVM guests via macvtap to the hosts network"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"No additional impact on actors from the Nova side (configuration is done in"},{"line_number":51,"context_line":"Neutron)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_f2b41fd2","line":48,"updated":"2015-06-12 13:59:46.000000000","message":"Can you add some text about *why* this is important? Just supporting a thing because it\u0027s unsupported is not a good reason to add something like this, IMHO.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Use Cases"},{"line_number":46,"context_line":"----------"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* Attaching libvirt/KVM guests via macvtap to the hosts network"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"No additional impact on actors from the Nova side (configuration is done in"},{"line_number":51,"context_line":"Neutron)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_e571b7a9","line":48,"in_reply_to":"1af86dd1_f2b41fd2","updated":"2015-06-16 09:35:05.000000000","message":"I will do in the next patchset. Basically it offers great performance (high throughput low latency, low cpu consumption) - we did some tests comparing against Openstack-ovs and it\u0027s much better (around 30-50%) in each category. It\u0027s built into every kernel (no third party software required) and it does not require much configuration.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"7ce5ad217116df2db6a33f711b00f09598f83477","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  \u003c/interface\u003e"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"On port binding, the Neutron code enriches the vif_details with two attributes."},{"line_number":72,"context_line":"These are defined in the Neutron agents config, but Nova needs to know about it"},{"line_number":73,"context_line":"to instantiate the macvtap correctly: ::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_578f6523","line":71,"updated":"2015-06-12 13:33:29.000000000","message":"Do we have the neutron side of spec ready for review?\n\nWith the existing SR-IOV solution, the allocation of a PCI device is done from the nova side, and scheduling of a compute node takes the device availability into account. \n\nMy understanding is that this proposal would handle the macvtap for non-sriov ports. How would above aspects be handled?","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  \u003c/interface\u003e"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"On port binding, the Neutron code enriches the vif_details with two attributes."},{"line_number":72,"context_line":"These are defined in the Neutron agents config, but Nova needs to know about it"},{"line_number":73,"context_line":"to instantiate the macvtap correctly: ::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_8540eba6","line":71,"in_reply_to":"1af86dd1_578f6523","updated":"2015-06-16 09:35:05.000000000","message":"The spec for the neutron part is not yet public - I\u0027m waiting for the stackforge repo to be created (already requested).\n\nThe great difference to sriov-macvtap is, that I\u0027m NOT using the passthrough mode, but the bridge or alternatively vepa mode. So the hosts interface is not an Openstack Resource. In the flat use case, all macvtaps in the same logical network will \"sit\" on the same lower (source) device. So it\u0027s a *:1 relationship between macvtap and eth interface.\nThere\u0027s no need to allocate an eth device like in the sriov-macvtap-passthrough case where you have the 1:1 relationship between macvtap and eth interface. It\u0027s more like the linuxbridge or the ovs case where the interface is not treated as a resource, as it\u0027s share anyhow.\n\nThis is explained in the neutron spec in more detail - but it\u0027s not yet upstream as I\u0027m still waiting for my stackforge repo to be created.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"958b5e00cf599c8ff63a25bdd9a668a01577a98b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  \u003c/interface\u003e"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"On port binding, the Neutron code enriches the vif_details with two attributes."},{"line_number":72,"context_line":"These are defined in the Neutron agents config, but Nova needs to know about it"},{"line_number":73,"context_line":"to instantiate the macvtap correctly: ::"},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_335b5b56","line":71,"in_reply_to":"fa32b979_8540eba6","updated":"2015-06-16 13:31:42.000000000","message":"makes sense. Looking forward to the neutron spec.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":100,"context_line":"Instead of creating a new vif type in Nova, an existing vif_type could be"},{"line_number":101,"context_line":"refactored to become more generic and be reused by the macvtap Neutron code."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"But having dependencies to vif types used by other vendor Neutron drivers or"},{"line_number":104,"context_line":"agents is not a good thing I guess. It also might end up in a couple if-else"},{"line_number":105,"context_line":"statements to determine which attributes must or must not be set."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"**vnic_type**"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_92dbab1b","line":105,"range":{"start_line":103,"start_character":0,"end_line":105,"end_character":65},"updated":"2015-06-12 13:59:46.000000000","message":"So we\u0027re adding a new thing instead of re-using existing stuff because we might have to add \"a couple if-else statements\" ?\n\nPlease elaborate here.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"But having dependencies to vif types used by other vendor Neutron drivers or"},{"line_number":104,"context_line":"agents is not a good thing I guess. It also might end up in a couple if-else"},{"line_number":105,"context_line":"statements to determine which attributes must or must not be set."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"**vnic_type**"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_88032242","line":105,"in_reply_to":"1af86dd1_92dbab1b","updated":"2015-06-16 09:35:05.000000000","message":"At least this is how it was done in the past. Each neutron driver introduced it\u0027s own vif_type. The architecture of the nova vif-driver requires  for each vif_type the following methods to be existent:\n- get_config_\u003cvif_type\u003e\n- plug_\u003cvif_type\u003e\n- unplug_\u003cvif_type\u003e\n\nIf neutron-driver would share the same vif_type, the same xml would be generated, and the same plug/unplug actions would be executed. For distinguishing between neutron drivers within such a method an new identifier would be required (something like the driver name). But this might be solved with the vif-plug-script blueprint [1] for the plug/unplug methods anyhow. But not for the get_config methods. There some general effort needs to be set up to cover that as well (maybe this is the trigger to do that).\n\nComing back to my proposal: In fact as much existing code as possible is being re-used. It\u0027s just the method definition that is new. This method calls other existing methods to do it\u0027s job. \n\nI will think about a way of generalizing the get_config parts as well. Thanks for this feedback!\n\n\n[1] https://review.openstack.org/#/c/162468/16/specs/liberty/approved/vif-plug-script.rst,cm","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Due to the nature of macvtap, Neutron Security Groups and anti-spoofing-rules"},{"line_number":146,"context_line":"cannot be supported with this new vif_type. Macvtap doesn\u0027t offer a hook for"},{"line_number":147,"context_line":"the hypervisor to apply ip- or ebtables rules on the guests traffic."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Notifications impact"},{"line_number":150,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_92f28b99","line":147,"updated":"2015-06-12 13:59:46.000000000","message":"Wait... what? This driver is fundamentally incompatible with security groups?","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Due to the nature of macvtap, Neutron Security Groups and anti-spoofing-rules"},{"line_number":146,"context_line":"cannot be supported with this new vif_type. Macvtap doesn\u0027t offer a hook for"},{"line_number":147,"context_line":"the hypervisor to apply ip- or ebtables rules on the guests traffic."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Notifications impact"},{"line_number":150,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_23ed5725","line":147,"in_reply_to":"1af86dd1_92f28b99","updated":"2015-06-16 09:35:05.000000000","message":"yes, that\u0027s how macvtap was designed. Bring the guest as close as possible to the hardware switch and eliminate the need of a managed vswitch on the hypervisor at all. The hyperivsor itself is not allowed to intercept guest traffic somehow. That\u0027s why iptables and ebtables can not be applied on a macvtap device. \n\nHowever there is the option to use the vepa mode for the macvtap and let the hw switch handle the security groups via another vendor specific neutron driver. Or use the qbh or qbg extensions - but this is not the plan for this driver for now - maybe it could be extended later on. But I assume it also would required some code that is setting up the hw switch accordingly...\n\nNot sure how other drivers that are dealing with direct or macvtap connections handle this, but I assume that they also not support it or rely on programming hardware.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":162,"context_line":"None from a Openstack code point of view."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"But the network performance of the guest should increase compared to the ovs"},{"line_number":165,"context_line":"reference implementation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Other deployer impact"},{"line_number":168,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_b23c6730","line":165,"updated":"2015-06-12 13:59:46.000000000","message":"What about compared to other drivers like bridging?","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":162,"context_line":"None from a Openstack code point of view."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"But the network performance of the guest should increase compared to the ovs"},{"line_number":165,"context_line":"reference implementation."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Other deployer impact"},{"line_number":168,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_a36e4794","line":165,"in_reply_to":"1af86dd1_b23c6730","updated":"2015-06-16 09:35:05.000000000","message":"We did not do any tests with linuxbridge, but a presentation on the summit [1] showed numbers that the performance is compareable to ovs (maybe slightly better), while we observed huge performance increase with macvtap.\n[1] https://www.youtube.com/watch?v\u003dmJYk2jJ9tXg","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"7570784fafe092852775db818970aae9f71f8109","unresolved":false,"context_lines":[{"line_number":195,"context_line":"Dependencies"},{"line_number":196,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"None"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_6d69728b","line":198,"updated":"2015-06-12 14:14:28.000000000","message":"So we are almost agreed on changing VIF drivers using this:\nhttps://review.openstack.org/#/c/162468/16/specs/liberty/approved/vif-plug-script.rst,cm","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":195,"context_line":"Dependencies"},{"line_number":196,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"None"},{"line_number":199,"context_line":""},{"line_number":200,"context_line":""},{"line_number":201,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_2309d7dd","line":198,"in_reply_to":"1af86dd1_6d69728b","updated":"2015-06-16 09:35:05.000000000","message":"will add dependency","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4c6a30410c97dcc35702e9eff5f1c80298c186e6","unresolved":false,"context_lines":[{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* Unittest"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* No tempest test, as it would require the corresponding Neutron code"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1af86dd1_d226c315","line":206,"updated":"2015-06-12 13:59:46.000000000","message":"I assume that here you mean \"no tempest test because this is testing a thing that is not in-tree in neutron\" is that right?","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"d5a15c34339cc012592a00eff8a8b04c370735bb","unresolved":false,"context_lines":[{"line_number":203,"context_line":""},{"line_number":204,"context_line":"* Unittest"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"* No tempest test, as it would require the corresponding Neutron code"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa32b979_43fdfb38","line":206,"in_reply_to":"1af86dd1_d226c315","updated":"2015-06-16 09:35:05.000000000","message":"yes, that\u0027s one reason.\nI was more focusing on the point, it would be the job of neutron to do tempest testing, as soon as the driver is available. As it\u0027s on stackforge, it\u0027s would be a thrid party CI. There are ideas to have one, but not yet concrete plans.","commit_id":"35c723557a9300cf6753c4cb3a3cc1062f87af82"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"7e09a7cd3511012b6e1770ce332212dd6536e990","unresolved":false,"context_lines":[{"line_number":76,"context_line":"methods, existing buliding blocks are used."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* As soon as the plug-vif-script feature `[3]`_ is implemented, plug/unplug"},{"line_number":79,"context_line":"  code will be moved out to the networking-macvtap repository."},{"line_number":80,"context_line":"* After that happend, an approach could be set up to create a new generic"},{"line_number":81,"context_line":"  \u0027direct\u0027 vif_type which can be used by other vendors using direct attachments"},{"line_number":82,"context_line":"  as well."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_90c4b940","line":79,"updated":"2015-06-22 14:20:43.000000000","message":"Maybe a better approach is to just \"pass\" the plug/unplug methods and wait until either [3] or the discussed alternative is implemented and add support for plug/unplug later on with the new approach. This would me allow to go forward with flat networking approach. Plug/unplug is only required for vlan networking (for creation of the vlan device) which can be added later on in the new approach.","commit_id":"17ef90a158d2460936c145ea63cf6ebefddde808"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"99a409d35e5f19c6e056c7c190b60f19378e2d8e","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  required."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"One idea would be, to support all of these types in the Neutron part. But all"},{"line_number":194,"context_line":"would result in the same macvtap device."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_35af942b","line":194,"updated":"2015-06-23 20:31:10.000000000","message":"I think that \u0027normal\u0027 shouldn\u0027t be used for this. The reason for that is that one can have multiple mech drivers configured. For example, both openvswitch and the macvtap mech driver can be configured in neutron. The former will bind to normal vnic_type, and the latter macvtap.\nCurrently, the definition of \u0027macvtap\u0027 is associated with PCI passthrough or SR-IOV. For the regular macvtap, I think that we may have to use something else. It seems like that the current name \u0027macvtap\u0027 is a good fit for what\u0027s proposed in this spec, while the one for sr-ipv should be called something else.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"fb2ae074a73b79e173abb8d26c00f8738b6ec095","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  required."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"One idea would be, to support all of these types in the Neutron part. But all"},{"line_number":194,"context_line":"would result in the same macvtap device."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_ea05c610","line":194,"in_reply_to":"fa32b979_35af942b","updated":"2015-06-23 20:57:15.000000000","message":"From my understanding vnic_type is totally transparent to nova - that\u0027s why I removed it in the new patchset. Nova shouldn\u0027t know and care about it. It\u0027s an optional attribute that can be specified during neutron port creation.\n\nSo if I go with vnic_type macvtap, direct or normal - nova wouldn\u0027t know about that like it doesn\u0027t with most other vif_types. \n\nThe only exception is the pci code, that is doing some actions based on the vnic_type. But this is a special scenario, which is only required as the same vif_type can result in 2 totally different xml and plug/unplug actions. Vnic_type is used to differentiate between those. This will not be the case for the macvtap agent. \n\nIn the scenario you described, the vnic_type is used for controlling which drive/agent to use for port creation, rigth?\n\nWhich type is best for the driver, should be part in the neutron review. I will reconsider your input there. But I see the macvtap agent more as an alternative to ovs instead of a parallel thing. Thanks!","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"125b4f1295fb1d01afe732e072db4d7c9b4021b6","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  required."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"One idea would be, to support all of these types in the Neutron part. But all"},{"line_number":194,"context_line":"would result in the same macvtap device."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_1b42730f","line":194,"in_reply_to":"fa32b979_e4562e29","updated":"2015-06-25 10:11:04.000000000","message":"Good point. a vnic_type \u003d! \u0027normal\u0027 is used to schedule PCI requests. Wasn\u0027t aware of that. As the proposed macvtap integration does not rely on pci at all, the only option is to use the \u0027normal\u0027 type (which is the plan) ore create a new type for this agent (which I do not want to do).\n\nBut I see the potential confusion with the existing \u0027macvtap\u0027 type which triggers pci request just due to the naming. The only good idea I have is to rename it to somehting like macvtap-sriov. But this would break api I guess. I will add these considerations in the next patchset again. Such an effort requires a separate blueprint. \n\nBut the proposed vif_type does not know anything about vnic_types! So the proposed feature is independent of this discussion.\n\nThanks for your input. It gave me great insides!","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"37b65f8c6c591dba2e05f99f4325864848a6d887","unresolved":false,"context_lines":[{"line_number":191,"context_line":"  required."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"One idea would be, to support all of these types in the Neutron part. But all"},{"line_number":194,"context_line":"would result in the same macvtap device."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_e4562e29","line":194,"in_reply_to":"fa32b979_ea05c610","updated":"2015-06-24 17:06:48.000000000","message":"Actually, vnic_type is used for port binding in individual ml2 mech drivers. For example, mech_agent.py supports \u0027normal\u0027 only. the supported_vnic_types provides a list of vnic types supported by the mech driver.\n\nAlso, vnic_type is currently used by nova to determine if PCI requests should be created that will be used for the scheduler to schedule sriov-capable compute nodes. Check compute/api.py for create_pci_requests_for_sriov_ports().\n\nUsing \u0027normal\u0027 for regular macvtap would prevent that call from doing anything. But it would cause confusion in using the neutron API to create a port. It also means a cloud either has all the ports to be regular macvtap or not. But I agree that it\u0027s better for the user not to care about it at all. Given the differences between the vnic types, however, it doesn\u0027t seem to be practical.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e40765d459ffff35dc57f1aba65e066bf63ee3fe","unresolved":false,"context_lines":[{"line_number":213,"context_line":"cannot be supported with this new vif_type. Macvtap doesn\u0027t offer a hook for"},{"line_number":214,"context_line":"the hypervisor to apply ip- or ebtables rules on the guests traffic."},{"line_number":215,"context_line":"However, those features are handled in neutron. We\u0027re still looking for a"},{"line_number":216,"context_line":"solution but this will not affect the nova integration."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Notifications impact"},{"line_number":219,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_41ccecba","line":216,"updated":"2015-06-23 13:58:47.000000000","message":"Well....we still have nova-network, so what does this mean there?  Or would your vif type just never be used outside of a neutron case?\n\nWhat happens if someone boots an instance (with neutron doing networking) and they request a security group as part of that request but are using your vif type?  Do we error?  Do we ignore?","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6b62ea9cd96348840f3fd929fa7a3cbad92d8ac7","unresolved":false,"context_lines":[{"line_number":213,"context_line":"cannot be supported with this new vif_type. Macvtap doesn\u0027t offer a hook for"},{"line_number":214,"context_line":"the hypervisor to apply ip- or ebtables rules on the guests traffic."},{"line_number":215,"context_line":"However, those features are handled in neutron. We\u0027re still looking for a"},{"line_number":216,"context_line":"solution but this will not affect the nova integration."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Notifications impact"},{"line_number":219,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_e83815a2","line":216,"in_reply_to":"fa32b979_2f798e82","updated":"2015-06-25 14:15:30.000000000","message":"Oh, OK, that wasn\u0027t clear to me, maybe have that in the deployer impact section?","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"2dd04b292a9cfcad7b593f3c36ecd0d6874d8657","unresolved":false,"context_lines":[{"line_number":213,"context_line":"cannot be supported with this new vif_type. Macvtap doesn\u0027t offer a hook for"},{"line_number":214,"context_line":"the hypervisor to apply ip- or ebtables rules on the guests traffic."},{"line_number":215,"context_line":"However, those features are handled in neutron. We\u0027re still looking for a"},{"line_number":216,"context_line":"solution but this will not affect the nova integration."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Notifications impact"},{"line_number":219,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_2f798e82","line":216,"in_reply_to":"fa32b979_41ccecba","updated":"2015-06-23 15:22:38.000000000","message":"With nova network you can not use this new vif_type at all. I do not plan any integration. \n\nRegarding Sec. Group, it\u0027s like with other direct attachments, the NoopFirewallDriver should/must be configured.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e40765d459ffff35dc57f1aba65e066bf63ee3fe","unresolved":false,"context_lines":[{"line_number":269,"context_line":""},{"line_number":270,"context_line":"New vif-plug approach:"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* `[3]`_ or"},{"line_number":273,"context_line":"* `[5]`_"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_c629f29c","line":272,"updated":"2015-06-23 13:58:47.000000000","message":"I don\u0027t think this is likely to happen, at least in Liberty.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e40765d459ffff35dc57f1aba65e066bf63ee3fe","unresolved":false,"context_lines":[{"line_number":270,"context_line":"New vif-plug approach:"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* `[3]`_ or"},{"line_number":273,"context_line":"* `[5]`_"},{"line_number":274,"context_line":""},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Testing"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_c6001205","line":273,"updated":"2015-06-23 13:58:47.000000000","message":"This will probably be the actual dependency.  Like os-brick with volume drivers, we want to move the vif stuff into a library so that nova and neutron can share the same code.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e40765d459ffff35dc57f1aba65e066bf63ee3fe","unresolved":false,"context_lines":[{"line_number":279,"context_line":"* Unittest"},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"* No tempest tests. They will be added with the corresponding neutron code and"},{"line_number":282,"context_line":"  run by a neutron Thirdparty CI."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_46b88275","line":282,"updated":"2015-06-23 13:58:47.000000000","message":"This means that if someone proposes a change to nova that breaks your vif type, you won\u0027t find out about it until post-merge, but I think that\u0027s been the case with a lot of the vendor volume drivers in nova too.  Their 3rd party CI runs on cinder changes rather than nova.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"2dd04b292a9cfcad7b593f3c36ecd0d6874d8657","unresolved":false,"context_lines":[{"line_number":279,"context_line":"* Unittest"},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"* No tempest tests. They will be added with the corresponding neutron code and"},{"line_number":282,"context_line":"  run by a neutron Thirdparty CI."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_cf99027b","line":282,"in_reply_to":"fa32b979_46b88275","updated":"2015-06-23 15:22:38.000000000","message":"Right, but that\u0027s the same thing with other 3rd party types. It must be verified by a third party CI.","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"31263866173731c6ccd4b6c9f3433296204a1298","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"References"},{"line_number":292,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":293,"context_line":""},{"line_number":294,"context_line":".. _[1]: https://launchpad.net/networking-macvtap"},{"line_number":295,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_61901044","line":292,"updated":"2015-06-23 14:03:29.000000000","message":"nit: this sections is blank when viewed in docs:\n\nhttp://docs-draft.openstack.org/80/182280/4/check/gate-nova-specs-docs/5a54288//doc/build/html/specs/liberty/approved/libvirt-macvtap-vif.html\n\nThe links work elsewhere in the doc, but could you make the links also show up in the references section here when viewed in rendered docs?","commit_id":"cb9fad5a9276f952db82311b0018d5148bc8c966"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"e8b169775a43cbeca7d2926871b0d8189c36c0f7","unresolved":false,"context_lines":[{"line_number":75,"context_line":"  e.g. \u0027bridge\u0027 or \u0027vepa\u0027"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Bandwith configurations are supported like with other vif types using a macvtap"},{"line_number":79,"context_line":"based connection (e.g. \u0027hw_veb\u0027)."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"This proposed change will consider the ongoing os-vif-library discussion"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_355d5447","line":78,"updated":"2015-06-23 20:31:48.000000000","message":"typo: s/bandwith/bandwidth","commit_id":"7c71f841a89815df896678ed02ec46f6e845194d"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"8eb498fc1db12bc0d40047cc5863b72cdf428412","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  macvtap sits on)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"* mode: The mode, in which the macvtap device should be instantiated."},{"line_number":75,"context_line":"  e.g. \u0027bridge\u0027 or \u0027vepa\u0027"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Bandwith configurations are supported like with other vif types using a macvtap"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa32b979_bb12565f","line":75,"updated":"2015-06-25 15:48:46.000000000","message":"Is above change part of implementing this BP? Do we want to merge this and the code without knowing how neutron is going to support them (which also needs to be approved, I guess)?","commit_id":"0a79595aec4b3d6d905b57bbe244f01cebddb95c"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"c39069d9b9081eb07f891c16be6bae974b1e73c5","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  macvtap sits on)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"* mode: The mode, in which the macvtap device should be instantiated."},{"line_number":75,"context_line":"  e.g. \u0027bridge\u0027 or \u0027vepa\u0027"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Bandwith configurations are supported like with other vif types using a macvtap"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa32b979_07d098f6","line":75,"in_reply_to":"fa32b979_67f644fb","updated":"2015-06-26 12:45:46.000000000","message":"right, this information is taken from the agents config file. The neutron server holds the information of all agents with all its configurations.\n\nI would use a dictionary of the port-binding API (either binding:profile or binding:vif_details) to return the values (Response only). The API just describes these 2 attributes as dictionaries, without restricting or listing concrete content of it. So IMO it would not be an API change. But I\u0027ll clarify that before merging any code!","commit_id":"0a79595aec4b3d6d905b57bbe244f01cebddb95c"},{"author":{"_account_id":6685,"name":"Baodong (Robert) Li","email":"baoli@cisco.com","username":"baoli"},"change_message_id":"48921e26c5a5b893d41d039ae4a3f934ce6b5a65","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  macvtap sits on)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"* mode: The mode, in which the macvtap device should be instantiated."},{"line_number":75,"context_line":"  e.g. \u0027bridge\u0027 or \u0027vepa\u0027"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Bandwith configurations are supported like with other vif types using a macvtap"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa32b979_67f644fb","line":75,"in_reply_to":"fa32b979_8b6a7c80","updated":"2015-06-26 12:26:47.000000000","message":"I see. And will the above data be configured (rather than entered through neutron API enhancement)?","commit_id":"0a79595aec4b3d6d905b57bbe244f01cebddb95c"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"ef49f84235c175afed607f3ea2cbc9531efa0343","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  macvtap sits on)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"* mode: The mode, in which the macvtap device should be instantiated."},{"line_number":75,"context_line":"  e.g. \u0027bridge\u0027 or \u0027vepa\u0027"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Bandwith configurations are supported like with other vif types using a macvtap"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa32b979_8b6a7c80","line":75,"in_reply_to":"fa32b979_bb12565f","updated":"2015-06-26 09:54:35.000000000","message":"In my prototype I used the vif details dictionary. The data is added by the neutron mechanism, which is fully under my control (own openstack project)","commit_id":"0a79595aec4b3d6d905b57bbe244f01cebddb95c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"82807a050ba43d017b63d989a9355feeb6d14366","unresolved":false,"context_lines":[{"line_number":184,"context_line":"Dependencies"},{"line_number":185,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"New vif-plug approach:"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"* `[5]`_ or alternatively"},{"line_number":190,"context_line":"* `[3]`_"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa32b979_a8da0d49","line":187,"updated":"2015-06-25 14:17:58.000000000","message":"For the record, I don\u0027t expect either of those to land in Liberty given other priorities, so I wouldn\u0027t be completely against just landing this change into nova in liberty the \u0027old way\u0027 for new vif types.","commit_id":"0a79595aec4b3d6d905b57bbe244f01cebddb95c"}]}