)]}'
{"specs/liberty/approved/extensible-vifplug.rst":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"cf3defd929b147c0dcec517c8aa3c7d650fb1fdf","unresolved":false,"context_lines":[{"line_number":126,"context_line":""},{"line_number":127,"context_line":"We propose implementing this interface for libvirt, initially.  The"},{"line_number":128,"context_line":"libvirt code will be refactored so that existing binding types are in"},{"line_number":129,"context_line":"class form, for consistency and because the current code is ugly."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Alternatives"},{"line_number":132,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ed2c75ad","line":129,"updated":"2015-06-15 08:57:30.000000000","message":"It is not entirely clear from this description, but it looks like you\u0027re suggesting that the libvirt XML config creation should be moved out into this separate library. If so that is absolutely not something I wish to see happen. This would turn guest VIF configuration into a complete blackbox which is really not at all desirable from the POV of the libvirt Nova driver. It is not reasonable to assume that this library knows how to correctly configure all aspects of the guest VIF config - there are a number of aspects of the config that require knowledge / logic from the libvirt driver itself and we\u0027re not going to outsource that to an external library, as that is essentially turning an internal impl detail into stable API.  This is one of the main reasons we got rid of the previous externally pluggable VIF driver setup and so we\u0027re not going to re-introduce that again","commit_id":"25ceab90df74cf14c7ded8fe320044989b661c89"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"dbb10ac958d09b4816c385e15b7b0930ff6cd930","unresolved":false,"context_lines":[{"line_number":126,"context_line":""},{"line_number":127,"context_line":"We propose implementing this interface for libvirt, initially.  The"},{"line_number":128,"context_line":"libvirt code will be refactored so that existing binding types are in"},{"line_number":129,"context_line":"class form, for consistency and because the current code is ugly."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Alternatives"},{"line_number":132,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_47e52707","line":129,"in_reply_to":"fa32b979_6c44d273","updated":"2015-06-15 16:55:03.000000000","message":"In the event that there is a new VIF type invented by libvirt/qemu, then I actually consider the fact that Nova would need modifying to support that to be a desired feature. I don\u0027t want to allow a total free for all where network vendors can do arbitrary libvirt configuration with no involvement of Nova. As explained in the previous comment, the VIF configuration cannot be done as a blackbox outside the nova libvirt driver - there are aspects to the configuration that only the Nova libvirt code is capable of doing. Some VIF configurations have significant security implications, and others have dependancies on other aspects of guest configuration such as huge pages. Libvirt also has various QoS settings to apply to the VIF configuration, and has logic to decide what type of virtual hardware to expose to the guest. Finally, the libvirt driver needs to be able to parse the XML configuration of any guest, to represent it in our internal config object model, and so any new VIF type supported by libvirt will always need that object model extended - thus precludes the idea that an external network vendor add support for new XML formats without modifying Nova libvirt. For all these reasons, Nova libvirt will always retain 100% control over the XML configuration task - the only thing open for debate is how to facilitate the host OS networking stack configuration tasks. eg the stuff currently done in the plug/unplug methods of the Nova VIF driver - not the get_config method.","commit_id":"25ceab90df74cf14c7ded8fe320044989b661c89"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"8a7d4af53c52217e4f9c89129fde2a230a4d9923","unresolved":false,"context_lines":[{"line_number":126,"context_line":""},{"line_number":127,"context_line":"We propose implementing this interface for libvirt, initially.  The"},{"line_number":128,"context_line":"libvirt code will be refactored so that existing binding types are in"},{"line_number":129,"context_line":"class form, for consistency and because the current code is ugly."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Alternatives"},{"line_number":132,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_6c44d273","line":129,"in_reply_to":"fa32b979_ed2c75ad","updated":"2015-06-15 16:42:13.000000000","message":"The reason I put this proposal in is specifically because the scripted VIF thing has issues.  The next time I want to add another vhostuser - assuming I can find a libvirt and a qemu that supports it (and ivshmem would be a good example of this, I guess) - then I do truly know better than the current, shipped Openstack code.  And assuming the \u0027I\u0027 in that sentence is any of the people writing a network controller, then they probably want to get their code on machines without changing Nova, of all things, to do it, and I think they should be able to.\n\nI do totally sympathise that the way in which the libvirt XML is written may change enough to break one of these things - a totally legitimate concern; also the reason for the driver version during registration, which I\u0027m thinking at this point should change frequently on the Nova side of things and not remotely consider backward compatibility.\n\nGiven the way I put this together it\u0027s trivial for a supplier to write a piece of plugin code supporting many versions, and put out one that keeps v.OLD support while including v.NEW support that will work with both old and new Nova versions quite happily.\n\nSince it\u0027s impossible for Nova devs to make any concession to whatever the 3rd party code is doing (which is pretty much unknowable, as you say), I think lands the development responsibility squarely where it belongs while simultaneously enabling something that gets in the way of making Openstack deployments better.","commit_id":"25ceab90df74cf14c7ded8fe320044989b661c89"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"cf3defd929b147c0dcec517c8aa3c7d650fb1fdf","unresolved":false,"context_lines":[{"line_number":131,"context_line":"Alternatives"},{"line_number":132,"context_line":"------------"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"None considered."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Data model impact"},{"line_number":137,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_ed03150e","line":134,"updated":"2015-06-15 08:57:30.000000000","message":"There is the existing VIF plugin proposal that is under debate","commit_id":"25ceab90df74cf14c7ded8fe320044989b661c89"},{"author":{"_account_id":105,"name":"Kyle Mestery","email":"mestery@mestery.com","username":"mestery"},"change_message_id":"cbf573dadcc7455b1a6dcc15bcdabd17cc0b71cd","unresolved":false,"context_lines":[{"line_number":131,"context_line":"Alternatives"},{"line_number":132,"context_line":"------------"},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"None considered."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Data model impact"},{"line_number":137,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa32b979_eb408ca7","line":134,"in_reply_to":"fa32b979_ed03150e","updated":"2015-06-16 18:05:29.000000000","message":"Can you link that here for reference?","commit_id":"25ceab90df74cf14c7ded8fe320044989b661c89"}]}