)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":10,"context_line":"to provide a versioned object model for data passed from neutron"},{"line_number":11,"context_line":"to nova for VIF port binding, and an API to allow vendors to"},{"line_number":12,"context_line":"provide custom plug/unplug actions for execution by Nova."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Change-Id: If285dae9934cd21d58e52c15dedff9e68e418a47"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"ba3cc151_c3f80f4c","line":13,"updated":"2015-07-01 09:09:44.000000000","message":"We should really include the blueprint here, to help with tracking:\nblueprint os-vif-library","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"}],"specs/liberty/approved/os-vif-library.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Project Priority"},{"line_number":63,"context_line":"-----------------"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"De-gross-ification of networking ? \u003c/joke\u003e"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Proposed change"},{"line_number":68,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_483e488c","line":65,"updated":"2015-06-23 17:29:49.000000000","message":"Few things:\n\n1. That\u0027s not a priority (although maybe it should be)\n2. This is far from sufficient for de-gross-ification :P","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":87,"context_line":"     * Code distributed by mechanism vendor"},{"line_number":88,"context_line":"     * Allows vendors to innovate without bottleneck on Nova"},{"line_number":89,"context_line":"       developers in common case."},{"line_number":90,"context_line":"     * In the, uncommon, event a new VIF type was required,"},{"line_number":91,"context_line":"       this would still require os-vif modification with"},{"line_number":92,"context_line":"       Nova \u0026 Neutron core team signoff."},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_8390b144","line":90,"range":{"start_line":90,"start_character":23,"end_line":90,"end_character":24},"updated":"2015-06-23 17:29:49.000000000","message":"s/,//","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"d01615f5b094c561417186deb26e95d463d04a10","unresolved":false,"context_lines":[{"line_number":96,"context_line":"     * Owned by Nova virt driver team"},{"line_number":97,"context_line":"     * Code distributed as part of Nova virt / VIF driver"},{"line_number":98,"context_line":"     * Ensures hypervisor driver retains full control over"},{"line_number":99,"context_line":"       how the guest instances are configured"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"The library will make use of the oslo.versionedobjects module in order to"},{"line_number":102,"context_line":"formally define a set of objects to describe the VIF port binding data."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_57eb32dc","line":99,"updated":"2015-06-24 03:19:50.000000000","message":"I\u0027ve said this before and received objections from Dan, but it is worth restating: occasionally a plugging mechanism wants to write different XML to that that is incorporated into libvirt (or pick your other hypervisor config as you like).  Granted that anyone doing this is risking the stability of their Openstack; granted also that this config is somewhat related to the other configuration and therefore is highly unlikely to cross versions of the libvirt driver.  \n\nHowever, the current mechanism and this proposal deny any possibility for a network plugin implementor to use a new mechanism - vhostuser would be the example, which took two releases to turn up - or to come up with a modified implementation without changing core Nova code, code that typically comes in a package that you have to rebuild if you want to update files within it rather than simply installing extension packages.  It would be nice to enable this so that Neutron drivers are not in lockstep with Nova and don\u0027t find it necessary to modify Nova (which is precisely what this change is trying to permit) and an extension package could be added to the system rather than a replacement.\n\nThis doesn\u0027t allow for that and explicitly excludes it.  Are we all good with that fact?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":96,"context_line":"     * Owned by Nova virt driver team"},{"line_number":97,"context_line":"     * Code distributed as part of Nova virt / VIF driver"},{"line_number":98,"context_line":"     * Ensures hypervisor driver retains full control over"},{"line_number":99,"context_line":"       how the guest instances are configured"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"The library will make use of the oslo.versionedobjects module in order to"},{"line_number":102,"context_line":"formally define a set of objects to describe the VIF port binding data."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_7703d642","line":99,"in_reply_to":"fa32b979_57eb32dc","updated":"2015-06-24 04:10:14.000000000","message":"Actually it doesn\u0027t if I come up with the world\u0027s most evilest VIF plugging type and add it to Nova, I suppose...  New spec time!","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":96,"context_line":"     * Owned by Nova virt driver team"},{"line_number":97,"context_line":"     * Code distributed as part of Nova virt / VIF driver"},{"line_number":98,"context_line":"     * Ensures hypervisor driver retains full control over"},{"line_number":99,"context_line":"       how the guest instances are configured"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"The library will make use of the oslo.versionedobjects module in order to"},{"line_number":102,"context_line":"formally define a set of objects to describe the VIF port binding data."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_043d6b8e","line":99,"in_reply_to":"fa32b979_57eb32dc","updated":"2015-06-24 09:48:11.000000000","message":"Yes, it excludes the possibility for plugins to customize the XML, but I don\u0027t think you should compare the delay in getting current VIF types approved, to how it would work in the future. For a start, we\u0027re needing to create many more VIF types today that should actually be needed - we already have 4 VIF types that use the type\u003dethernet XML with the exact same configuration. With this new approach we\u0027d have a single VIF type that could be used as is by any plugin that needs type\u003dethernet, so there would have been zero need for new VIF type in the case of those mechanisms.\n\nSecond, because the VIF types are explicitly just concerned with providing the information needed to map to guest configuration, the design of new VIF types in the future will be much more straightforward. It would be a simple task to map data required by a new libvirt XML config, to a corresponding VIF type, as we\u0027d not be having to debate the merits/ design of the vendor specific OS setup \u0026 overlap between vendors mechanisms. So adding new VIF types, in the rare cases that is needed, would be a simpler and well defined process.\n\nSo the fact that adding new VIF types will be faster, and that most mechanisms will not even need new VIF types, combine to mitigate the need to go through nova / neutron core teams for approval. I think this is a wise tradeoff between allowing mechanism vendors flexibility and maintaining control of REST API data and virt guest configuration.\n\nFinally, as previously mentioned, the idea that vendors can add new XML configuration via a plugin, without needing to change libvirt driver does not in fact work in practice. Every new XML config needs an update to the nova/virt/libvirt/config.py classes, so that the libvirt driver can deal with it, and there\u0027s no way for the plugin to do that from out of tree. So supporting new XML configs has always required libvirt driver changes, even back in the day when VIF plugins were allowed out of tree.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":114,"context_line":"    class VIFConfig(base.VersionedObject)"},{"line_number":115,"context_line":"        # Common stuff for all VIFs"},{"line_number":116,"context_line":"        fields \u003d {"},{"line_number":117,"context_line":"\t    # VIF port identifier"},{"line_number":118,"context_line":"\t    id:  UUIDField()"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"\t    # Various common fields see current"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_c346b9bf","line":117,"updated":"2015-06-23 17:29:49.000000000","message":"Hard tabs here and below.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"This base object defines the fields that are common to all the"},{"line_number":130,"context_line":"different VIF port binding types. There are a number of these attributes,"},{"line_number":131,"context_line":"currently detailed in the VIF class in nova.network.model, or the equiv"},{"line_number":132,"context_line":"in Neutron."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"On addition here is a \u0027plug\u0027 field which will be the name of a class"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_7e00a601","line":131,"range":{"start_line":131,"start_character":66,"end_line":131,"end_character":71},"updated":"2015-06-23 17:29:49.000000000","message":"s/equiv/equivalent/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":131,"context_line":"currently detailed in the VIF class in nova.network.model, or the equiv"},{"line_number":132,"context_line":"in Neutron."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"On addition here is a \u0027plug\u0027 field which will be the name of a class"},{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_910a2a25","line":134,"updated":"2015-06-24 02:55:54.000000000","message":"s/On/One/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":133,"context_line":""},{"line_number":134,"context_line":"On addition here is a \u0027plug\u0027 field which will be the name of a class"},{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"},{"line_number":138,"context_line":"arbitary number of Neutron mechanisms to be implemented."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_3ef0defc","line":138,"range":{"start_line":136,"start_character":9,"end_line":138,"end_character":56},"updated":"2015-06-23 17:29:49.000000000","message":"This concerns me. Aren\u0027t the plug classes in the library? How will nova and neutron know which of each are supported by either end? What if neutron says \"use plug $foo\" and nova doesn\u0027t support that yet?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2048963cf322280ccd0eedda970b07d304457eb","unresolved":false,"context_lines":[{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"},{"line_number":138,"context_line":"arbitary number of Neutron mechanisms to be implemented."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_83b2eee3","line":138,"in_reply_to":"fa32b979_3ef0defc","updated":"2015-06-23 17:48:20.000000000","message":"Well the idea was that the task of deploying a neutron mechanism involves deploying their desired plugin code onto the compute nodes.\n\nSo, the Neutron vendor would have to make sure their plugin is deployed on compute nodes, before deploying their mechanism on the network nodes.\n\nSimilarly in upgrades, I think the requirement would be that the plugin code is upgraded on the compute nodes before the mechanism is upgraded on the network node. The plugin code would have to the cope with being used with new/old mechanism.\n\n\nAlternatively though, we could extend the negotiation, so instead of passing Neutron a just of VIF types Nova supports, we could provide a list of VIF types and a list of plugin impls, possibly with versions. That way Neutron would know exactly what\u0027s available.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b2fbf36da2229c4a9772482b6202f784a00092d4","unresolved":false,"context_lines":[{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"},{"line_number":138,"context_line":"arbitary number of Neutron mechanisms to be implemented."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_efb39b4b","line":138,"in_reply_to":"fa32b979_83b2eee3","updated":"2015-06-24 04:24:37.000000000","message":"So I think that creates a conflict with how people normally do upgrades (or at least how I tell them to do them). That being everything else (neutron included) gets upgraded, then nova control services get upgraded, then nova-computes. So they\u0027re literally last.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"},{"line_number":138,"context_line":"arbitary number of Neutron mechanisms to be implemented."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_574812b3","line":138,"in_reply_to":"fa32b979_83b2eee3","updated":"2015-06-24 04:10:14.000000000","message":"Your negotiation idea is clearly the right approach, but I think you have to spell out how that would look in negotiation.  You have, in a comment, but I would add that to the spec and also be explicit that the same type can appear multiple times with different versions.\n\nThe negotiation can\u0027t name binding_type and the magic plugging class both because the plugging classes are not registered centrally.  That seems to undermine negotiation.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":135,"context_line":"that will be used to perform the vendor specific plug/unplug work on the"},{"line_number":136,"context_line":"host OS. This de-coupling is what will allow the number of VIFConfig"},{"line_number":137,"context_line":"classes to remain at a fairly small finite size, while still allowing"},{"line_number":138,"context_line":"arbitary number of Neutron mechanisms to be implemented."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_04648bb6","line":138,"in_reply_to":"fa32b979_efb39b4b","updated":"2015-06-24 09:48:11.000000000","message":"Ok, so it seems we\u0027d need to go with the second approach of passing the neccessary information to Neutron when doing the VIF creation. I\u0027ll expand on this detail in next version of the spec to clarify how it might work.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":139,"context_line":""},{"line_number":140,"context_line":"The various VIFConfig subclasses will be created, based on the different"},{"line_number":141,"context_line":"bits of information that are currently passed around. NB, this is not"},{"line_number":142,"context_line":"covering all the current VIF_TYPE_XXX  variants, as a number of them"},{"line_number":143,"context_line":"have essentially identical config parameter requirements, and only differ"},{"line_number":144,"context_line":"in the plug/unplug actions, hence the point previously about the \u0027plug\u0027"},{"line_number":145,"context_line":"class name.  All existing VIF types will be considered legacy. These"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_3431cced","line":142,"updated":"2015-06-24 02:55:54.000000000","message":"s/\u003cspace\u003e\u003cspace\u003evariants/\u003cspace\u003evariants/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":144,"context_line":"in the plug/unplug actions, hence the point previously about the \u0027plug\u0027"},{"line_number":145,"context_line":"class name.  All existing VIF types will be considered legacy. These"},{"line_number":146,"context_line":"various config classes will define a completely new set of modern VIF"},{"line_number":147,"context_line":"types. In many cases they will closely remember the existing VIF types,"},{"line_number":148,"context_line":"but the key difference is in the data serialization format which will"},{"line_number":149,"context_line":"be using oslo.versionedobject serialization instead of dicts. By defining"},{"line_number":150,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_b4539c15","line":147,"updated":"2015-06-24 02:55:54.000000000","message":"remember?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":148,"context_line":"but the key difference is in the data serialization format which will"},{"line_number":149,"context_line":"be using oslo.versionedobject serialization instead of dicts. By defining"},{"line_number":150,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"},{"line_number":151,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":152,"context_line":"indicate what VIF types it is capable of supporting, and thus Neutron"},{"line_number":153,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_be694e8e","line":153,"range":{"start_line":151,"start_character":57,"end_line":153,"end_character":54},"updated":"2015-06-23 17:29:49.000000000","message":"Okay, so why isn\u0027t that list just a enum on the plug field above?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":150,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"},{"line_number":151,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":152,"context_line":"indicate what VIF types it is capable of supporting, and thus Neutron"},{"line_number":153,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_94ad38eb","line":153,"in_reply_to":"fa32b979_031b3ecb","updated":"2015-06-24 02:55:54.000000000","message":"Presumably because they are a free for all on stackforge now for Neutron?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":150,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"},{"line_number":151,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":152,"context_line":"indicate what VIF types it is capable of supporting, and thus Neutron"},{"line_number":153,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_64cf977f","line":153,"in_reply_to":"fa32b979_94ad38eb","updated":"2015-06-24 09:48:11.000000000","message":"Well, yes, Neutron has specifically taken the approach of decentralizing its development process, but Nova has remained a bottleneck in terms of review \u0026 acceptance of VIF plugin logic. The goal is for nova to get out of the way in areas where it doesn\u0027t really matter for us - specifically the vendor specific plug/unplug logic, but formalize control in areas where it does matter for us (VIF type definition, XML generation, REST API data transfer).","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2048963cf322280ccd0eedda970b07d304457eb","unresolved":false,"context_lines":[{"line_number":150,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"},{"line_number":151,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":152,"context_line":"indicate what VIF types it is capable of supporting, and thus Neutron"},{"line_number":153,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_031b3ecb","line":153,"in_reply_to":"fa32b979_be694e8e","updated":"2015-06-23 17:48:20.000000000","message":"There is a 1:1 relation ship between a VIF type and a VIFConfig subclass - in fact the VIF type really just becomes the result of calling \u0027obj_name()\u0027 on the VIFConfig classs.\n\nThe plug field is the name of the Neutron mechanism vendor implementation, and this is completely separate from the VIF type. There is a M:N relationship between the VIF type/VIFConfig class and the vendor plugin class impl. We don\u0027t wish mechanism vendors to be bottlenecked on getting code in nova approved, so whitelisting the plug class values via an enum is not desirable - we explicitly want that to be a free for all.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":151,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":152,"context_line":"indicate what VIF types it is capable of supporting, and thus Neutron"},{"line_number":153,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"  https://review.openstack.org/#/c/190917/"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_f474c49c","line":154,"updated":"2015-06-24 02:55:54.000000000","message":"s/anomous/anonymous/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":154,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":155,"context_line":"on in this spec already"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"  https://review.openstack.org/#/c/190917/"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"So approximately the following set of objects would be defined to"},{"line_number":160,"context_line":"represent the new VIF types. It is expected that the result of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_b70e3e3b","line":157,"updated":"2015-06-24 04:10:14.000000000","message":"More than \u0027touched on\u0027, thank you very much.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"629a0f9ffa05561e0824e16df43e1ad1276ed297","unresolved":false,"context_lines":[{"line_number":214,"context_line":"cover all needed guest configuration modes."},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"These subclasses above, approximately map to the finite set of libvirt XML"},{"line_number":217,"context_line":"configs defined"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"   http://libvirt.org/formatdomain.html#elementsNICS"},{"line_number":220,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_15ccd068","line":217,"updated":"2015-06-23 20:35:39.000000000","message":"So the approach is to look at libvirt and define the finite set of base configs (bridge, direct, hosted, ethernet,.), subclass a few of them and then add all possible attributes that libvirt supports?. Or is the approach to look at the current vif_types, consolidate them (probably to the libvirt base types + subclasses) and and only specify the attributes used today?\n\nMy point is: Within such a base type, there are so many parameters that are optional (just think of the \"driver\" attribute) but may not be used today. So if tomorrow someone wants to exploit this parameter, again changes to nova might be required, as adding a new vif subclass to the os-vif repo is not sufficient - also the xml genearting nova code needs to be updated.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":214,"context_line":"cover all needed guest configuration modes."},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"These subclasses above, approximately map to the finite set of libvirt XML"},{"line_number":217,"context_line":"configs defined"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"   http://libvirt.org/formatdomain.html#elementsNICS"},{"line_number":220,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_44be13af","line":217,"in_reply_to":"fa32b979_15ccd068","updated":"2015-06-24 09:48:11.000000000","message":"I don\u0027t have a firm answer because the devil is in the details.  In general though, my approach would be to look at the set of configs libvirt can conceptually support, and ensure we have coverage of all the aspects that Neutron would be expected to want to make use of.  ie, we\u0027d not just limit ourselves to designing what would satisfy current mechanisms - we\u0027d try to future proof ourselves by considering what might be needed in the future too and get that covered now, to minimize liklihood of changes in future too.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":225,"context_line":""},{"line_number":226,"context_line":"As alluded to in an earlier paragraph, the library will also need to define"},{"line_number":227,"context_line":"an interface for enabling the plug / unplug actions to be performed. This"},{"line_number":228,"context_line":"is a quite straightforward abstract python classs"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"::"},{"line_number":231,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_94dbf87b","line":228,"updated":"2015-06-24 02:55:54.000000000","message":"s/classs/class/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"The \u0027config\u0027 parameter passed in here will be an instance of the VIFConfig"},{"line_number":241,"context_line":"versioned object defined above."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"There will be at least one subclass of this VIFPlug class provided by each"},{"line_number":244,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":245,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_77a436a5","line":242,"updated":"2015-06-24 04:10:14.000000000","message":"I have a couple of issues here:\n\n- your VIFPlug subclass is usable by dint of being present on the system.  This effectively means that Nova will operate differently simply as a side effect of another class being installed.  I would prefer that you have to list the classes to be loaded or files to be imported in the config, so that it\u0027s not a side effect and also so that it\u0027s clear when an expected file is absent on startup.  Also so that anything calling this interface can\u0027t just load random crap into Nova.\n\n- I understand why you\u0027re suggesting a class name, but I wonder if the class should register a friendly name when it\u0027s loaded.\n\n- We should certainly mandate checking that the class to be used is of the right ABC.  (Also, if we change the fundamentals in future we can use a different ABC and identify whether additional behaviour uses the old or new interface to Nova.)\n\nhttps://review.openstack.org/#/c/191210/ may be unpalatable for its config fiddling, but if you set that aside I still think I had a better registration concept: a friendly name, explicit loading, and versioning of the plug mechanism\u0027s semantics (versus the parameters\u0027 format).","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"The \u0027config\u0027 parameter passed in here will be an instance of the VIFConfig"},{"line_number":241,"context_line":"versioned object defined above."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"There will be at least one subclass of this VIFPlug class provided by each"},{"line_number":244,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":245,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_6426b7cf","line":242,"in_reply_to":"fa32b979_77a436a5","updated":"2015-06-24 09:48:11.000000000","message":"As dan smith mentions, the obvious way to handle this is to register classes via stevedore, so we have a clear set of classes that are expected/permitted. \n\nIt is not mentioned in this spec version, but as discussed in the comments elsewhere, it looks like we\u0027d need to provide info about the available plugins to neutron, along with the VIF type, so it can determine whether it can satisfactorily operate with the Nova version.\n\nSo this spec will need updating to clarify this aspect.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":243,"context_line":"There will be at least one subclass of this VIFPlug class provided by each"},{"line_number":244,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":245,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":246,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":247,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":248,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":249,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_7e2c2602","line":246,"range":{"start_line":246,"start_character":3,"end_line":246,"end_character":32},"updated":"2015-06-23 17:29:49.000000000","message":"These should be loaded by stevedore I think. This interface will evolve over time as well, I assume, so some thinking needs to be done about how we know if a plugin we loaded is too new or old. For example, a given plugin will likely assume some version of VIFConfig being passed in. Perhaps define some way of determining what version of VIFConfig the plugin knew about at the time of writing and apply the same versioning rules to determine if our object is compatible with their assumptions?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":243,"context_line":"There will be at least one subclass of this VIFPlug class provided by each"},{"line_number":244,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":245,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":246,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":247,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":248,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":249,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_97753acc","line":246,"in_reply_to":"fa32b979_7e2c2602","updated":"2015-06-24 04:10:14.000000000","message":"Using stevedore sounds just lovely but aiui stevedore involves changing a file that is part of Nova (not config, but source) to make classes available.  If that is true, it defeats the object.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":243,"context_line":"There will be at least one subclass of this VIFPlug class provided by each"},{"line_number":244,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":245,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":246,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":247,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":248,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":249,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_ff049415","line":246,"in_reply_to":"fa32b979_97753acc","updated":"2015-06-24 09:48:11.000000000","message":"I don\u0027t believe it does need changing to the source - IIUC, the registration happens as the time pip installs the python code for the extension.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":247,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":248,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":249,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"},{"line_number":250,"context_line":"of a VIF port."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":253,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_8070a4a5","line":250,"updated":"2015-06-23 17:29:49.000000000","message":"Maybe it\u0027s just me, but I have a hard time understanding why for a given vif type and hypervisor, that we need this to be so pluggable. Could you maybe pick something and provide an example?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2048963cf322280ccd0eedda970b07d304457eb","unresolved":false,"context_lines":[{"line_number":247,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":248,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":249,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"},{"line_number":250,"context_line":"of a VIF port."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":253,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_037c9eb3","line":250,"in_reply_to":"fa32b979_8070a4a5","updated":"2015-06-23 17:48:20.000000000","message":"Yep, there are currently 4 VIF types:\n\n VIF_TYPE_IVS\n VIF_TYPE_IOVISOR\n VIF_TYPE_MIDONET\n VIF_TYPE_ETHERNET\n\nwhich all results in exactly the same configuration of the libvirt guest - they all use \u003cinterface type\u003d\"ethernet\"\u003e in the same way. The only difference between them is that they have different code running in their plug/unplug methods. This problem is only getting worse over time - we\u0027re seeing more \u0026 more VIF types proposed, which use the same libvirt configuration as an existing VIF type, but want different vendor commands run.\n\nBy de-coupling the VIF types from the plug/unplug implementation, we ensure the number of VIF types and the data passed between Neutron \u0026 Nova is well understood and defined in a small set of VIF types.  The vendors can then provide their own plugin to do their random vendor specific stuff, and not bottleneck on getting a new VIF type agreed and getting changes into the libvirt nova code to support it. They can use an existing VIF type and just point at their plugin code.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":252,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":253,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"},{"line_number":254,"context_line":"Nova teams), as any additions to data passed over the REST API must be reviewed"},{"line_number":255,"context_line":"and approved by project maintainers."},{"line_number":256,"context_line":""},{"line_number":257,"context_line":"So when a vendor wishes to create a new mechanism, they first decide which"},{"line_number":258,"context_line":"VIFConfig implementation(s) they need to target, and populate that with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_206f582c","line":255,"updated":"2015-06-23 17:29:49.000000000","message":"Presumably we also need sign-off from the Neutron team that this is a thing they want in their API. Because they (AFAIK) try to support non-nova consumers of Neutron, this API becomes a very nova-neutron-centric thing at this point.\n\nPerhaps nova (or this library), using a suitably new neutronclient, could pass an Accepts: header indicating that we\u0027d like an object in return?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2048963cf322280ccd0eedda970b07d304457eb","unresolved":false,"context_lines":[{"line_number":252,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":253,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"},{"line_number":254,"context_line":"Nova teams), as any additions to data passed over the REST API must be reviewed"},{"line_number":255,"context_line":"and approved by project maintainers."},{"line_number":256,"context_line":""},{"line_number":257,"context_line":"So when a vendor wishes to create a new mechanism, they first decide which"},{"line_number":258,"context_line":"VIFConfig implementation(s) they need to target, and populate that with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_c6532416","line":255,"in_reply_to":"fa32b979_206f582c","updated":"2015-06-23 17:48:20.000000000","message":"Yep, this certainly needs Neutron team buy-in, as this affects both projects.\n\nThis should still allow Neutron to work wiith other non-nova based callers - the only dependency is that the callers have to be able to use oslo.versionedobjects to interpret the API response. I don\u0027t think that\u0027s an unreasonable burden on callers, as it doesn\u0027t really force the caller to do anything special - we\u0027re just leveraging oslo.vo for its serialization format and versioning logic, which I think is something needed for this API regardless of whether Nova or something else is calling it.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":252,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":253,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"},{"line_number":254,"context_line":"Nova teams), as any additions to data passed over the REST API must be reviewed"},{"line_number":255,"context_line":"and approved by project maintainers."},{"line_number":256,"context_line":""},{"line_number":257,"context_line":"So when a vendor wishes to create a new mechanism, they first decide which"},{"line_number":258,"context_line":"VIFConfig implementation(s) they need to target, and populate that with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_37746efc","line":255,"in_reply_to":"fa32b979_c6532416","updated":"2015-06-24 04:10:14.000000000","message":"I think this is fine - we\u0027re explicitly negotiating with whatever-it-is about what binding types we will take (as a predecessor of this patch), and that negotiation has fallbacks, which I presume Dan B\u0027s reviewed for sanity.  The ultimate fallback is that XXX just passes a binding type that\u0027s recognised today, and prays that Nova will accept it, same as we do now...","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"When Nova asks Neutron to create the VIF, neutron returns the serialized"},{"line_number":267,"context_line":"VIFConfig class, which Nova loads. Nova compute manager passes this down"},{"line_number":268,"context_line":"to the virt driver implementation, which instantiates the class defined"},{"line_number":269,"context_line":"by the \u0027plug\u0027 attribute. It will then invoke either the \u0027plug\u0027 or \u0027unplug\u0027"},{"line_number":270,"context_line":"method depending on whether it is attaching or detaching a VIF to the"},{"line_number":271,"context_line":"guest instance.  The hypervisor driver will then configure the guest"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_9470d873","line":268,"updated":"2015-06-24 02:55:54.000000000","message":"Most of this spec reads like it\u0027s very specific to the vif stuff in the libvirt driver in nova, but this paragraph is talking about it being more or less generic for the other virt drivers (vmware, ironic, hyper-v and xen).  I honestly don\u0027t know how they all model this stuff either.  I get lost looking at the vmware vif stuff for example.  Are we sure this is as portable as we think for those other virt drivers?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"When Nova asks Neutron to create the VIF, neutron returns the serialized"},{"line_number":267,"context_line":"VIFConfig class, which Nova loads. Nova compute manager passes this down"},{"line_number":268,"context_line":"to the virt driver implementation, which instantiates the class defined"},{"line_number":269,"context_line":"by the \u0027plug\u0027 attribute. It will then invoke either the \u0027plug\u0027 or \u0027unplug\u0027"},{"line_number":270,"context_line":"method depending on whether it is attaching or detaching a VIF to the"},{"line_number":271,"context_line":"guest instance.  The hypervisor driver will then configure the guest"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_c278de80","line":268,"in_reply_to":"fa32b979_9470d873","updated":"2015-06-24 04:10:14.000000000","message":"So the answer to your question is that they all have the same concept: a binding_type (which is not hypervisor specific) and a plugging mechanism (which turns Neutron\u0027s nonspecific information into something that the specific hypervisor can do).  This is libvirt specific in its description but it does apply generally.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":265,"context_line":""},{"line_number":266,"context_line":"When Nova asks Neutron to create the VIF, neutron returns the serialized"},{"line_number":267,"context_line":"VIFConfig class, which Nova loads. Nova compute manager passes this down"},{"line_number":268,"context_line":"to the virt driver implementation, which instantiates the class defined"},{"line_number":269,"context_line":"by the \u0027plug\u0027 attribute. It will then invoke either the \u0027plug\u0027 or \u0027unplug\u0027"},{"line_number":270,"context_line":"method depending on whether it is attaching or detaching a VIF to the"},{"line_number":271,"context_line":"guest instance.  The hypervisor driver will then configure the guest"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_bf584c32","line":268,"in_reply_to":"fa32b979_c278de80","updated":"2015-06-24 09:48:11.000000000","message":"I\u0027ve tended to focus on libvirt, because the problem is an order of magnitude worse in libvirt than any of the other drivers. As ian says, they do generally work in the same kind of way, but obviously the plug/unplug logic for a particular VIF type will potentially be different for each hypervisor.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":271,"context_line":"guest instance.  The hypervisor driver will then configure the guest"},{"line_number":272,"context_line":"virtual machine using the data stored in the VIFConfig class."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"When a new Nova talks to an old Neutron, it will obviously be receiving the"},{"line_number":276,"context_line":"port binding data in the existing dict format. Nova will have to have some"},{"line_number":277,"context_line":"compatibility code to be able to support comsumption of the data in this"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_20d3d805","line":274,"updated":"2015-06-23 17:29:49.000000000","message":"Extra line here.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":271,"context_line":"guest instance.  The hypervisor driver will then configure the guest"},{"line_number":272,"context_line":"virtual machine using the data stored in the VIFConfig class."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"When a new Nova talks to an old Neutron, it will obviously be receiving the"},{"line_number":276,"context_line":"port binding data in the existing dict format. Nova will have to have some"},{"line_number":277,"context_line":"compatibility code to be able to support comsumption of the data in this"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_77d2f601","line":274,"in_reply_to":"fa32b979_20d3d805","updated":"2015-06-24 04:10:14.000000000","message":"Someone take the man\u0027s coffee away, he\u0027s had too much.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":287,"context_line":"new VIFConfig object model. With an explicit opt-in required, when an old"},{"line_number":288,"context_line":"Nova talks to new Neutron, Neutron will know to return data in the legacy"},{"line_number":289,"context_line":"format that Nova can still understand.  The obvious implication of this"},{"line_number":290,"context_line":"is that any newly developer Neutron mechanisms that rely on the new"},{"line_number":291,"context_line":"VIFCOnfig object model exclusively, will not work with legacy Nova"},{"line_number":292,"context_line":"deployments. This is not considered to be a significant problem, as the"},{"line_number":293,"context_line":"mis-match in Neutron/Nova versions is only a temporary problem as a cloud"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_3400ecaa","line":290,"updated":"2015-06-24 02:55:54.000000000","message":"s/developer/developed/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"629a0f9ffa05561e0824e16df43e1ad1276ed297","unresolved":false,"context_lines":[{"line_number":301,"context_line":""},{"line_number":302,"context_line":"In this new design, there will be the following relationships"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":" - VIF type \u003c-\u003e VIFConfig class - 1:1 - VIFConfig classes are direct"},{"line_number":305,"context_line":"   representation of each VIF type - a VIF type is simply the name"},{"line_number":306,"context_line":"   of the class used to represent the data."},{"line_number":307,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_f5fdacb1","line":304,"updated":"2015-06-23 20:35:39.000000000","message":"What will be the relationship between VIF type/VIFConfig_class and xml generating get_config_\u003cvif_type\u003e nova code? Will each type again have it\u0027s own get_config_yvif_type\u003e like method?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":312,"context_line":""},{"line_number":313,"context_line":" - VIF type \u003c-\u003e VIF plugins - 1:M - a single VIF type can be used with"},{"line_number":314,"context_line":"   multiple plugins. ie many mechanisms will use the same VIF type, but"},{"line_number":315,"context_line":"   each supply their own plugin implementation for host OS setup"},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"The split between VIF plugins and VIF types is key to the goal of"},{"line_number":318,"context_line":"limiting the number of new VIF types that are created over time."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_6306ca1d","line":315,"updated":"2015-06-23 17:29:49.000000000","message":"I feel like this is almost what I need to wrap my head around this. Still, as above, an example of a real neutron vif_type, mechanism, and plug that aren\u0027t always used together would close the loop I think.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":312,"context_line":""},{"line_number":313,"context_line":" - VIF type \u003c-\u003e VIF plugins - 1:M - a single VIF type can be used with"},{"line_number":314,"context_line":"   multiple plugins. ie many mechanisms will use the same VIF type, but"},{"line_number":315,"context_line":"   each supply their own plugin implementation for host OS setup"},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"The split between VIF plugins and VIF types is key to the goal of"},{"line_number":318,"context_line":"limiting the number of new VIF types that are created over time."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_7f6644ee","line":315,"in_reply_to":"fa32b979_54eb30dc","updated":"2015-06-24 09:48:11.000000000","message":"I did put an example in a comment earlier about how 4 VIF types all basically map to the same libvirt config, merely differing in their XML. I\u0027ll expand this in the next version of the spec.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":312,"context_line":""},{"line_number":313,"context_line":" - VIF type \u003c-\u003e VIF plugins - 1:M - a single VIF type can be used with"},{"line_number":314,"context_line":"   multiple plugins. ie many mechanisms will use the same VIF type, but"},{"line_number":315,"context_line":"   each supply their own plugin implementation for host OS setup"},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"The split between VIF plugins and VIF types is key to the goal of"},{"line_number":318,"context_line":"limiting the number of new VIF types that are created over time."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_54eb30dc","line":315,"in_reply_to":"fa32b979_6306ca1d","updated":"2015-06-24 02:55:54.000000000","message":"If there is an example added to the spec, I\u0027d use whatever happens with OVS since that\u0027s the reference impl in Neutron.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":323,"context_line":""},{"line_number":324,"context_line":"1. Do nothing. Continue with the current approach where every new Neutron"},{"line_number":325,"context_line":"   mechanism requires a change to Nova hypervisor VIF driver to support"},{"line_number":326,"context_line":"   its vendor specific plug/unplug actions. This will make no one happy."},{"line_number":327,"context_line":""},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"2. Return to the previous approach, where Nova allows loading of out"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_34c54c5b","line":326,"updated":"2015-06-24 02:55:54.000000000","message":"Support people will be happy since they will continue to be funded.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"7e47a6a0078a9c08578a1edd9cc7b4e32f6ff224","unresolved":false,"context_lines":[{"line_number":340,"context_line":"   In addition the libvirt driver has a set of classes for representing"},{"line_number":341,"context_line":"   the libvirt XML config of a guest, which need to be capable of"},{"line_number":342,"context_line":"   representing any VIF config for the guest. These are considered part"},{"line_number":343,"context_line":"   of the libvirt internal implementation and not a stable API."},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"   Thirdly, the libvirt VIF driver plugin API has changed in the past"},{"line_number":346,"context_line":"   and may change again in the future, and the data passed into it is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_2cce7f2d","line":343,"updated":"2015-06-23 14:35:53.000000000","message":"We still can have hooks in nova only for plug/unplug method and not the get_config.\nBut, yes it\u0027s doesn\u0027t answer to your third point","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"7e47a6a0078a9c08578a1edd9cc7b4e32f6ff224","unresolved":false,"context_lines":[{"line_number":355,"context_line":"   that is pretty similar to this previous approach. The key differences"},{"line_number":356,"context_line":"   and benefits of this spec, are that it defines a set of versioned"},{"line_number":357,"context_line":"   objects to hold the data that is passed to the 3rd party VIFPlug"},{"line_number":358,"context_line":"   implementation. The external VIFPlug implementation is only being"},{"line_number":359,"context_line":"   responsible for the host OS setup tasks - ie the plug/unplug"},{"line_number":360,"context_line":"   actions. The libvirt driver retains control over guest configuration"},{"line_number":361,"context_line":"   The VIFPlug driver is isolated from the internal impl and API design"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_273e988b","line":358,"updated":"2015-06-23 14:35:53.000000000","message":"It\u0027s possible that some mechanism driver needs to provide specific fields to the unplug/plug methods, not defined inside the default fields of the VIFConfigs object. It was possible to do that with the vif_script by providing a new key/value into the VIF_DETAILS dict.\n\nShould we address such usecases ?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"ffd26ae6d0343e78c6da28e257b86e8be9cedf4f","unresolved":false,"context_lines":[{"line_number":355,"context_line":"   that is pretty similar to this previous approach. The key differences"},{"line_number":356,"context_line":"   and benefits of this spec, are that it defines a set of versioned"},{"line_number":357,"context_line":"   objects to hold the data that is passed to the 3rd party VIFPlug"},{"line_number":358,"context_line":"   implementation. The external VIFPlug implementation is only being"},{"line_number":359,"context_line":"   responsible for the host OS setup tasks - ie the plug/unplug"},{"line_number":360,"context_line":"   actions. The libvirt driver retains control over guest configuration"},{"line_number":361,"context_line":"   The VIFPlug driver is isolated from the internal impl and API design"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_3471da76","line":358,"in_reply_to":"fa32b979_194adc26","updated":"2015-06-23 19:31:41.000000000","message":"I was thought about different extra information that could be useful for plug/unplug method. In fact these ones doesn\u0027t justify any extra plugin_metadata into the VIFObject. See:\n\n1) MTU\n\nFor example, thanks to this spec: https://github.com/openstack/neutron-specs/blob/master/specs/kilo/mtu-selection-and-advertisement.rst, neutron is able to get the mtu for each network.\n\nThe mtu information could be given by Neutron for the plug method. (e.g. to set the mtu on the tap device) ( Note:  It will allow to remove the deprecated network_device_mtu option in nova.conf.)\n\n- In fact, the mtu field should be added to Network(base.VersionedObject) class: https://github.com/berrange/os_vif/blob/object-model/os_vif/objects/network.py ? (and not into a plugin_metadata field of VIF object)\n\n- Maybe we should address this specific problem into an other spec ? \n\n2) Bridge name\n\nIf you consider VIF_TAP or VIF_VHOSTUSER, and you want to implement openvswitch like or linux bridge like, the plug method will need to know on which bridge you need to plug your device.\n\nThe bridge name could be given by Neutron for the plug method. ( Note: We should not have hard-corded name for the ovs bridge name and linux bridge name in the nova code. )\n\nSuch information is useless for the get_config method. As libvirt will not plug the interface into the bridge.\n\nIn fact there is already a bridge field into the Network Object:  https://github.com/berrange/os_vif/blob/object-model/os_vif/objects/network.py#L26. \n\n- Neutron should provide the bridge name into the Network object ?\n\n- Or into a bridge_name field of VIF Object (e.g. brname of  VIFBridge) ?\n\n(here we have some duplicated information issue I think)\n\n3) InterfaceID \n\nIf you consider the case of the ovs dpdk or ovs fp, you will need InterfaceID for the plug method, but this field is not including into VIFVHostUser:\nhttps://github.com/berrange/os_vif/blob/object-model/os_vif/objects/vif.py#L140\nbut it\u0027s the case for the VIFOpenVSwitch:\nhttps://github.com/berrange/os_vif/blob/object-model/os_vif/objects/vif.py#L71\n\nI think you want that the VIFObject only reflects the libvirt field of the xml, Thus having the ovs_interfaceid in the VIFVhostUser object doesn\u0027t make senses at all.\n\nAs ovs_interface is equals to the vif id (in the actual code), we still have this information in the VIFVHostUser object. So there are no need for a plugin_metadata.\n\n- Regarding ovs_interafaceid, Neutron should only provide the id field into the VIFObject or also duplicate this value into the interfaceid field of VIFOpenVSwitch  ? (here we have some duplicated information I think)","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"75de51573f9b30c4f72194f2dc6ede89ab7f1db1","unresolved":false,"context_lines":[{"line_number":355,"context_line":"   that is pretty similar to this previous approach. The key differences"},{"line_number":356,"context_line":"   and benefits of this spec, are that it defines a set of versioned"},{"line_number":357,"context_line":"   objects to hold the data that is passed to the 3rd party VIFPlug"},{"line_number":358,"context_line":"   implementation. The external VIFPlug implementation is only being"},{"line_number":359,"context_line":"   responsible for the host OS setup tasks - ie the plug/unplug"},{"line_number":360,"context_line":"   actions. The libvirt driver retains control over guest configuration"},{"line_number":361,"context_line":"   The VIFPlug driver is isolated from the internal impl and API design"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_194adc26","line":358,"in_reply_to":"fa32b979_273e988b","updated":"2015-06-23 14:52:40.000000000","message":"With the current list of VIF types we already have I didn\u0027t see any usage that would require such data, so I didn\u0027t attempt to address that need.\n\nWe could potentially add a\n\n  plugin_metadata: field.DictOfStringsField()\n\nwhich would be an opaque dict that is just passed through to the plug/unplug methods. ie it would be completely ignored / not interpreted by Nova / libvirt. It would be defined by the Neutron mechanism consumed by the Neutron nova plugin and nothing else.\n\nUnless we have an immediately compelling need for this though, I\u0027d rather leave it out. It is something we could add later if it turns out to really be needed.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"629a0f9ffa05561e0824e16df43e1ad1276ed297","unresolved":false,"context_lines":[{"line_number":355,"context_line":"   that is pretty similar to this previous approach. The key differences"},{"line_number":356,"context_line":"   and benefits of this spec, are that it defines a set of versioned"},{"line_number":357,"context_line":"   objects to hold the data that is passed to the 3rd party VIFPlug"},{"line_number":358,"context_line":"   implementation. The external VIFPlug implementation is only being"},{"line_number":359,"context_line":"   responsible for the host OS setup tasks - ie the plug/unplug"},{"line_number":360,"context_line":"   actions. The libvirt driver retains control over guest configuration"},{"line_number":361,"context_line":"   The VIFPlug driver is isolated from the internal impl and API design"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_d54bc8af","line":358,"in_reply_to":"fa32b979_3471da76","updated":"2015-06-23 20:35:39.000000000","message":"I\u0027ve also seen, that today e.g. sriov uses the vnic_type that is transmitted to nova to decide how the plug/unplug actions and the xml should look like. \nBut I guess considering this spec, neutron can be more precise in defining what it needs in future. So this attribute might not extend Maximes list. \n\nIs there anything else regarding vnic_type that should be considered for nova here? Or is this only neutron related?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":355,"context_line":"   that is pretty similar to this previous approach. The key differences"},{"line_number":356,"context_line":"   and benefits of this spec, are that it defines a set of versioned"},{"line_number":357,"context_line":"   objects to hold the data that is passed to the 3rd party VIFPlug"},{"line_number":358,"context_line":"   implementation. The external VIFPlug implementation is only being"},{"line_number":359,"context_line":"   responsible for the host OS setup tasks - ie the plug/unplug"},{"line_number":360,"context_line":"   actions. The libvirt driver retains control over guest configuration"},{"line_number":361,"context_line":"   The VIFPlug driver is isolated from the internal impl and API design"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_bfaccc9f","line":358,"in_reply_to":"fa32b979_d54bc8af","updated":"2015-06-24 09:48:11.000000000","message":"@andreas - regarding the vnic_type - this is really a bit of a hack, that allows one VIF type to represent two different VIF types at once. So in that scenario, my approach would be to just define the two separate VIF types, and have Neutron pass back the one it desires immediately, thus no need for the vnic_type attribute.\n\n@maxime - I would certainly see merit in MTU being part of the network object. It could equally be part of the common VIFConfig class, if we wanted to allow possibility of different MTUs on same network.\n\nI\u0027m not sure how to respond about the bridge name - will think about that a bit. Likewise for the interface ID. It is certainly an optiona that we could decide to include them in the VIFConfig classs, even if we don\u0027t strictly need them for libvirt config POV.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":365,"context_line":""},{"line_number":366,"context_line":""},{"line_number":367,"context_line":"3. Keep the current VIF binding approach, but include the name of an"},{"line_number":368,"context_line":"   executable program (script) that Nova will invoke to perform thte"},{"line_number":369,"context_line":"   plug/unplug actions."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"   This is approximately same as the proposal in this spec, it is just"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_d49ae061","line":368,"updated":"2015-06-24 02:55:54.000000000","message":"s/thte/the/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":368,"context_line":"   executable program (script) that Nova will invoke to perform thte"},{"line_number":369,"context_line":"   plug/unplug actions."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"   This is approximately same as the proposal in this spec, it is just"},{"line_number":372,"context_line":"   substituting in-process execution of python code, for out of process"},{"line_number":373,"context_line":"   execution of a (shell) script. In the case of scripts, the data from"},{"line_number":374,"context_line":"   the VIF port bindings must be provided to the script, and the proposal"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_34aa2c72","line":371,"updated":"2015-06-24 02:55:54.000000000","message":"s/same/the same/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":384,"context_line":"   python module which defines the versioned objects to represent the"},{"line_number":385,"context_line":"   port binding data, that can be shared between both Nova and Neutron"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"   It is believe that by defining a formal set of versioned objects"},{"line_number":388,"context_line":"   to represent the VIF port binding data, and a python abstract class"},{"line_number":389,"context_line":"   for the plug/unplug actions, we achieve a strict, clean and easily"},{"line_number":390,"context_line":"   extensible interface for the boudnary between Nova and Neutron,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_14e368da","line":387,"updated":"2015-06-24 02:55:54.000000000","message":"s/believe/believed/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"7e47a6a0078a9c08578a1edd9cc7b4e32f6ff224","unresolved":false,"context_lines":[{"line_number":391,"context_line":"   avoiding some of the problems inherant in serializing the data via"},{"line_number":392,"context_line":"   environment variables. ie the VIFPlug subclasses will stil get to"},{"line_number":393,"context_line":"   access the well defined VIFConfig class attributes, instead of"},{"line_number":394,"context_line":"   having to parse environment variables."},{"line_number":395,"context_line":""},{"line_number":396,"context_line":""},{"line_number":397,"context_line":"4. As per this spec, but keep all the VIFConfig classes in Nova instead"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_4ceae375","line":394,"updated":"2015-06-23 14:35:53.000000000","message":"Agree on this point. It make sense to have a formal API regarding the VIF port binding data. The vif_script was \"hiding\" the fact what we need a formal API for plug/unplug method by converting all information regarding VIF port binding into environment variable.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":410,"context_line":""},{"line_number":411,"context_line":"There is no change to the database data model."},{"line_number":412,"context_line":""},{"line_number":413,"context_line":"There will however be creation of a number of versioned objects to"},{"line_number":414,"context_line":"represent the port binding data for each VIF type."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_74f9947f","line":413,"updated":"2015-06-24 02:55:54.000000000","message":"But this happens in the os-vif library and doesn\u0027t have anything to do with the nova database schema, so shouldn\u0027t be a problem.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":410,"context_line":""},{"line_number":411,"context_line":"There is no change to the database data model."},{"line_number":412,"context_line":""},{"line_number":413,"context_line":"There will however be creation of a number of versioned objects to"},{"line_number":414,"context_line":"represent the port binding data for each VIF type."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_9f7ea819","line":413,"in_reply_to":"fa32b979_74f9947f","updated":"2015-06-24 09:48:11.000000000","message":"Sure, I just wanted to call out somewhere that we were going to be defining some new versioned objects - probably I could just do that under the REST API part instead","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":412,"context_line":""},{"line_number":413,"context_line":"There will however be creation of a number of versioned objects to"},{"line_number":414,"context_line":"represent the port binding data for each VIF type."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"REST API impact"},{"line_number":418,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_7740b6a5","line":415,"updated":"2015-06-24 04:10:14.000000000","message":"This makes this API (which, fwiw, is not actually Neutron specific) dependent on Oslo versioned object serialisations and potentially a bit hard to document given it\u0027s otherwise just a standard JSON REST API.  Do we care?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":412,"context_line":""},{"line_number":413,"context_line":"There will however be creation of a number of versioned objects to"},{"line_number":414,"context_line":"represent the port binding data for each VIF type."},{"line_number":415,"context_line":""},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"REST API impact"},{"line_number":418,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_df04307f","line":415,"in_reply_to":"fa32b979_7740b6a5","updated":"2015-06-24 09:48:11.000000000","message":"The oslo.vo serialization is still JSON based - there\u0027s just a little bit more metadata / structure to them - specifically instead of a dict of key/value pairs for the data, there is a dict which declares the object type, version \u0026 namespace, and a dict to hold the key/value data pairs. So there\u0027s a little more nesting, but its still ultimately a JSON representation of some nested dicts. So its a little more work to document, but not unreasonably complex.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":427,"context_line":""},{"line_number":428,"context_line":"For the new \"modern\" VIF types, the data format passed back by Neutron"},{"line_number":429,"context_line":"will use the oslo.versionedobjects serialization format, instead of just"},{"line_number":430,"context_line":"serializing a plain python dict. IOW, the data will be the result of the"},{"line_number":431,"context_line":"following API call"},{"line_number":432,"context_line":""},{"line_number":433,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_943d382d","line":430,"updated":"2015-06-24 02:55:54.000000000","message":"nit: you might want to write out \u0027In other words\u0027 since some of us might have had to look that up...","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25d5b6e0cb281920108ad7ac97a8d7f1dc7d19db","unresolved":false,"context_lines":[{"line_number":437,"context_line":"where cfg is the VIFConfig versioned object. This JSON data is thus"},{"line_number":438,"context_line":"formally specified and versioned, improving ability to evolve this"},{"line_number":439,"context_line":"in future releases."},{"line_number":440,"context_line":""},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Security impact"},{"line_number":443,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_23b1a247","line":440,"updated":"2015-06-23 17:29:49.000000000","message":"I think there is also something that needs to be explored here about old and new neutron/nova interactions in a post-this world. Meaning, in three cycles from now, when both nova and neutron are using this approach, how do we handle mismatches of the two when using the versioned object where the object has changed?\n\nIf neutron sends a newer VIFConfig than nova understands, nova will have no option but to fail. So, how do we handle that case during a transition? Do we pin the version at the neutron side in config? Do we enforce that neutron gets upgraded after nova (the opposite of how most people do it today I think)?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2048963cf322280ccd0eedda970b07d304457eb","unresolved":false,"context_lines":[{"line_number":437,"context_line":"where cfg is the VIFConfig versioned object. This JSON data is thus"},{"line_number":438,"context_line":"formally specified and versioned, improving ability to evolve this"},{"line_number":439,"context_line":"in future releases."},{"line_number":440,"context_line":""},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Security impact"},{"line_number":443,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_c6880474","line":440,"in_reply_to":"fa32b979_23b1a247","updated":"2015-06-23 17:48:20.000000000","message":"In this dependant spec:\n\n  https://review.openstack.org/#/c/190917/ \n\nwe\u0027re talking about adding a further piece of info to be sent from Nova to Neutron - the list of VIF types we support. Perhaps ratrher than just the VIF type, we should send the VIF type + version. eg\n\ninstead of just\n\n  VIFConfigBridge,VIFConfigOpenVSwitch\n\nwe should send\n\n  VIFConfigBridge\u003d1.5,VIFConfigOpenVSwitch\u003d1.3\n\nSo, if Neutron is using a newer version of the objects, it can call the obj_make_compatible() method on them to back level them to the version that Nova is able to accept.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":437,"context_line":"where cfg is the VIFConfig versioned object. This JSON data is thus"},{"line_number":438,"context_line":"formally specified and versioned, improving ability to evolve this"},{"line_number":439,"context_line":"in future releases."},{"line_number":440,"context_line":""},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Security impact"},{"line_number":443,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_b47f1cde","line":440,"in_reply_to":"fa32b979_c6880474","updated":"2015-06-24 02:55:54.000000000","message":"When I was thinking about doing essentially this same kind of thing in os-brick, namely convert the connection_info dict into a set of oslo.versionedobjects with subclasses, I wasn\u0027t sure how the version pinning would work either, so I\u0027m interested in how this turns out since we\u0027ll probably need to do similar with Cinder when nova is calling the os-initialize_connection API in Cinder.  I figured that since connection_info is stored in nova\u0027s block_device_mapping table as a serialized dict, when we move to objects we\u0027d just be serializing the version of the object in there too and when we need to do any interactions between nova and cinder (or maybe it just goes through os-brick), the version compat stuff would happen during that transmission.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":448,"context_line":"method implementations run a fairly arbitrary set of commands on the"},{"line_number":449,"context_line":"compute host. One difference though is that the Nova core team will no"},{"line_number":450,"context_line":"longer be responsible for reviewing that code, as it will be maintained"},{"line_number":451,"context_line":"exclusively by the Neutron mechanism vendor."},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"Notifications impact"},{"line_number":454,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_f4c7e40f","line":451,"updated":"2015-06-24 02:55:54.000000000","message":"Which is in stackforge which is a free for all, so buyer beware...","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":448,"context_line":"method implementations run a fairly arbitrary set of commands on the"},{"line_number":449,"context_line":"compute host. One difference though is that the Nova core team will no"},{"line_number":450,"context_line":"longer be responsible for reviewing that code, as it will be maintained"},{"line_number":451,"context_line":"exclusively by the Neutron mechanism vendor."},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"Notifications impact"},{"line_number":454,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_1f74d8fb","line":451,"in_reply_to":"fa32b979_0238069f","updated":"2015-06-24 09:48:11.000000000","message":"It seems we\u0027re agreed on the need to register the plugins in some way now. Ultimately though, we do rely on the python module having been explicitly installed on the compute node by the cloud admin. If a vendor gives the cloud admin code to deploy which runs \u0027rm -rf /\u0027, then that vendor is going to get themselves an awful reputation pretty quickly.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":448,"context_line":"method implementations run a fairly arbitrary set of commands on the"},{"line_number":449,"context_line":"compute host. One difference though is that the Nova core team will no"},{"line_number":450,"context_line":"longer be responsible for reviewing that code, as it will be maintained"},{"line_number":451,"context_line":"exclusively by the Neutron mechanism vendor."},{"line_number":452,"context_line":""},{"line_number":453,"context_line":"Notifications impact"},{"line_number":454,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_0238069f","line":451,"in_reply_to":"fa32b979_f4c7e40f","updated":"2015-06-24 04:10:14.000000000","message":"def plug():\n    subprocess.call(\u0027sudo rm -rf /\u0027)\n    print \u0027:)\u0027\n\nOf course, I can do just that from the Neutron side.  The problem is the loading of arbitrary code into Nova, but there are other interfaces that make that possible, I think.\n\nPer my comment above, though, I would prefer that it was explicitly done and not as a side-effect of a REST API parameter.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":468,"context_line":"Other deployer impact"},{"line_number":469,"context_line":"---------------------"},{"line_number":470,"context_line":""},{"line_number":471,"context_line":"When deploying new Neutron mechanisms, they will include a python module"},{"line_number":472,"context_line":"which must be deployed on each compute host. This provides the host OS"},{"line_number":473,"context_line":"plug/unplug logic that will be run when adding VIFs to a guest. It is"},{"line_number":474,"context_line":"anticipated that the various vendor tools for deploying openstack will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_54dfb0d5","line":471,"updated":"2015-06-24 02:55:54.000000000","message":"Is this the neutron mechanism driver code from the vendor repo that\u0027s in stackforge?  Just need to package that up for the one you\u0027re using and installed it on the compute node, if I\u0027m understanding you correctly.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":468,"context_line":"Other deployer impact"},{"line_number":469,"context_line":"---------------------"},{"line_number":470,"context_line":""},{"line_number":471,"context_line":"When deploying new Neutron mechanisms, they will include a python module"},{"line_number":472,"context_line":"which must be deployed on each compute host. This provides the host OS"},{"line_number":473,"context_line":"plug/unplug logic that will be run when adding VIFs to a guest. It is"},{"line_number":474,"context_line":"anticipated that the various vendor tools for deploying openstack will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_5fb1008e","line":471,"in_reply_to":"fa32b979_54dfb0d5","updated":"2015-06-24 09:48:11.000000000","message":"The nova plugin code is separate from the mechanism code, but provided by the same team. eg, \u003chand waving\u003eI\u0027d  expect   \u0027pip install neutron-myawesomenetwork\u0027 to install the neutron mechanism on neutron nodes, and \u0027pip install nova-vifplugin-myawesomenetwork\u0027 to install the corresponding plugin on nova compute nodes.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":483,"context_line":"object in the os-vif library that is shared between Neutron and Nova. This"},{"line_number":484,"context_line":"will involve defining a subclass of VIFConfig, and then implementing the"},{"line_number":485,"context_line":"logic in the Nova libvirt driver to handle this new configuration type."},{"line_number":486,"context_line":"Based on historical frequency of such additions in QEMU, it is expected"},{"line_number":487,"context_line":"that this will be a rare occurrance."},{"line_number":488,"context_line":""},{"line_number":489,"context_line":"When a vendor wishes to implement a new Neutron mechanism, they will have"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_9400d835","line":486,"updated":"2015-06-24 02:55:54.000000000","message":"Again, very specific to the libvirt driver and I\u0027m not sure how this all maps to vmware/hyperv/xen/ironic.  We might not care, I\u0027m just interested.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"7e47a6a0078a9c08578a1edd9cc7b4e32f6ff224","unresolved":false,"context_lines":[{"line_number":507,"context_line":""},{"line_number":508,"context_line":"  Daniel Berrange \u003cberrange@redhat.com\u003e irc:danpb"},{"line_number":509,"context_line":"  Brent Eagles \u003cbeagles@redhat.com\u003e irc: beagles"},{"line_number":510,"context_line":"  Andreas Scheuring"},{"line_number":511,"context_line":""},{"line_number":512,"context_line":"Work Items"},{"line_number":513,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_6c96c7f1","line":510,"updated":"2015-06-23 14:35:53.000000000","message":"As I have already helped on the vif_script, I will continue helping on os-vif by reviewing and testing against my out-of-tree mechanism driver (i.e. ovs-fp).","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":512,"context_line":"Work Items"},{"line_number":513,"context_line":"----------"},{"line_number":514,"context_line":""},{"line_number":515,"context_line":"1. Create a new os-vif python module in openstack and/or stackforge"},{"line_number":516,"context_line":""},{"line_number":517,"context_line":"2. Implement the VIFConfig abstract base class as a versioned object"},{"line_number":518,"context_line":"   using oslo.versionedobjects."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_748af4c0","line":515,"updated":"2015-06-24 02:55:54.000000000","message":"s/module/library or repo/\n\nThe word module here is confusing since it\u0027s an entirely new repo/pip which is going to need to be packaged up as a dependency of nova\u0027s.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"7e47a6a0078a9c08578a1edd9cc7b4e32f6ff224","unresolved":false,"context_lines":[{"line_number":520,"context_line":"3. Agree on and define the minimal set of VIF configurations that"},{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_2cb3df9b","line":523,"updated":"2015-06-23 14:35:53.000000000","message":"I have a look on the libvirt/vif.py. We have 12 VIF_TYPE different. Most of them have only specific code for plug/unplug. If the plug/unplug is remove from Nova, I think we can consolidate the number of VIF_TYPE around 6 in libvirt.\n\nSee: https://etherpad.openstack.org/p/libvirt_vif_consolidation","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"75de51573f9b30c4f72194f2dc6ede89ab7f1db1","unresolved":false,"context_lines":[{"line_number":520,"context_line":"3. Agree on and define the minimal set of VIF configurations that"},{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_b9c5f05c","line":523,"in_reply_to":"fa32b979_2cb3df9b","updated":"2015-06-23 14:52:40.000000000","message":"I came up with a slightly larger set when i was trying to spec this out in code last night https://github.com/berrange/os_vif/blob/object-model/os_vif/objects/vif.py  but we\u0027re both thinking the same way which is the important thing. How many we finally need will depend on how much we wish to make use of inheritance. I tended towards creating more subclasses with mandatory attributes, instead of fewer subclasses with many optional attributes.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":520,"context_line":"3. Agree on and define the minimal set of VIF configurations that"},{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_c20bfed3","line":523,"in_reply_to":"fa32b979_b9c5f05c","updated":"2015-06-24 04:10:14.000000000","message":"The code in there is a clear antipattern in any case and wants to be a bunch of classes based on an ABC, setting aside the rest - which is a side effect of what you\u0027re doing here and a reason for win totally aside of the rest.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"629a0f9ffa05561e0824e16df43e1ad1276ed297","unresolved":false,"context_lines":[{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."},{"line_number":527,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_55b3389a","line":524,"updated":"2015-06-23 20:35:39.000000000","message":"Along my comments before. I miss a step that describe how the existing xml generating methods will be treated. I know, they stay in nova, but will they be consolidated along with the vif_types or will there be a master logic handling all types?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"91f9f72fc3cd39684300bf10e6ce934a223f47d6","unresolved":false,"context_lines":[{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."},{"line_number":527,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_df18b086","line":524,"in_reply_to":"fa32b979_55b3389a","updated":"2015-06-24 09:48:11.000000000","message":"I\u0027ve tried to avoid getting into libvirt code work here, but obviously for each new VIF type we have there will be some code in libvirt to generate XML for it. I\u0027ve not really considered what that\u0027d look like, since its pretty minimal code and doesn\u0027t have much of an impact on the big concepts we\u0027re debating in this spec.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ed24ca25951436e81d0e0581a19a1ef23d913a58","unresolved":false,"context_lines":[{"line_number":521,"context_line":"   need to be supported. This is approximately equal to the number"},{"line_number":522,"context_line":"   of different libvirt XML configs, plus a few for other virt"},{"line_number":523,"context_line":"   hypervisors"},{"line_number":524,"context_line":""},{"line_number":525,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":526,"context_line":"   in step 3."},{"line_number":527,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_82fad6bb","line":524,"in_reply_to":"fa32b979_55b3389a","updated":"2015-06-24 04:10:14.000000000","message":"Per above, they ought to be on the VIF classes.  But we don\u0027t want them overriding by loaded subclasses so it becomes a bit tricky...\n\n(And we\u0027ve strayed into libvirtness, but the same comment applies to the other HVs.)","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":532,"context_line":"   VIF port data in either the legacy dict format or as a VIFConfig"},{"line_number":533,"context_line":"   object instance"},{"line_number":534,"context_line":""},{"line_number":535,"context_line":"7. Extend Nova/Neutron REST inteface so that Nova is able to request"},{"line_number":536,"context_line":"   use of the VIFConfig data format"},{"line_number":537,"context_line":""},{"line_number":538,"context_line":"8. Add code to Nova to convert the legacy dict format into the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_34a78c51","line":535,"updated":"2015-06-24 02:55:54.000000000","message":"s/inteface/interface/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":541,"context_line":"9. Convert the Neutron mechanisms to be able to use the new VIFConfig"},{"line_number":542,"context_line":"   object model"},{"line_number":543,"context_line":""},{"line_number":544,"context_line":"10. Profit"},{"line_number":545,"context_line":""},{"line_number":546,"context_line":"Dependencies"},{"line_number":547,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_d46e60ff","line":544,"updated":"2015-06-24 02:55:54.000000000","message":"10. ???\n\n11. Profit!\n\nhttp://lundstrj.files.wordpress.com/2012/02/underpants-gnomes.jpg\n\nCan you get that in here via ascii art please?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":546,"context_line":"Dependencies"},{"line_number":547,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":548,"context_line":""},{"line_number":549,"context_line":"The key dependancy is to have collaboration between the Nova and"},{"line_number":550,"context_line":"Neutron teams in setting up the new os-vif python project, and"},{"line_number":551,"context_line":"defining the VIFConfig object model and VIFPlug interface."},{"line_number":552,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_547b30be","line":549,"updated":"2015-06-24 02:55:54.000000000","message":"s/dependancy/dependeny/","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":566,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":567,"context_line":""},{"line_number":568,"context_line":"The current gate CI system includes cover for some of the Neutron"},{"line_number":569,"context_line":"mechanisms. As and when both Neutron and Nova support the new"},{"line_number":570,"context_line":"design, the current CI system will automatically start to test"},{"line_number":571,"context_line":"its operation."},{"line_number":572,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_14504831","line":569,"updated":"2015-06-24 02:55:54.000000000","message":"s/As/If/ ?","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"677e9bca83952cd9e91278e1f378273a451bf358","unresolved":false,"context_lines":[{"line_number":582,"context_line":"will all be developer facing, so can be done as simple docs inside the"},{"line_number":583,"context_line":"respective python projects."},{"line_number":584,"context_line":""},{"line_number":585,"context_line":"There may be some specific release notes required to advise cloud admins"},{"line_number":586,"context_line":"of any considerations during upgrade, but this should be minimal"},{"line_number":587,"context_line":""},{"line_number":588,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_1437e8ff","line":585,"updated":"2015-06-24 02:55:54.000000000","message":"Well, if there are config pins for version compat or something that will need to be documented, along with making sure any new dependencies are put down on the compute node - unless nova\u0027s requirements.txt just calls out os-vif and that pulls in most of the meat, but it sounds like the neutron mechanism stuff still has to be laid down depending on which you\u0027re using.  Maybe that\u0027s no different for people deploying neutron today after things were split out to stackforge though.","commit_id":"771a5a59334e5e56b3bf7a7c32d41c13d734c0b2"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":22,"context_line":"and Neutron to obtain a dict of port binding metadata. Nova passes this"},{"line_number":23,"context_line":"along to the virt drivers which have a set of classes for dealing with"},{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_03c7d745","line":25,"updated":"2015-07-01 09:09:44.000000000","message":"bit worried about the libvirt specific-ness here, it would be good to make this more general.\n\nhaving said that, libvirt has the most drivers right now, so its a good place to start.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8a496e014e97e8e08574b7bc38ff3385a937a3c9","unresolved":false,"context_lines":[{"line_number":22,"context_line":"and Neutron to obtain a dict of port binding metadata. Nova passes this"},{"line_number":23,"context_line":"along to the virt drivers which have a set of classes for dealing with"},{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_a848a42e","line":25,"in_reply_to":"ba3cc151_03c7d745","updated":"2015-11-03 15:01:35.000000000","message":"I am happy about that now.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"93036577089fb8593f0fd3c0217d43fd2742a890","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1a26ad4f_7e6baef1","line":27,"updated":"2015-11-02 10:49:07.000000000","message":"Although there now appears to be a broad consensus behind this spec (including my own +1), I\u0027d really appreciate it if the spec also explicitly reviewed _why_ Nova deals with VIF plugging at all.  In other words, why is Nova responsible for running VIF plug and unplug code - even if this evolves to be via the os-vif library - instead of Neutron?\n\nTo be clear, I\u0027m not questioning Nova\u0027s ownership of the get_config; that clearly needs to be Nova, as it feeds into the hypervisor spec.  Just the plug and unplug logic.\n\n(I _think_, from when I\u0027ve raised this in the past, that the arguments are:\n\n1. It\u0027s nice for Nova to do VIF plugging because it allows Neutron backends that don\u0027t have an agent at all on the compute node.\n\n2. VIF plugging needs to be hypervisor-dependent, therefore it\u0027s in Nova.\n\nIf those are the _only_ arguments, then I have to say that I\u0027m not sure they\u0027re strong enough to justify the complexity of the new os-vif approach, and I suspect that it would be simpler to move the responsibility for VIF plug/unplug to Neutron.  In particular I\u0027d counter (2) by saying that if there are M hypervisors and N VIF types, it\u0027s no worse to have hypervisor-dependent code in Neutron than it is to have VIF-dependent code in Nova; and in practice it\u0027s a lot better, because new hypervisor types are (I guess) added much more rarely than new VIF types, and because many Neutron backends only support libvirt anyway.\n\nHowever, probably there are other arguments - but then I think that it is important for this spec to enumerate and review them.)","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"4a1544dcfef3918716036560dc0a6b9855718d2b","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1a26ad4f_b5ccefbb","line":27,"in_reply_to":"1a26ad4f_7e6baef1","updated":"2015-11-02 20:26:36.000000000","message":"\u003eand I suspect that it would be simpler to move the responsibility for VIF plug/unplug to Neutron.\n\nWhat evidence do you have that this will be the case? How would Neutron ever test this code without a strong dependency on Nova?\n\n\u003eit\u0027s no worse to have hypervisor-dependent code in Neutron than it is to have VIF-dependent code in Nova\n\nThe VIF is not managed by Neutron so they aren\u0027t equivalent. The VIF is the network interface of the virtual machine. Neutron\u0027s responsibility is just to get traffic to the VIF.\n\nFor an analogy in the physical world, do you expect your switch vendor to provide you drivers for all of the network interfaces?\n\nWhat you are suggesting would require every Neutron backend to re-implement all of the VIF plugging code in an agent on the compute node. The fact that there might be some VMware hypervisor code that would have to live in the OVN/OVS repo should be a clear indicator that something is broken.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"757f0d67bd08f3a3276bf1161890287f3ede6e62","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_5b20ef49","line":27,"in_reply_to":"1a26ad4f_b5ccefbb","updated":"2015-11-03 11:07:40.000000000","message":"\u003e What evidence do you have that this will be the case?\n\nWell, strictly none, I\u0027m just speculating at the moment.  However, taking the Calico backend as an example:\n\n- the VIF plug logic (for VIF_TYPE_TAP) is just \u0027linux_net.create_tap_dev(dev, mac); linux_net._set_device_mtu(dev)\u0027\n\n- we have an agent that is told about that TAP interface (+ its VM and IP address etc.), waits for it to appear, and then does stuff like programming a route through it\n\n- I believe it would be trivial for our agent also to do the effect of \u0027linux_net.create_tap_dev(dev, mac); linux_net._set_device_mtu(dev)\u0027, instead of Nova doing this.\n\nIn comparison with that, it seems to me that os-vif is a lot more complex.\n\n\u003e How would Neutron ever test this code without a strong dependency on Nova?\n\nI don\u0027t understand the problem.  In the Calico example just mentioned, there wouldn\u0027t even be any core Neutron code to test.  Calico-specific testing would obviously test that the TAP interface had appeared and been correctly programmed.\n\n\u003e The VIF is not managed by Neutron so they aren\u0027t equivalent. The VIF is the network interface of the virtual machine. Neutron\u0027s responsibility is just to get traffic to the VIF.\n\nPerhaps I\u0027m missing something, but this sounds to me like just a restatement of the status quo.  My question is: is there a strong reason why it has to be that way?\n\n\u003e For an analogy in the physical world, do you expect your switch vendor to provide you drivers for all of the network interfaces?\n\nOK, I think I may be getting your point now - although I\u0027m not sure it matches the reality of all of the VIF plug/unplug code in Nova today...\n\nI think you\u0027re saying that it\u0027s correct and useful that, on every kind hypervisor, there should be some kind of VIF abstraction, and that it\u0027s Nova\u0027s job to manage one side of that abstraction, and Neutron\u0027s job to work with the other side.  E.g. for libvirt, the abstraction is the Linux netdev, and so Nova should be responsible for the creation of that netdev.\n\nI could buy that, but the trouble is that there\u0027s lots of plug code that goes beyond that, and does things like connecting that netdev into a Linux or OVS bridge, or executing some backend-specific ...ctl command on the netdev.  That\u0027s why the number of VIF types is larger than the number of distinct get_config patterns.\n\n\u003e What you are suggesting would require every Neutron backend to re-implement all of the VIF plugging code in an agent on the compute node.\n\nYes.  I am suggesting that that might be a lot simpler than the os-vif plan.\n\n\u003e The fact that there might be some VMware hypervisor code that would have to live in the OVN/OVS repo should be a clear indicator that something is broken.\n\nNot sure I\u0027m seeing the point here - please could you expand?","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"fd1aef3c21b816a8b761d5a7c94aa34f800e2047","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_a66d3ece","line":27,"in_reply_to":"1a26ad4f_b5ccefbb","updated":"2015-11-03 11:26:36.000000000","message":"I don\u0027t believe it would be significantly simpler for Neutron to have an agent on the compute hosts. We would still need to have an os-vif library to formalize the data passed between Neutron \u0026 Nova for the purposes of configuration of libvirt guest XML (or other hypervisor equivalent). We still need to define a versioning mechanism for VIFs so that it is possible to do incremental upgrades of compute nodes, without having to lock-step upgrade Neutron + mechanisms.\n\nSince Neutron does not currently have an agent on every node, it would have to define a new agent and message bus protocol to communicate with it, and deal with versioning too, so that you can upgrade the agent without upgrading neutron \u0026 vica-verca. The agent that Neutron provided would still have to provide some kind of plugin facility so that the out of tree mechanisms can provide their own plug/unplug code to run.\n\nUtimately I believe you just end up with an almost identical architecture to what is being proposed here. The only real difference is that in this design, Neutron is just leveraging Nova to invoke the plug/unplug code, instead of providing its own agent + messagebus. So I think this design we have here is actually simpler on balance, as it avoids Neutron having to build a parallel agent \u0026 message bus setup on every compute node.\n\nGiven this I really don\u0027t see any value in re-designing the proposal yet again - it\u0027d likely just serve to delay the end result by yet another release cycle for no obvious win.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"8cca2559c556b93317ff4f8aa0ebce58fb0e3189","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_1171a3e0","line":27,"in_reply_to":"fa80f949_5b20ef49","updated":"2015-11-04 19:09:41.000000000","message":"\u003ePerhaps I\u0027m missing something, but this sounds to me like just a restatement of the status quo. My question is: is there a strong reason why it has to be that way?\n\nSeparation of concerns. What you are suggesting would require logic for detecting huge pages support for vhost unix sockets, etc. That is hypervisor feature detection, compute node operating system configuration detection, and hardware detection. Neutron does not manage hypervisors. If we were fine with a monolithic project that looked at everything that we would just roll neutron back into nova network.\n\n\n\u003eI don\u0027t understand the problem. In the Calico example just mentioned, there wouldn\u0027t even be any core Neutron code to test. Calico-specific testing would obviously test that the TAP interface had appeared and been correctly programmed.\n\nWe would have a giant heap of hypervisor code in Neutron that is untestable without installing a bunch of hypervisors.\n\n\u003eNot sure I\u0027m seeing the point here - please could you expand?\n\nWhat you are suggesting is taking generic networking projects (e.g. OVN/OVS, or, for a vendor example, Big Cloud Fabric) and forcing them to adopt a bunch of openstack-specific code for Nova wiring. Right now there is a clean demarcation of the virtual switch that means that anything that plugs into the switch can be managed in a consistent way (e.g. OpenStack, Docker, Cloudstack). However, if they become responsible for creating network interfaces, they have to understand how every one of those projects expects interfaces to be wired up.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"c42d167df87c9db156a4e84a45177c7839bfab29","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_f1589ffc","line":27,"in_reply_to":"fa80f949_a134484a","updated":"2015-11-04 18:50:47.000000000","message":"\u003eFWIW several Neutron implementations already have an agent on each compute host. However it is true that they don\u0027t all have this.\n\n\nThis on it\u0027s own makes it infeasible to go this route. It would be a backwards-incompatible major architecture change to Nova-Neutron interactions.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"bf09594696897b38c2ff25c1f39daf8f63ef1419","unresolved":false,"context_lines":[{"line_number":24,"context_line":"different VIF types. In the libvirt case, each class has three methods,"},{"line_number":25,"context_line":"one for building the libvirt XML config, one for performing host OS config"},{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_a134484a","line":27,"in_reply_to":"fa80f949_a66d3ece","updated":"2015-11-03 12:06:48.000000000","message":"Thanks Dan.\n\nMy main concern here was to ensure that there wasn\u0027t a simpler possibility here that had been missed, and as part of that to check the reasons for Nova being responsible for VIF plug/unplug.  It appears that we\u0027re nearly done on those points now.  However I do still have doubts about some of your detailed points...\n\n\u003e I don\u0027t believe it would be significantly simpler for Neutron to have an agent on the compute hosts.\n\nFWIW several Neutron implementations already have an agent on each compute host.  However it is true that they don\u0027t all have this.\n\n\u003e We would still need to have an os-vif library to formalize the data passed between Neutron \u0026 Nova for the purposes of configuration of libvirt guest XML (or other hypervisor equivalent). We still need to define a versioning mechanism for VIFs so that it is possible to do incremental upgrades of compute nodes, without having to lock-step upgrade Neutron + mechanisms.\n\nIf VIF types were 1:1 with guest XML patterns, I suggest it would be maintainable to represent those with VIF_TYPE_* constants as the current code does.  (To be clear, we\u0027d first need to transition to a 1:1 situation, by deleting VIF types like VIF_TYPE_MIDONET - in that case using VIF_TYPE_TAP instead, and moving the \u0027mm-ctl ...\u0027 invocation to the MidoNet agent.  After that I suggest it would be sustainably rare for people to want to add new VIF types, and hence reasonable to process such changes within the Nova project.)\n\nBut perhaps there are other versioning / upgrade / negotiation problems that the os-vif plan helps with, and which I haven\u0027t understood yet...\n\n\u003e Since Neutron does not currently have an agent on every node, it would have to define a new agent and message bus protocol to communicate with it, and deal with versioning too, so that you can upgrade the agent without upgrading neutron \u0026 vica-verca.\n\nStill, I guess that it will be much easier to handle such versioning / upgrade issues within a particular focussed project - typically just within a particular networking-xxx backend project, because the communication we are talking about here will be between the backend\u0027s server plugin and its agent - than cross-project between Nova, os-vif and Neutron.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"bcbfda31d52d357fcdd8b181648e305e9071b8cf","unresolved":false,"context_lines":[{"line_number":26,"context_line":"tasks related to plugging a VIF and one for performing host OS config"},{"line_number":27,"context_line":"tasks related to unplugging a VIF."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Currently, whenever a new Neutron mechanism is created, this results in"},{"line_number":30,"context_line":"the definition of a new VIF type, and the addition of a new VIF class to"},{"line_number":31,"context_line":"the libvirt driver to support it. Due to the wide variety of vendors,"},{"line_number":32,"context_line":"there is a potentially limitless number of Neutron mechanisms that need"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_063f37b5","line":29,"updated":"2015-06-29 20:02:16.000000000","message":"Nit: mechanism driver? Could also be a monolithic plugin, the terminology here seems to favor ML2.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"bcbfda31d52d357fcdd8b181648e305e9071b8cf","unresolved":false,"context_lines":[{"line_number":31,"context_line":"the libvirt driver to support it. Due to the wide variety of vendors,"},{"line_number":32,"context_line":"there is a potentially limitless number of Neutron mechanisms that need"},{"line_number":33,"context_line":"to be dealt with over time. Conversely the number of different libvirt"},{"line_number":34,"context_line":"XML configurations is quite small and well defined. There are sometimes"},{"line_number":35,"context_line":"new libvirt XML configs defined, as QEMU gains new network backends, but"},{"line_number":36,"context_line":"this is fairly rare. Out of 15 different VIF types supported by libvirt\u0027s"},{"line_number":37,"context_line":"VIF driver today, there are only 5 distinct libvirt XML configurations"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_c65f0f0d","line":34,"updated":"2015-06-29 20:02:16.000000000","message":"No-action-required: This seems to hint that each of these mechanism drivers would be better served by adding support into libvirt for their plug/unplug operations.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a6a1ca7ee85b3a1a17d06707a7b594a3d136a263","unresolved":false,"context_lines":[{"line_number":37,"context_line":"VIF driver today, there are only 5 distinct libvirt XML configurations"},{"line_number":38,"context_line":"required. These are illustrated in"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"  https://wiki.openstack.org/wiki/LibvirtVIFTypeXMLConfigs"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The problem with this architecture is that the Nova libvirt maintainers"},{"line_number":43,"context_line":"have task of maintaining the plug/unplug code in the VIF drivers, which"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_de15ef3f","line":40,"updated":"2015-07-01 12:15:25.000000000","message":"The above is awesomesauce. Thank you!","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":37,"context_line":"VIF driver today, there are only 5 distinct libvirt XML configurations"},{"line_number":38,"context_line":"required. These are illustrated in"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"  https://wiki.openstack.org/wiki/LibvirtVIFTypeXMLConfigs"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The problem with this architecture is that the Nova libvirt maintainers"},{"line_number":43,"context_line":"have task of maintaining the plug/unplug code in the VIF drivers, which"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_a93e8589","line":40,"in_reply_to":"fa32b979_de15ef3f","updated":"2015-07-10 02:36:18.000000000","message":"+1","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a6a1ca7ee85b3a1a17d06707a7b594a3d136a263","unresolved":false,"context_lines":[{"line_number":46,"context_line":"having a lock-step change in Nova."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"A second related problem, is that the format of the data passed between"},{"line_number":49,"context_line":"Nova and Neutron for the VIF port binding is fairly loosely defined. There"},{"line_number":50,"context_line":"is no versioning of the information passed between them and no agreed formal"},{"line_number":51,"context_line":"specification of what the different fields mean. This data is used both to"},{"line_number":52,"context_line":"generate the libvirt XML config and to control the logic of the plug/unplug"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_fe3793e0","line":49,"updated":"2015-07-01 12:15:25.000000000","message":"That would be an understatement :)","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f5e2a608886cc5d2b3f6c468de59e883bdfb86a8","unresolved":false,"context_lines":[{"line_number":64,"context_line":"Project Priority"},{"line_number":65,"context_line":"-----------------"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"De-gross-ification of networking ? \u003c/joke\u003e"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Proposed change"},{"line_number":70,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_23cbfba6","line":67,"updated":"2015-07-01 08:42:06.000000000","message":"So it does fit into things we said would be a priority if we can get someone to work on them, so we might want to promote this one.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8a496e014e97e8e08574b7bc38ff3385a937a3c9","unresolved":false,"context_lines":[{"line_number":64,"context_line":"Project Priority"},{"line_number":65,"context_line":"-----------------"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"De-gross-ification of networking ? \u003c/joke\u003e"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Proposed change"},{"line_number":70,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_c8dc0849","line":67,"in_reply_to":"ba3cc151_03f59781","updated":"2015-11-03 15:01:35.000000000","message":"We should probably drop this section now.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":64,"context_line":"Project Priority"},{"line_number":65,"context_line":"-----------------"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"De-gross-ification of networking ? \u003c/joke\u003e"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Proposed change"},{"line_number":70,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_03f59781","line":67,"in_reply_to":"ba3cc151_23cbfba6","updated":"2015-07-01 09:09:44.000000000","message":"http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html#priorities-without-a-clear-plan","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"bcbfda31d52d357fcdd8b181648e305e9071b8cf","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Inspired by the os-brick library effort started by the Cinder project, the"},{"line_number":73,"context_line":"proposal involves creation of a new library module that will be jointly"},{"line_number":74,"context_line":"developed by the Neutron \u0026 Nova teams, for consumption by both projects."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"This proposal is describing an architecture with the following high level"},{"line_number":77,"context_line":"characteristics \u0026 split of responsibilities"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_c6b62f3d","line":74,"updated":"2015-06-29 20:02:16.000000000","message":"++, this will be a win for both sides of this equation!","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Inspired by the os-brick library effort started by the Cinder project, the"},{"line_number":73,"context_line":"proposal involves creation of a new library module that will be jointly"},{"line_number":74,"context_line":"developed by the Neutron \u0026 Nova teams, for consumption by both projects."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"This proposal is describing an architecture with the following high level"},{"line_number":77,"context_line":"characteristics \u0026 split of responsibilities"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_631343b9","line":74,"in_reply_to":"ba3cc151_c6b62f3d","updated":"2015-07-01 09:09:44.000000000","message":"I have a strong preference here that we follow the oslo model of having incubator style usage, while we get the interface for the library stable.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"bcbfda31d52d357fcdd8b181648e305e9071b8cf","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":" - Definition of VIF types and associated config metadata."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"     * Owned jointly by Nova and Neutron core teams"},{"line_number":82,"context_line":"     * Code shared in os-vif library"},{"line_number":83,"context_line":"     * Ensures core teams have 100% control over data on"},{"line_number":84,"context_line":"       the REST API"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_6682c354","line":81,"updated":"2015-06-29 20:02:16.000000000","message":"Nit: core reviewer","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"\t    # Port profile metadata  - needed for network modes"},{"line_number":136,"context_line":"\t    # like OVS, VEPA, etc"},{"line_number":137,"context_line":"\t    profile: ObjectField(\"VIFProfile\")"},{"line_number":138,"context_line":"        }"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_30c5ea09","line":137,"updated":"2015-06-26 03:54:23.000000000","message":"Hard tabs in the lines you added ;)","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":134,"context_line":""},{"line_number":135,"context_line":"\t    # Port profile metadata  - needed for network modes"},{"line_number":136,"context_line":"\t    # like OVS, VEPA, etc"},{"line_number":137,"context_line":"\t    profile: ObjectField(\"VIFProfile\")"},{"line_number":138,"context_line":"        }"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_693ddd2b","line":137,"in_reply_to":"fa32b979_30c5ea09","updated":"2015-07-10 02:36:18.000000000","message":"will the VIF profile object play the same role as the binding:profile in the current neutron port bindings extension?\n\nhttps://github.com/openstack/neutron/blob/master/neutron/extensions/portbindings.py#L30-33\n\nif so do we also need a \ndetails: ObjectField(\"VIFDetails\")\nfield?\n\nsee https://github.com/openstack/neutron/blob/master/neutron/extensions/portbindings.py#L23-26","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"1616661657b0ab5913ca268fafb466a5dcf559be","unresolved":false,"context_lines":[{"line_number":162,"context_line":"  https://wiki.openstack.org/wiki/LibvirtVIFTypeXMLConfigs"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"We can see that IVS, IOVISOR, MIDONET and VROUTER all use the same"},{"line_number":165,"context_line":"libvirt type\u003dethernet configuration, but different plug scripts."},{"line_number":166,"context_line":"Similarly there is significant overlap between VIFs that use"},{"line_number":167,"context_line":"type\u003dbridge, but with different plug scripts."},{"line_number":168,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_88adc932","line":165,"updated":"2015-06-25 14:35:32.000000000","message":"I don\u0027t want it to derail or detract focus from getting this spec approved, but I\u0027ve raised several times the point that libvirt apparently regards type\u003dethernet as deprecated, and would very much appreciate hearing your view on that.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c25087bd5660cdceac7fb298258d28bf4e96ae73","unresolved":false,"context_lines":[{"line_number":162,"context_line":"  https://wiki.openstack.org/wiki/LibvirtVIFTypeXMLConfigs"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"We can see that IVS, IOVISOR, MIDONET and VROUTER all use the same"},{"line_number":165,"context_line":"libvirt type\u003dethernet configuration, but different plug scripts."},{"line_number":166,"context_line":"Similarly there is significant overlap between VIFs that use"},{"line_number":167,"context_line":"type\u003dbridge, but with different plug scripts."},{"line_number":168,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_43bd62af","line":165,"in_reply_to":"fa32b979_88adc932","updated":"2015-06-25 14:40:39.000000000","message":"We have historically disliked and thus deprecated type\u003dethernet for two reasons\n\n- It is a complete black box, so libvirt has little ability to verify guest setup across migration\n- It (often) requires QEMU to be run with elevated privileges (at least CAP_SYS_ADMIN) but in practice people run it as root in order to launch the setup scripts.\n\nThe latter point is the big reason we strongly discourage its usage. In openstack VIFs though, I don\u0027t think any currently rely on QEMU being able to execute the ifup script itself. So in that case it is palatable to have openstack using that config. Upstream we\u0027re trying to move the ifup script handling out of QEMU and into libvirt to solve this privilege elevation problem","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":195,"context_line":"is running a newer version of the os-vif library than is installed"},{"line_number":196,"context_line":"on the Nova compute host. Second, in addition to the list of VIF"},{"line_number":197,"context_line":"types, Nova will also need to provide a list of installed plugins"},{"line_number":198,"context_line":"along with their versions."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"So approximately the following set of objects would be defined to"},{"line_number":201,"context_line":"represent the new VIF types. It is expected that the result of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_f0e542a4","line":198,"updated":"2015-06-26 03:54:23.000000000","message":"I wonder about this.  (Sorry, I lost some review comments on the previous version.)  I think you need two things:\n\n1. the base binding type\n2. The VIF plug extension\n\nI *don\u0027t* think they\u0027re 1:1, in fact; you could have multiple plug types on one base binding type.  It just happens that each one is used by precisely one driver, but I can probably, if I put my mind to it, come up with a way to use different drivers for different Neutron networks so I don\u0027t think you can avoid loading multiple of these on the same binding type - in which case their names should make the transition.\n\nAlternatively you can just make a new binding type name for the type with a plug driver attached, but you might have namespace conflicts when you do this.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"2cd84ad0ccad3397a063fc18cff89da49bf99642","unresolved":false,"context_lines":[{"line_number":195,"context_line":"is running a newer version of the os-vif library than is installed"},{"line_number":196,"context_line":"on the Nova compute host. Second, in addition to the list of VIF"},{"line_number":197,"context_line":"types, Nova will also need to provide a list of installed plugins"},{"line_number":198,"context_line":"along with their versions."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"So approximately the following set of objects would be defined to"},{"line_number":201,"context_line":"represent the new VIF types. It is expected that the result of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_593772b0","line":198,"in_reply_to":"ba3cc151_95aceeee","updated":"2015-06-29 13:56:19.000000000","message":"In future VIF type is simply going to be the name of the VIFConfig class. There is a M:N relationship between standardized VIF config and vendor provided VIF plugin. See line 380 for full description of the relationships, and thus why we have 2 independant lists to provide to Neutron","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c20e02ffbd1d06120ac306088ace3e84503a4756","unresolved":false,"context_lines":[{"line_number":195,"context_line":"is running a newer version of the os-vif library than is installed"},{"line_number":196,"context_line":"on the Nova compute host. Second, in addition to the list of VIF"},{"line_number":197,"context_line":"types, Nova will also need to provide a list of installed plugins"},{"line_number":198,"context_line":"along with their versions."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"So approximately the following set of objects would be defined to"},{"line_number":201,"context_line":"represent the new VIF types. It is expected that the result of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_95aceeee","line":198,"in_reply_to":"fa32b979_1ae6bcb0","updated":"2015-06-29 05:26:24.000000000","message":"Um, I thought we agreed that a VIFConfig went with a specific VIFType (as in 1:many) so it seems like this is one list of tuples and not two lists.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"054165a651e61a7a1fcc2dd8b1342eeeafbf90e0","unresolved":false,"context_lines":[{"line_number":195,"context_line":"is running a newer version of the os-vif library than is installed"},{"line_number":196,"context_line":"on the Nova compute host. Second, in addition to the list of VIF"},{"line_number":197,"context_line":"types, Nova will also need to provide a list of installed plugins"},{"line_number":198,"context_line":"along with their versions."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"So approximately the following set of objects would be defined to"},{"line_number":201,"context_line":"represent the new VIF types. It is expected that the result of the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_1ae6bcb0","line":198,"in_reply_to":"fa32b979_f0e542a4","updated":"2015-06-26 09:15:26.000000000","message":"Errm, perhaps I\u0027m missing something, but I just said in this paragraphy that nova would provide both lists - the VIF types and the VIF plugins - which is just what you asked for. Nova would not express any fixed relationship between them - they\u0027 just two lists. It will be up to the mechanism what combinations they need to use. It is certainly permissble for one mechansim to choose between mutliple VIF types or multiple plugins at runtime - no 1:1 restriction.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"bcbfda31d52d357fcdd8b181648e305e9071b8cf","unresolved":false,"context_lines":[{"line_number":224,"context_line":"        fields \u003d {"},{"line_number":225,"context_line":"            # Source device NIC name on host (eg eth0)"},{"line_number":226,"context_line":"            devname: StringField()"},{"line_number":227,"context_line":"\t    # An enum of \u0027vepa\u0027, \u0027passthrough\u0027, or \u0027bridge\u0027"},{"line_number":228,"context_line":"\t    mode: DirectModeField()"},{"line_number":229,"context_line":"        }"},{"line_number":230,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_866347b1","line":227,"updated":"2015-06-29 20:02:16.000000000","message":"nit: hard tabs","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":233,"context_line":"            # UNIX socket path"},{"line_number":234,"context_line":"            path: StringField()"},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"            # Access permission mode"},{"line_number":237,"context_line":"            mode: StringField()"},{"line_number":238,"context_line":"        }"},{"line_number":239,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_743850d5","line":236,"updated":"2015-07-10 02:36:18.000000000","message":"the libvirt xml mode attribute does not specify the access permission. the valid values are client or server.\nclient mode specify that the vm will be the client and the socket will be created by the switching backend e.g. the switch. in server mode the socket is create by libvirt/qemu.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":277,"context_line":""},{"line_number":278,"context_line":"     class VIFProfile8021QBG(VIFProfile):"},{"line_number":279,"context_line":"          fields \u003d {"},{"line_number":280,"context_line":"\t    managerid: IntegerField(),"},{"line_number":281,"context_line":"\t    typeid: IntegerField()"},{"line_number":282,"context_line":"\t    typeidversion: IntegerField()"},{"line_number":283,"context_line":"\t    instanceid: UUIDField()"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_e36e732e","line":280,"updated":"2015-07-01 09:09:44.000000000","message":"Nit: tabs not generally allowed, although the tests clearly forgot to enforce that, so no change required.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":301,"context_line":""},{"line_number":302,"context_line":"::"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"    class VIFPlug(object):"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"        VERSION \u003d \"1.0\""},{"line_number":307,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_5350b80a","line":304,"updated":"2015-06-26 03:54:23.000000000","message":"Pretty please can we validate the base class (which should be an ABC) of incoming loaded classes?  And if we did, then I wonder about a version in the name, so that we load only classes we can do something with and we can make backward compatibility arrangements if we choose for older versions (e.g. a plug() that takes fewer args or returns something different).","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":301,"context_line":""},{"line_number":302,"context_line":"::"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"    class VIFPlug(object):"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"        VERSION \u003d \"1.0\""},{"line_number":307,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_54fe6caf","line":304,"in_reply_to":"fa32b979_5350b80a","updated":"2015-07-10 02:36:18.000000000","message":"+1 to valididating that the derived plug class inherit from and abstract VIFPlug. \nim not as convinced about having the version in the name but that just personal preference for a stylistic standpoint.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"054165a651e61a7a1fcc2dd8b1342eeeafbf90e0","unresolved":false,"context_lines":[{"line_number":301,"context_line":""},{"line_number":302,"context_line":"::"},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"    class VIFPlug(object):"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"        VERSION \u003d \"1.0\""},{"line_number":307,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_5aba0473","line":304,"in_reply_to":"fa32b979_5350b80a","updated":"2015-06-26 09:15:26.000000000","message":"Details of what validation we do isn\u0027t really relevant detail for the spec as this isn\u0027t a fine grained low level code design - that stuff will all be considered in the actual implementation \u0026 so can be reviewed at that point.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":318,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":319,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":320,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":321,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":322,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":323,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"},{"line_number":324,"context_line":"of a VIF port.  The VIFPlug classes must be registered with Nova via the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_b0aeda2d","line":321,"updated":"2015-06-26 03:54:23.000000000","message":"Dan suggests (previous draft) that a pip installed class registers itself with stevedore when it\u0027s installed, so that it\u0027s available at that point. I worry that this is again a side effect thing: Nova will behave differently just because I happen to have an additional package installed, albeit its functionality is improved.  Other examples of pluggable types (for instance the hypervisor driver itself) are named in config.  In this case the name comes from Neutron, so it\u0027s perhaps a little more subtle.  Do we care?","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c20e02ffbd1d06120ac306088ace3e84503a4756","unresolved":false,"context_lines":[{"line_number":318,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":319,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":320,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":321,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":322,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":323,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"},{"line_number":324,"context_line":"of a VIF port.  The VIFPlug classes must be registered with Nova via the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_75960a96","line":321,"in_reply_to":"fa32b979_6d295089","updated":"2015-06-29 05:26:24.000000000","message":"Yes - but the issue is that this is code that is loaded into Nova by the fact that it happens to say of its own free will that it should be, unless we also explicitly list in config what should be loaded (which I\u0027m assuming is a list, as you say).  I like my effects to be explicit.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"054165a651e61a7a1fcc2dd8b1342eeeafbf90e0","unresolved":false,"context_lines":[{"line_number":318,"context_line":"Neutron vendor mechanism. These subclass implementations do not need to be"},{"line_number":319,"context_line":"part of the os-vif library itself. The mechanism vendors would be expected"},{"line_number":320,"context_line":"to distribute them independently, so decomposition of the neutron development"},{"line_number":321,"context_line":"is maintained. It is expected the vendors will provide a separate VIFPlug"},{"line_number":322,"context_line":"impl for each hypervisor they need to be able to integrate with, so info about"},{"line_number":323,"context_line":"the Nova hypervisor must be provided to Neutron when Nova requests creation"},{"line_number":324,"context_line":"of a VIF port.  The VIFPlug classes must be registered with Nova via the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_6d295089","line":321,"in_reply_to":"fa32b979_b0aeda2d","updated":"2015-06-26 09:15:26.000000000","message":"This behaviour is really the main point of using the stevedore mechanism really. The hypervisor is different because you are explicitly selecting one specific impl to use - there\u0027s no way to automatically determine that. In this case, the goal is to make available a whole bunch of impls to be dynamically chosen at runtime. Requiring additional configuration in nova.conf just adds more one step which can be done incorrectly for no compelling benefit that I can see.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":326,"context_line":"it has available, and thus validate requests from Neutron to use a particular"},{"line_number":327,"context_line":"plugin. It also allows Nova to tell Neutron which plugins are available for"},{"line_number":328,"context_line":"use. The plugins will be versioned too, so that it is clear to Neutron which"},{"line_number":329,"context_line":"version of the plugin logic will be executed by Nova."},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":332,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_90539639","line":329,"updated":"2015-06-26 03:54:23.000000000","message":"The other draft suggests that a plugin names all the versions of the interface it supports and that multiple plugins can support different versions - which gets you over the problem that you need lockstepped Nova and Neutron versions, which we don\u0027t want both for upgrade and because in production people do mix and match - the example I\u0027ve come across is older Openstacks with newer Keystones but there\u0027s no reason to think that Neutron wouldn\u0027t fit in there in the future.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c20e02ffbd1d06120ac306088ace3e84503a4756","unresolved":false,"context_lines":[{"line_number":326,"context_line":"it has available, and thus validate requests from Neutron to use a particular"},{"line_number":327,"context_line":"plugin. It also allows Nova to tell Neutron which plugins are available for"},{"line_number":328,"context_line":"use. The plugins will be versioned too, so that it is clear to Neutron which"},{"line_number":329,"context_line":"version of the plugin logic will be executed by Nova."},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":332,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_75ddaa6f","line":329,"in_reply_to":"fa32b979_1a39dcf2","updated":"2015-06-29 05:26:24.000000000","message":"Two things:\n\n1. you may quite reasonably want to support versions of interface to Neutron\n2. the actual integration to Nova might vary over time\n\nOn (1) I\u0027m imagining that\u0027s going to be a list of versions - not necessarily all the way back to v1, and not necessarily all the way up to the latest one Neutron supports, so I would think a list of supported versions would be nice (Neutron can further make accommodations to that with object version management but I don\u0027t want Nova to have to support interface v1 forever).\n\nOn (2) we\u0027ve said nothing to date.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"054165a651e61a7a1fcc2dd8b1342eeeafbf90e0","unresolved":false,"context_lines":[{"line_number":326,"context_line":"it has available, and thus validate requests from Neutron to use a particular"},{"line_number":327,"context_line":"plugin. It also allows Nova to tell Neutron which plugins are available for"},{"line_number":328,"context_line":"use. The plugins will be versioned too, so that it is clear to Neutron which"},{"line_number":329,"context_line":"version of the plugin logic will be executed by Nova."},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":332,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_1a39dcf2","line":329,"in_reply_to":"fa32b979_90539639","updated":"2015-06-26 09:15:26.000000000","message":"I don\u0027t think my previous drafts said anything about plugins declaring versions of VIF types they support. In terms of the VIF type objects, the version(s) supported are effectively determined by the version of the library - essentially what version os-vif has the ability to de-serialize.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":331,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":332,"context_line":"would remain under control of the os-vif library maintainers (ie Neutron and"},{"line_number":333,"context_line":"Nova teams), as any additions to data passed over the REST API must be reviewed"},{"line_number":334,"context_line":"and approved by project maintainers."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"So when a vendor wishes to create a new mechanism, they first decide which"},{"line_number":337,"context_line":"VIFConfig implementation(s) they need to target, and populate that with the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_342de8a8","line":334,"range":{"start_line":334,"start_character":35,"end_line":334,"end_character":36},"updated":"2015-07-10 02:36:18.000000000","message":"should this spec detail the process to propose new VIFConfigs. For example as the VIFConfig and vif types will be owned by both the nova and neutron core teams should a nova or neutron spec be opened to propose a new type? for example the ivshmem interface type is not currently supported by nova but is supported by libvirt and qemu. in the future it may be desirables to add a VIF_TYPE_IVSHMEM and corresponding VIFConfig.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":393,"context_line":"   each supply their own plugin implementation for host OS setup"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"The split between VIF plugins and VIF types is key to the goal of"},{"line_number":396,"context_line":"limiting the number of new VIF types that are created over time."},{"line_number":397,"context_line":""},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_c34a4fac","line":396,"updated":"2015-07-01 09:09:44.000000000","message":"Honestly, this feels a bit like too much info for a spec, but its here now.\n\nWe might want to convert a lot of this into a devref style doc instead.\n\nBut we can work that all out at a later date.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":393,"context_line":"   each supply their own plugin implementation for host OS setup"},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"The split between VIF plugins and VIF types is key to the goal of"},{"line_number":396,"context_line":"limiting the number of new VIF types that are created over time."},{"line_number":397,"context_line":""},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_2fbcb505","line":396,"in_reply_to":"ba3cc151_c34a4fac","updated":"2015-07-10 02:36:18.000000000","message":"i think this help to clearly define the relationships and flexibility of the proposed mechanism so even if it is verbose it is use to keep. +1 to replicating lines 382-393\nin devref.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"93036577089fb8593f0fd3c0217d43fd2742a890","unresolved":false,"context_lines":[{"line_number":481,"context_line":"   library that can be used by both Nova and Neutron directly, we ensure"},{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1a26ad4f_a1712baa","line":484,"updated":"2015-11-02 10:49:07.000000000","message":"5. Move responsibility for VIF plug/unplug to Neutron ?\n\nI\u0027ve written about this more fully in a comment above.  If it isn\u0027t feasible, I guess this would be the right place to explain why.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"4a1544dcfef3918716036560dc0a6b9855718d2b","unresolved":false,"context_lines":[{"line_number":481,"context_line":"   library that can be used by both Nova and Neutron directly, we ensure"},{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1a26ad4f_fa501434","line":484,"in_reply_to":"1a26ad4f_a1712baa","updated":"2015-11-02 20:26:36.000000000","message":"Neutron doesn\u0027t manage any hypervisor configuration right now and I personally don\u0027t want to see it manage hypervisor configs. \n\nIf there is code in Neutron that understands the intricacies of configuring hypervisor software, we have completely failed when it comes to separation of concerns.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"757f0d67bd08f3a3276bf1161890287f3ede6e62","unresolved":false,"context_lines":[{"line_number":481,"context_line":"   library that can be used by both Nova and Neutron directly, we ensure"},{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_3bc5eb5a","line":484,"in_reply_to":"1a26ad4f_fa501434","updated":"2015-11-03 11:07:40.000000000","message":"IIUC the os-vif plan isn\u0027t proposing any change to how Nova get_config works, and my suggestion doesn\u0027t change that either.  In both cases hypervisor configuration management stays firmly in Nova.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"},{"line_number":488,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_06c12580","line":485,"updated":"2015-07-01 09:09:44.000000000","message":"There is also talk of a neutron agent fast path, where nova calls something that does everything the neutron agent would do, without the need for loads more more hops.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"},{"line_number":488,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_6f707d74","line":485,"in_reply_to":"ba3cc151_06c12580","updated":"2015-07-10 02:36:18.000000000","message":"is there a written explanation of this that you can link?","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"8a496e014e97e8e08574b7bc38ff3385a937a3c9","unresolved":false,"context_lines":[{"line_number":482,"context_line":"   both apps have a unified object model and can leverage the standard"},{"line_number":483,"context_line":"   oslo.versionedobject serialization format. This brings Neutron/Nova"},{"line_number":484,"context_line":"   a well defined REST API data format this the data passed between them."},{"line_number":485,"context_line":""},{"line_number":486,"context_line":"Data model impact"},{"line_number":487,"context_line":"-----------------"},{"line_number":488,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa80f949_c8aac885","line":485,"in_reply_to":"ba3cc151_6f707d74","updated":"2015-11-03 15:01:35.000000000","message":"I don\u0027t have a link to that I am afraid.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"6f00504ce7abea68f9efa936c115daeaf286af1c","unresolved":false,"context_lines":[{"line_number":498,"context_line":"  https://review.openstack.org/#/c/190917/"},{"line_number":499,"context_line":""},{"line_number":500,"context_line":"For existing \"legacy\" VIF types, the data format passed back by Neutron"},{"line_number":501,"context_line":"will not change."},{"line_number":502,"context_line":""},{"line_number":503,"context_line":"For the new \"modern\" VIF types, the data format passed back by Neutron"},{"line_number":504,"context_line":"will use the oslo.versionedobjects serialization format, instead of just"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_e303d340","line":501,"updated":"2015-07-01 09:09:44.000000000","message":"This is normally only Nova REST API impact, so this will cause confusion when scanning between specs.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"84abb45e816666e1a1d4bfbcb342b93e1de4015f","unresolved":false,"context_lines":[{"line_number":558,"context_line":"   types and plugins are supported. Neutron only has version 1.0"},{"line_number":559,"context_line":"   but Nova supports version 1.3. Nova can trivially handle version"},{"line_number":560,"context_line":"   1.0, so Neutron can just return data in version 1.0 format"},{"line_number":561,"context_line":"   and Nova just loads it and runs."},{"line_number":562,"context_line":""},{"line_number":563,"context_line":""},{"line_number":564,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_7004d217","line":561,"updated":"2015-06-26 03:54:23.000000000","message":"There will come a point where Nova can\u0027t deal with older forms of the data, so I think listing all versions rather than making assumptions is the better option here.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2616309c7b80199fa835385cc1eba6709376ae4c","unresolved":false,"context_lines":[{"line_number":558,"context_line":"   types and plugins are supported. Neutron only has version 1.0"},{"line_number":559,"context_line":"   but Nova supports version 1.3. Nova can trivially handle version"},{"line_number":560,"context_line":"   1.0, so Neutron can just return data in version 1.0 format"},{"line_number":561,"context_line":"   and Nova just loads it and runs."},{"line_number":562,"context_line":""},{"line_number":563,"context_line":""},{"line_number":564,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_cf0e698c","line":561,"in_reply_to":"ba3cc151_35e72242","updated":"2015-07-10 02:36:18.000000000","message":"could this be handled by a min and max versions similar to pip requirements\ne.g. VIFConfigBridge\u003e\u003d1.0,\u003c2.0","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c20e02ffbd1d06120ac306088ace3e84503a4756","unresolved":false,"context_lines":[{"line_number":558,"context_line":"   types and plugins are supported. Neutron only has version 1.0"},{"line_number":559,"context_line":"   but Nova supports version 1.3. Nova can trivially handle version"},{"line_number":560,"context_line":"   1.0, so Neutron can just return data in version 1.0 format"},{"line_number":561,"context_line":"   and Nova just loads it and runs."},{"line_number":562,"context_line":""},{"line_number":563,"context_line":""},{"line_number":564,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_35e72242","line":561,"in_reply_to":"fa32b979_2d12680a","updated":"2015-06-29 05:26:24.000000000","message":"Yeah - it comes down to Nova not (in this version) being able to say \u0027if you give me a v1 object type I will not be able to use it\u0027.  I would like that ability if possible (probably by saying what versions I *do* support).","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"054165a651e61a7a1fcc2dd8b1342eeeafbf90e0","unresolved":false,"context_lines":[{"line_number":558,"context_line":"   types and plugins are supported. Neutron only has version 1.0"},{"line_number":559,"context_line":"   but Nova supports version 1.3. Nova can trivially handle version"},{"line_number":560,"context_line":"   1.0, so Neutron can just return data in version 1.0 format"},{"line_number":561,"context_line":"   and Nova just loads it and runs."},{"line_number":562,"context_line":""},{"line_number":563,"context_line":""},{"line_number":564,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_2d12680a","line":561,"in_reply_to":"fa32b979_7004d217","updated":"2015-06-26 09:15:26.000000000","message":"At least in terms of serialization/deserialization it is expected that back compat is maintained forever. So Nova should always be able to load the object no matter what versions.\n\nProbably where it becomes trickier is when the VIF plugin does not wish to suport an older version of the VIF config, which this spec doesn\u0027t have a way to express, so will need to think about how to deal with that.","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a6a1ca7ee85b3a1a17d06707a7b594a3d136a263","unresolved":false,"context_lines":[{"line_number":651,"context_line":"  Daniel Berrange \u003cberrange@redhat.com\u003e irc:danpb"},{"line_number":652,"context_line":"  Brent Eagles \u003cbeagles@redhat.com\u003e irc: beagles"},{"line_number":653,"context_line":"  Andreas Scheuring"},{"line_number":654,"context_line":"  Maxime Leroy"},{"line_number":655,"context_line":""},{"line_number":656,"context_line":"Work Items"},{"line_number":657,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ba3cc151_a49dca67","line":654,"updated":"2015-07-01 12:15:25.000000000","message":"Feel free to add me as well. I\u0027m familiar with the code here and put together the os_vif sample library on Github to get the juices flowing...","commit_id":"576ea39898092900aa75b39db3774a8a105437bc"}],"specs/liberty/os-vif-library.rst":[{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/os-vif-library"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Define a standalone os-vif python library, inspired by os-brick, to provide"},{"line_number":14,"context_line":"a versioned object model for data passed from neutron to nova for VIF port"},{"line_number":15,"context_line":"binding, and an API to allow vendors to provide custom plug/unplug actions"},{"line_number":16,"context_line":"for execution by Nova."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_43a434b8","line":13,"updated":"2015-06-22 12:22:53.000000000","message":"FWIW, it\u0027s not clear to me whether \"os-\" here means open source, operating system, or OpenStack.  So possibly it\u0027s not the best name.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/os-vif-library"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Define a standalone os-vif python library, inspired by os-brick, to provide"},{"line_number":14,"context_line":"a versioned object model for data passed from neutron to nova for VIF port"},{"line_number":15,"context_line":"binding, and an API to allow vendors to provide custom plug/unplug actions"},{"line_number":16,"context_line":"for execution by Nova."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ebddec70","line":13,"in_reply_to":"fa32b979_43a434b8","updated":"2015-06-23 10:02:38.000000000","message":"I just presumed it meant  openstack, but to be honest I\u0027m not sold on the name. I just picked that as an easy name to use in the spec.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5d3329220cdc7d16d3b7c41347cfd890722f7d04","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Project Priority"},{"line_number":63,"context_line":"-----------------"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"De-gross-ification of networking ? \u003c/joke\u003e"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Proposed change"},{"line_number":68,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_8b8fdc74","line":65,"updated":"2015-06-22 15:10:51.000000000","message":":)","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":67,"context_line":"Proposed change"},{"line_number":68,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Inspired the os-brick library effort started by the Cinder project, the"},{"line_number":71,"context_line":"proposal involves creation of a new library module that will be jointly"},{"line_number":72,"context_line":"developed by the Neutron \u0026 Nova teams, for consumption by both projects."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_632058f8","line":70,"updated":"2015-06-22 12:22:53.000000000","message":"Nit: missing \"by\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":71,"context_line":"proposal involves creation of a new library module that will be jointly"},{"line_number":72,"context_line":"developed by the Neutron \u0026 Nova teams, for consumption by both projects."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The library will make use of the olso.versionedobjects module in order to"},{"line_number":75,"context_line":"formally define a set of objects to describe the VIF port binding data."},{"line_number":76,"context_line":"The data in this objects will be serialized into JSON, for transmission"},{"line_number":77,"context_line":"between Neutron and Nova, just as is done with the current dicts used"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_23c7b013","line":74,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"olso\" -\u003e \"oslo\" (also more occurrences below)","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"This base object defines the fields that are common to all the"},{"line_number":101,"context_line":"different VIF port binding types. There are a number of this attributes,"},{"line_number":102,"context_line":"currently detailed in the VIF class in nova.network.model, or the equiv"},{"line_number":103,"context_line":"in Neutron."},{"line_number":104,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ee7bef79","line":101,"updated":"2015-06-22 12:22:53.000000000","message":"Nit: \"this\" -\u003e \"these\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":115,"context_line":"in the plug/unplug actions, hence the point previously about the \u0027plug\u0027"},{"line_number":116,"context_line":"class name.  All existing VIF types will be considered legacy. These"},{"line_number":117,"context_line":"various config classes will define a completely new set of modern VIF"},{"line_number":118,"context_line":"types. In many cases they will be practically identical to the existing"},{"line_number":119,"context_line":"VIF types, with the exception that the data passed from Neutron to Nova"},{"line_number":120,"context_line":"will be using the olso.versioned object serialization data. By defining"},{"line_number":121,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_8efee3ac","line":118,"updated":"2015-06-22 12:22:53.000000000","message":"So, just to be clear, modern VIF types are 1:1 with config classes, NOT with plug/unplug implementations - correct?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":115,"context_line":"in the plug/unplug actions, hence the point previously about the \u0027plug\u0027"},{"line_number":116,"context_line":"class name.  All existing VIF types will be considered legacy. These"},{"line_number":117,"context_line":"various config classes will define a completely new set of modern VIF"},{"line_number":118,"context_line":"types. In many cases they will be practically identical to the existing"},{"line_number":119,"context_line":"VIF types, with the exception that the data passed from Neutron to Nova"},{"line_number":120,"context_line":"will be using the olso.versioned object serialization data. By defining"},{"line_number":121,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ab55a4c6","line":118,"in_reply_to":"fa32b979_8efee3ac","updated":"2015-06-23 10:02:38.000000000","message":"That is correct.  VIF type is 1:1 with config. Config is 1:M with plugins. Neutron mechanisms as M:N with configs - ie multiple neutron mechansism can use the same config. A single neutron mechanism can choose to use different configs depending on scenario.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":120,"context_line":"will be using the olso.versioned object serialization data. By defining"},{"line_number":121,"context_line":"a completely new set of VIF types, we make it easy for Nova to negotiate"},{"line_number":122,"context_line":"use of the new types with Neutron. When calling Neutron, Nova will"},{"line_number":123,"context_line":"indicate what VIF types it is capable ofo supporting, and thus Neutron"},{"line_number":124,"context_line":"can determine whether it is able to use the new object based VIF types"},{"line_number":125,"context_line":"or the legacy anoymous dict based types. This negotiation is touched"},{"line_number":126,"context_line":"on in this spec already"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_8e5023d6","line":123,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"ofo\" -\u003e \"of\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":145,"context_line":"    class VIFConfigEthernet(VIFConfig):"},{"line_number":146,"context_line":"        fields \u003d {"},{"line_number":147,"context_line":"            # Name of the host TAP device used as the VIF"},{"line_number":148,"context_line":"            devname: StringField(nullable\u003dTrue)"},{"line_number":149,"context_line":"        }"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"    class VIFConfigOVS(VIFConfigBridge):"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_c977053a","line":148,"updated":"2015-06-22 12:22:53.000000000","message":"Why allow null here?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":145,"context_line":"    class VIFConfigEthernet(VIFConfig):"},{"line_number":146,"context_line":"        fields \u003d {"},{"line_number":147,"context_line":"            # Name of the host TAP device used as the VIF"},{"line_number":148,"context_line":"            devname: StringField(nullable\u003dTrue)"},{"line_number":149,"context_line":"        }"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"    class VIFConfigOVS(VIFConfigBridge):"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_8b2f803d","line":148,"in_reply_to":"fa32b979_c977053a","updated":"2015-06-23 10:02:38.000000000","message":"Currently devname is optional, but there\u0027s reasonable grounds to make it mandatory. Don\u0027t take these classes i\u0027ve written here as final though - this was just a quick illustration to show the general concept, rather than what i consider the final set of fields to be. If people broadly agree with this approach, then I\u0027ll take time to spec out these classes correctly.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":188,"context_line":"too. This spec does not attempt to enumerate what those will be, but they"},{"line_number":189,"context_line":"will be similarly simple and finite set."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"As aluded to in an earlier paragraph, the library will also need to define"},{"line_number":192,"context_line":"an interface for enabling the plug / unplug actions to be performed. This"},{"line_number":193,"context_line":"is a quite straightforward abstract python classs"},{"line_number":194,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_09eacdac","line":191,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"aluded\" -\u003e \"alluded\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":202,"context_line":""},{"line_number":203,"context_line":"The \u0027config\u0027 parameter passed in here will be an instance of the VIFConfig"},{"line_number":204,"context_line":"versioned object defined above."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"There will be one subclass of this VIFPlug class provided by each Neutron"},{"line_number":207,"context_line":"vendor mechanism. These subclass implementations do not need to be part of"},{"line_number":208,"context_line":"the os-vif library itself. The mechanism vendors would be expected to distribute"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_741d7065","line":205,"updated":"2015-06-22 12:22:53.000000000","message":"Is it reasonable to expect that the same plug/unplug will work on different hypervisors?  In other words, should some additional information be passed into the plug and unplug methods, to indicate the hypervisor; or more broadly the compute host environment?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":202,"context_line":""},{"line_number":203,"context_line":"The \u0027config\u0027 parameter passed in here will be an instance of the VIFConfig"},{"line_number":204,"context_line":"versioned object defined above."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"There will be one subclass of this VIFPlug class provided by each Neutron"},{"line_number":207,"context_line":"vendor mechanism. These subclass implementations do not need to be part of"},{"line_number":208,"context_line":"the os-vif library itself. The mechanism vendors would be expected to distribute"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ebce4c82","line":205,"in_reply_to":"fa32b979_741d7065","updated":"2015-06-23 10:02:38.000000000","message":"No, I\u0027d expect generally the actions will differ. There\u0027s two ways we could deal with this - either pass virt driver type into the plugin, so it can take different codepaths. Or better is to pass hypervisor info across to neutron when creating the port - it might way to return a completely different VIF type for vmware vs libvirt.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":206,"context_line":"There will be one subclass of this VIFPlug class provided by each Neutron"},{"line_number":207,"context_line":"vendor mechanism. These subclass implementations do not need to be part of"},{"line_number":208,"context_line":"the os-vif library itself. The mechanism vendors would be expected to distribute"},{"line_number":209,"context_line":"them independantly, so decomposition of the neutron development is maintained."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":212,"context_line":"would remain under control of the os-vif library maintainers (ie Neuton and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_1423c4a8","line":209,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"independantly\" -\u003e \"independently\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":209,"context_line":"them independantly, so decomposition of the neutron development is maintained."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"The vendors would not be permitted to define new VIFConfig sub-classes, these"},{"line_number":212,"context_line":"would remain under control of the os-vif library maintainers (ie Neuton and"},{"line_number":213,"context_line":"Nova teams), as any additions to data passed over the REST API must be reviewed"},{"line_number":214,"context_line":"and approved by project maintainers."},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_a9540154","line":212,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"Neuton\" -\u003e \"Neutron\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":250,"context_line":"is that any newly developer Neutron mechanisms that rely on the new"},{"line_number":251,"context_line":"VIFCOnfig object model exclusively, will not work with legacy Nova"},{"line_number":252,"context_line":"deployments. This is not considered to be a signficant problem, as the"},{"line_number":253,"context_line":"mis-match in Neutron/Nova versions is only a temporary problem as a cloud"},{"line_number":254,"context_line":"undergoes a staged update from Kilo to Liberty"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_3405a8c1","line":253,"updated":"2015-06-22 12:22:53.000000000","message":"Sp: \"signficant\" -\u003e \"significant\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":266,"context_line":"   of tree VIF driver plugins for libvirt. This is undesirable for"},{"line_number":267,"context_line":"   a number of reasons."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"   The task of configuring a libvirt guests consists of two halves"},{"line_number":270,"context_line":"   commonly referred to as backend configuration (ie the host) and"},{"line_number":271,"context_line":"   frontend configuration (ie what the guest sees). The frontend"},{"line_number":272,"context_line":"   config is something that the libvirt driver needs to retain"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_f4b3c008","line":269,"updated":"2015-06-22 12:22:53.000000000","message":"\"guests\" -\u003e \"guest\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":278,"context_line":"   representing any VIF config for the guest. These are considered part"},{"line_number":279,"context_line":"   of the libvirt internal implementation and not a stable API."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"   Thirdly, the libvirt VIR driver plugin API has changed in the past"},{"line_number":282,"context_line":"   and may change again in the future, and the data passed into it is"},{"line_number":283,"context_line":"   an ill-defined dict of values from the port binding."},{"line_number":284,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_b4953841","line":281,"updated":"2015-06-22 12:22:53.000000000","message":"\"VIR\" -\u003e \"VIF\" (I think)","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":298,"context_line":"   of the libvirt hypervisor driver. The commonality is that the Neutron"},{"line_number":299,"context_line":"   vendor has the ability to retain control of their plug/unplug tasks"},{"line_number":300,"context_line":"   without Nova getting in the way."},{"line_number":301,"context_line":""},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"3. Keep the current VIF binding approach, but include the name of an"},{"line_number":304,"context_line":"   executable program (script) that Nova will invoke to perform thte"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_9444b4b7","line":301,"updated":"2015-06-22 12:22:53.000000000","message":"Also the new approach is, I believe, not libvirt-specific.  In principle it allows a VIFPlug implementation to handle plug/unplug under multiple hypervisors - which the config side of things, which is necessarily hypervisor-specific, correctly remains part of Nova (or os-vif).","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":298,"context_line":"   of the libvirt hypervisor driver. The commonality is that the Neutron"},{"line_number":299,"context_line":"   vendor has the ability to retain control of their plug/unplug tasks"},{"line_number":300,"context_line":"   without Nova getting in the way."},{"line_number":301,"context_line":""},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"3. Keep the current VIF binding approach, but include the name of an"},{"line_number":304,"context_line":"   executable program (script) that Nova will invoke to perform thte"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_cb9a686e","line":301,"in_reply_to":"fa32b979_9444b4b7","updated":"2015-06-23 10:02:38.000000000","message":"Yes, the guest configuration will remain under exclusive control of the hypervisor driver. The plugin is only responsible for host OS setup tasks. ie bits that a Neutron agent would do, if neutron used a compute host agent.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":329,"context_line":"   access the well defined VIFConfig class attributes, instead of"},{"line_number":330,"context_line":"   having to parse environment variables."},{"line_number":331,"context_line":""},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"Data model impact"},{"line_number":334,"context_line":"-----------------"},{"line_number":335,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_742010f8","line":332,"updated":"2015-06-22 12:22:53.000000000","message":"4. As per this spec, except keep the VIFConfig* classes in Nova instead of in a separate library module (os-vif). What are the pros and cons of that?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":329,"context_line":"   access the well defined VIFConfig class attributes, instead of"},{"line_number":330,"context_line":"   having to parse environment variables."},{"line_number":331,"context_line":""},{"line_number":332,"context_line":""},{"line_number":333,"context_line":"Data model impact"},{"line_number":334,"context_line":"-----------------"},{"line_number":335,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_cba8287a","line":332,"in_reply_to":"fa32b979_742010f8","updated":"2015-06-23 10:02:38.000000000","message":"The goal of having the versioned objects in a separate library was that Neutron will use these objects directly. This means that the data that gets passed over the REST api will be using the oslo.versionedobjects serialization format. This gives us well defined versioning, so if we later need to add fields to the VIFConfig classes we can do this in a well defined backwards compatible manner.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":343,"context_line":"---------------"},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"The data that Neutron passes back to Nova when asked to create a VIF"},{"line_number":346,"context_line":"will change in format. Assuming new Nova indicates to Neutron that it"},{"line_number":347,"context_line":"wishes to opt-in to the new format, then Neutron will return the"},{"line_number":348,"context_line":"results of running"},{"line_number":349,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_b4545854","line":346,"updated":"2015-06-22 12:22:53.000000000","message":"This still needs specification?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":400,"context_line":"that this will be a rare occurrance."},{"line_number":401,"context_line":""},{"line_number":402,"context_line":"When a vendor wishes to implement a new Neutron mechanism, they will have"},{"line_number":403,"context_line":"to provide an implementation of the VIFPlug clas whose abstract interface"},{"line_number":404,"context_line":"is define in the os-vif library. This vendor specific implementation will"},{"line_number":405,"context_line":"not need to be included in the os-vif library itself - it can be distributed"},{"line_number":406,"context_line":"and deployed by the vendor themselves. This frees the vendor from having to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_74aa501b","line":403,"updated":"2015-06-22 12:22:53.000000000","message":"\"clas\" -\u003e \"class\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":401,"context_line":""},{"line_number":402,"context_line":"When a vendor wishes to implement a new Neutron mechanism, they will have"},{"line_number":403,"context_line":"to provide an implementation of the VIFPlug clas whose abstract interface"},{"line_number":404,"context_line":"is define in the os-vif library. This vendor specific implementation will"},{"line_number":405,"context_line":"not need to be included in the os-vif library itself - it can be distributed"},{"line_number":406,"context_line":"and deployed by the vendor themselves. This frees the vendor from having to"},{"line_number":407,"context_line":"do a lock-step update to Nova to support their product."}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_94a59448","line":404,"updated":"2015-06-22 12:22:53.000000000","message":"\"define\" -\u003e \"defined\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"0b7c47779a60186d344ab258baf9effb084dcc53","unresolved":false,"context_lines":[{"line_number":414,"context_line":"-----------"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Primary assignee:"},{"line_number":417,"context_line":"  TBD"},{"line_number":418,"context_line":""},{"line_number":419,"context_line":"Other contributors:"},{"line_number":420,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_f920694b","line":417,"updated":"2015-06-23 09:36:15.000000000","message":"I could help getting things done.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":11307,"name":"Andreas Scheuring","email":"andreas.scheuring@de.ibm.com","username":"uniqueName"},"change_message_id":"0b7c47779a60186d344ab258baf9effb084dcc53","unresolved":false,"context_lines":[{"line_number":435,"context_line":"   hypervisors"},{"line_number":436,"context_line":""},{"line_number":437,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":438,"context_line":"   in step 3."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"5. Define the VIFPlug abstract base class for Neutron mechanism"},{"line_number":441,"context_line":"   vendors to implement"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_5e3e1bdb","line":438,"updated":"2015-06-23 09:36:15.000000000","message":"Where is the generation of the xml happening? Is it still in the LibvirtGenericVIFDriver class? I guess a step for refactoring this class to support the modern vif_types is required (remove plug/unplug code, introduce modern get_config_\u003cmodern-vif-type\u003e methods). Or is this covered in step 7 or 8?","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"840d3c4871753eee83ad74bdeef81f30d6965dcd","unresolved":false,"context_lines":[{"line_number":435,"context_line":"   hypervisors"},{"line_number":436,"context_line":""},{"line_number":437,"context_line":"4. Create VIFConfig subclasses for each of the configs identified"},{"line_number":438,"context_line":"   in step 3."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"5. Define the VIFPlug abstract base class for Neutron mechanism"},{"line_number":441,"context_line":"   vendors to implement"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_0bf4d084","line":438,"in_reply_to":"fa32b979_5e3e1bdb","updated":"2015-06-23 10:02:38.000000000","message":"All guest configuration will remain 100% under control of the virtualization drivers in Nova. The goal is that the VIFConfig class contain enough information to allow libvirt to generate its XML without needing to run vendor custom code. So the plugin is solely responsiblke for host OS setup tasks.","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"194a3779185d1cc6af08e452b2dcd0ba751e1c8f","unresolved":false,"context_lines":[{"line_number":472,"context_line":"of the proposals in this spec"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"Once those are done, the Nova and Neutron teams can progress on their"},{"line_number":475,"context_line":"respective work items independantly."},{"line_number":476,"context_line":""},{"line_number":477,"context_line":"Testing"},{"line_number":478,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_5434ecf9","line":475,"updated":"2015-06-22 12:22:53.000000000","message":"\"independantly\" -\u003e \"Independently\"","commit_id":"4698a64b7b163243eefbb4486d892c2038f50e3a"}]}