[Libvirt-cim] [PATCH] [TEST] Adding 05_RAPF_err.py to verify RAPF

[Deepti B Kalakeri]

Kaitlin Rupert wrote:
> Deepti B Kalakeri wrote:
>>
>>
>> Dan Smith wrote:
>>> DK> +def check_bridge_name(bridgename):
>>> DK> +    bridge_list = live.available_bridges(server)
>>> DK> +    vbr = None DK> +    if bridgename in bridge_list:
>>> DK> +        import random
>>> DK> +        vbr = bridgename + str(random.randint(1, 100))
>>> DK> +        if vbr in bridge_list:
>>> DK> +            logger.error('Need to give different bridge name 
>>> since it already exists')
>>> DK> +            return None
>>> DK> +    else:
>>> DK> +        vbr = bridgename
>>> DK> +    return vbr
>>>
>>> I think this would make a lot more sense as:
>>>
>>>   def get_unique_bridge():
>>>       bridge = "invalid-bridge"
>>>         while bridge not in live.available_bridges():
>>>           bridge += str(random.randint(1,100))
>>>         return bridge
>>>
>>>   
>> Ok , will modify this.
>>> DK> +    if virt != 'XenFV':
>>> DK> +        bridge = vsxml.set_vbridge(server)
>>>
>>> Can you explain why this special case exists?
>>>
>>>   
>> The network information for the XenFV is getting assigned by default.
>> The def _devices(): section of the XenFV is calling the
>>
>> self.set_bridge(CIM_IP) and hence the bridge information is getting 
>> assigned by default.
>> While this is not the case with the Xen and KVM.
>
> KVM also calls set_bridge() in the _devices() call.
>
> Xen does not, but the _devices() call for Xen sets the interface as an 
> ethernet type.  So there's no need to set a bridge for the Xen case.
Wrt to the tc when working with NetRASD requires the domain to be 
created with interface type as bridge.
NetRASD lists the domains which are created with bridge as the network 
type. Please correct me if I am wrong.
I suggest we keep the default network type for all the three Virtual 
types to be bridge and the give
another function which allows to add network type other than bridge to 
the domain when required