Change in vdsm[master]: [WIP] netwiring: [4/4] Add API definitions.

asegurap at redhat.com asegurap at redhat.com
Tue Dec 4 10:14:19 UTC 2012


Antoni Segura Puimedon has posted comments on this change.

Change subject: [WIP] netwiring: [4/4] Add API definitions.
......................................................................


Patch Set 14: (6 inline comments)

....................................................
File vdsm/libvirtvm.py
Line 1522: 
Line 1523:         return {'status': doneCode, 'vmList': self.status()}
Line 1524: 
Line 1525:     def _updateInterfaceDevice(self, params):
Line 1526:         if 'alias' not in params:
You've convinced me :-)
Line 1527:             self.log.error('Missing the required alias parameters.')
Line 1528:             return {'status': {'code': errCode['MissParam']['status']['code'],
Line 1529:                                'message': 'Missing the required alias '
Line 1530:                                'parameter'}}


Line 1563:         netParam = params.get('network')
Line 1564:         if netParam is None:
Line 1565:             # If no network is specified we take the vnic to the dummy bridge
Line 1566:             # and set the link 'down' always.
Line 1567:             source.setAttribute('bridge', DUMMY_BRIDGE)
Because not specifying a network is a way of dissociating the vnic from that network, thus, putting it somewhere else -> dummy bridge.
Line 1568:             link.setAttribute('state', 'down')
Line 1569:         else:
Line 1570:             # There is a network defined. Thus, we either just modify the link
Line 1571:             # status and/or move between network backends.


Line 1570:             # There is a network defined. Thus, we either just modify the link
Line 1571:             # status and/or move between network backends.
Line 1572:             if network != netParam:
Line 1573:                 # If a different network is specified. First we take the link
Line 1574:                 # down and then update the device to connect to the new bridge.
There where some reasons for it stated in the vdsm mailing thread about this feature. I will revisit them and try to lay them out here again.
Line 1575:                 link.setAttribute('state', 'down')
Line 1576:                 try:
Line 1577:                     self._dom.updateDeviceFlags(
Line 1578:                         vnicXML.toxml(encoding='utf-8'),


Line 1614:                 for mirrNet in params.get('portMirroring', []):
Line 1615:                     supervdsm.getProxy().setPortMirroring(mirrNet, netDev.name)
Line 1616:                     mirroredNetworks.append(mirrNet)
Line 1617:             except Exception, e:
Line 1618:                 # In case we fail, we rollback the whole updateIntefaceDevice.
Well, in fact I want to do both, rollback if not succeeding and in success case return the VM xml.
Line 1619:                 for mirrNet in mirroredNetworks:
Line 1620:                     supervdsm.getProxy().unsetPortMirroring(mirrNet,
Line 1621:                                                             netDev['name'])
Line 1622:                 # TODO: Rollback link and network.


Line 1626:                         {'code': errCode['updateDevice']['status']['code'],
Line 1627:                          'message': e.message}}
Line 1628: 
Line 1629:         # TODO: Update the VM conf and Nic instance.
Line 1630:         self._getUnderlyingNetworkInterfaceInfo()
I will study this to more detail to see if we can just rely on the return values of the libvirt operations to infer the real libvirt status, update the conf and the network objects and return the vm definition.
Line 1631: 
Line 1632:         return {'status': doneCode, 'vmList': self.status()}
Line 1633: 
Line 1634:     def updateDevice(self, params):


....................................................
File vdsm/vdsmd.init.in
Line 486:     then
Line 487:         log_failure_msg "$prog: Failed to create ephemeral dummy bridge."
Line 488:         return $ret_val
Line 489:     fi
Line 490: 
I'm not sure either. I don't see a big need to do it now, that vdsm networks are not following the dynamic configuration paradigm.
Line 491:     @VDSMDIR@/vdsm-restore-net-config
Line 492:     /usr/bin/vdsm-tool load-needed-modules
Line 493:     mk_data_center
Line 494:     mk_core_path


--
To view, visit http://gerrit.ovirt.org/9562
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I3b9b4f49f80466a83e3e13f1042ac2a8866c6bcd
Gerrit-PatchSet: 14
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Antoni Segura Puimedon <asegurap at redhat.com>
Gerrit-Reviewer: Alona Kaplan <alkaplan at redhat.com>
Gerrit-Reviewer: Antoni Segura Puimedon <asegurap at redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken at redhat.com>
Gerrit-Reviewer: Igor Lvovsky <ilvovsky at redhat.com>
Gerrit-Reviewer: Livnat Peer <lpeer at redhat.com>
Gerrit-Reviewer: Mark Wu <wudxw at linux.vnet.ibm.com>
Gerrit-Reviewer: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
Gerrit-Reviewer: oVirt Jenkins CI Server


More information about the vdsm-patches mailing list