)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4773556f0855f8f9e1553a24ccf22deedce8132d","unresolved":false,"context_lines":[{"line_number":23,"context_line":"class defined, which are sufficient to cover all the current"},{"line_number":24,"context_line":"usage in the libvirt driver and some usage in other drivers."},{"line_number":25,"context_line":"It is expected that a couple more VIF types may be added for"},{"line_number":26,"context_line":"vmware/hyper, when those drivers are later converted. The"},{"line_number":27,"context_line":"generic network port profile data is represented by the new"},{"line_number":28,"context_line":"VIFPortProfileBase class and its subclasses."},{"line_number":29,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9a68dd71_239801c0","line":26,"updated":"2016-01-22 02:50:31.000000000","message":"s/hyper/hyper-v","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"}],"README.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4773556f0855f8f9e1553a24ccf22deedce8132d","unresolved":false,"context_lines":[{"line_number":60,"context_line":"                                   network\u003dnetwork,"},{"line_number":61,"context_line":"                                   plugin\u003d\u0027vhostuser\u0027,"},{"line_number":62,"context_line":"                                   path\u003d\u0027/path/to/socket\u0027,"},{"line_number":63,"context_line":"                                   mode\u003d\u00270660\u0027)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    # Now do the actual plug operations to connect the VIF to"},{"line_number":66,"context_line":"    # the backing network interface."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a68dd71_4393b5a3","line":63,"updated":"2016-01-22 02:50:31.000000000","message":"So, here\u0027s the problem with this approach, IMHO. You should consider the example code in this README.rst file as being very similar (though condensed) to the code that should eventually be running in Nova.\n\nOne of the problems that an approach like this will introduce is there will need to be a giant set of conditionals (very similar to the existing code in /nova/virt/libvirt/vif.py that calls various plug_xxx() methods depending on the nic_type and other things.\n\nMy original idea was that having a single os_vif.objects.VIF() object constructed from the return of the Neutron port binding and details information would then be passed as-is to the os_vif.plug() call, thereby eliminating the need entirely to have a whole bunch of logic on Nova\u0027s side to create some VIF-type-specific object that must be passed to a plug operation.\n\nI prefer the existing design which uses the singular VIF object and houses all of the logic and complexity inside the os_vif library as opposed to requiring all the clients of os_vif (like Nova) to implement all that logic and numerous conditionals.","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4069f230f9b4a5a74e2242e50e79c77d0b0c3d66","unresolved":false,"context_lines":[{"line_number":60,"context_line":"                                   network\u003dnetwork,"},{"line_number":61,"context_line":"                                   plugin\u003d\u0027vhostuser\u0027,"},{"line_number":62,"context_line":"                                   path\u003d\u0027/path/to/socket\u0027,"},{"line_number":63,"context_line":"                                   mode\u003d\u00270660\u0027)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    # Now do the actual plug operations to connect the VIF to"},{"line_number":66,"context_line":"    # the backing network interface."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba63e191_1630b200","line":63,"range":{"start_line":63,"start_character":41,"end_line":63,"end_character":45},"updated":"2016-01-19 22:45:59.000000000","message":"the mode in this case is either \"client\" or \"server\" not a filesystem mode for the socket. client mode means the socket will be created by the network backend e.g. ovs and server means the socket will be created by qemu.","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"b7fb5d9d43426f5054521ffcbd921b7376030e47","unresolved":false,"context_lines":[{"line_number":60,"context_line":"                                   network\u003dnetwork,"},{"line_number":61,"context_line":"                                   plugin\u003d\u0027vhostuser\u0027,"},{"line_number":62,"context_line":"                                   path\u003d\u0027/path/to/socket\u0027,"},{"line_number":63,"context_line":"                                   mode\u003d\u00270660\u0027)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    # Now do the actual plug operations to connect the VIF to"},{"line_number":66,"context_line":"    # the backing network interface."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a68dd71_5a614638","line":63,"in_reply_to":"9a68dd71_4393b5a3","updated":"2016-01-22 10:28:39.000000000","message":"Sigh, we went over this in the spec already and this design I\u0027ve implemented was agreed then :-(\n\nThe problem you describe really won\u0027t come to pass long term - it is only a short term issue.\n\nFirst, there\u0027s really two parts to this - first constructing the initial VIF object, and second processing the objects. The latter is going to require a bunch of get_config_XXX conditionals regardless of which approach we take, as different VIF types have different means of configuring the virt layer interfaces. Having separate VIF subclasses for each type of config requirement actually simplifies the virt driver integration, as it is 100% clear what attributes are relevant for each configuration scenario. With a single object you never know which attribute is relevent in which scenario, which is one of the key problems we were aiming to solve with the refactor\n\nFor constructing the initial VIF object, we have to consider two stages of impl. Initially when we wire up os-vif into Nova, we will have the current Neutron port-binding data and have to use that to populate approach VIF objects. This will indeed require conditional logic to choose which subclass to instantiate. You can see an illustration of that here:\n\nhttps://review.openstack.org/#/c/269672/3/nova/network/os_vif.py\n\nfrom line 140 onwards. Note that having a single VIF object doesn\u0027t remove all this code, as 50% of the code is handling instantiation of the related Network/Subnet/etc objects\n\nBut this code is *only* alive for a short period of time. In the next  phase of integration, the Neutron mechanisms will instantiate the right VIF subclass immediately in this code, serialize this and pass it across to Nova.  So nova will no longer use the legacy port binding data at all - it can directly de-serialize the VIF instance and use it right away. 100% of the conditional logic disappears *and* we get to use strongly typed vif classes where it is obvious what data attributes are relevant to each VIF.\n\nSo I don\u0027t think your concern here is really relevant - looking to the final destination, having a sub-classes will be a clear win overall.","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"87dcf53a92f86206511ca66122a472abbf908f97","unresolved":false,"context_lines":[{"line_number":60,"context_line":"                                   network\u003dnetwork,"},{"line_number":61,"context_line":"                                   plugin\u003d\u0027vhostuser\u0027,"},{"line_number":62,"context_line":"                                   path\u003d\u0027/path/to/socket\u0027,"},{"line_number":63,"context_line":"                                   mode\u003d\u00270660\u0027)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    # Now do the actual plug operations to connect the VIF to"},{"line_number":66,"context_line":"    # the backing network interface."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba63e191_62def340","line":63,"range":{"start_line":63,"start_character":41,"end_line":63,"end_character":45},"in_reply_to":"ba63e191_1630b200","updated":"2016-01-20 10:08:54.000000000","message":"Yeah, i mis-read this originally when creating the objects i forgot to update here when i fixed it","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a04b963c2b4aeffa4950516f7807fe47c1998f80","unresolved":false,"context_lines":[{"line_number":60,"context_line":"                                   network\u003dnetwork,"},{"line_number":61,"context_line":"                                   plugin\u003d\u0027vhostuser\u0027,"},{"line_number":62,"context_line":"                                   path\u003d\u0027/path/to/socket\u0027,"},{"line_number":63,"context_line":"                                   mode\u003d\u00270660\u0027)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    # Now do the actual plug operations to connect the VIF to"},{"line_number":66,"context_line":"    # the backing network interface."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a5de9d1_5a309a9e","line":63,"range":{"start_line":63,"start_character":40,"end_line":63,"end_character":46},"updated":"2016-01-28 15:39:10.000000000","message":"the mode is incorrect here but it is fixed elseware in this patch revision.","commit_id":"16744c0193ec0ec673649a57d947d36816609086"}],"os_vif/objects/vif.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4069f230f9b4a5a74e2242e50e79c77d0b0c3d66","unresolved":false,"context_lines":[{"line_number":113,"context_line":"        # UNIX socket path"},{"line_number":114,"context_line":"        \u0027path\u0027: fields.StringField(),"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"        # UNIX socket access permissions"},{"line_number":117,"context_line":"        \u0027mode\u0027: osv_fields.VIFVHostUserModeField(),"},{"line_number":118,"context_line":"    }"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"ba63e191_91ca6ca0","line":116,"range":{"start_line":116,"start_character":0,"end_line":116,"end_character":40},"updated":"2016-01-19 22:45:59.000000000","message":"# UNIX socket creation mode: client,server","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"87dcf53a92f86206511ca66122a472abbf908f97","unresolved":false,"context_lines":[{"line_number":113,"context_line":"        # UNIX socket path"},{"line_number":114,"context_line":"        \u0027path\u0027: fields.StringField(),"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"        # UNIX socket access permissions"},{"line_number":117,"context_line":"        \u0027mode\u0027: osv_fields.VIFVHostUserModeField(),"},{"line_number":118,"context_line":"    }"},{"line_number":119,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"ba63e191_02ee17ec","line":116,"range":{"start_line":116,"start_character":0,"end_line":116,"end_character":40},"in_reply_to":"ba63e191_91ca6ca0","updated":"2016-01-20 10:08:54.000000000","message":"Done","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4069f230f9b4a5a74e2242e50e79c77d0b0c3d66","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"@base.VersionedObjectRegistry.register"},{"line_number":143,"context_line":"class VIFPortProfileOVS(VIFPortProfileBase):"},{"line_number":144,"context_line":"    # Port profile info for OpenVSwitch networks"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"    VERSION \u003d \u00271.0\u0027"}],"source_content_type":"text/x-python","patch_set":1,"id":"ba63e191_7178182c","line":143,"range":{"start_line":143,"start_character":0,"end_line":143,"end_character":44},"updated":"2016-01-19 22:45:59.000000000","message":"would it make sense to make ovs a special case of VIFGeneric\n\nin essince hybrid plug vs non hybrid plug are just two toplogies for connecting a tap device to ovs.\n\nthis would require the libvirt config to be altered to allow os_vif to do the plug and unplug in the non hybrid plug case.","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"87dcf53a92f86206511ca66122a472abbf908f97","unresolved":false,"context_lines":[{"line_number":140,"context_line":""},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"@base.VersionedObjectRegistry.register"},{"line_number":143,"context_line":"class VIFPortProfileOVS(VIFPortProfileBase):"},{"line_number":144,"context_line":"    # Port profile info for OpenVSwitch networks"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"    VERSION \u003d \u00271.0\u0027"}],"source_content_type":"text/x-python","patch_set":1,"id":"ba63e191_e2ae6384","line":143,"range":{"start_line":143,"start_character":0,"end_line":143,"end_character":44},"in_reply_to":"ba63e191_7178182c","updated":"2016-01-20 10:08:54.000000000","message":"I\u0027ve got a WIP up against nova that illustrates how we create the VIF instances for the different VIF types passed from Neutron\n\nhttps://review.openstack.org/#/c/269672/2/nova/network/os_vif.py\n\nEssentially the idea is that for the current Neutron VIF types which have multiple different ways of connecting to libvirt, we\u0027ll just instantiate a different VIFBase subclass right away, to represent the desired configuration approach","commit_id":"0e0064195342651bb2c41ffd41f901f1b4428082"}]}