incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sateesh Chodapuneedi" <sateesh.chodapune...@citrix.com>
Subject Re: Review Request: Patch1 for feature - (CLOUDSTACK-657) VMware vNetwork Distributed Virtual Switch support in CloudStack
Date Thu, 07 Feb 2013 00:13:35 GMT


> On Feb. 5, 2013, 7:38 a.m., Koushik Das wrote:
> > plugins/hypervisors/vmware/src/com/cloud/network/VmwareTrafficLabel.java, line 48
> > <https://reviews.apache.org/r/9189/diff/3/?file=255404#file255404line48>
> >
> >     Based on the options that you have provided, parseLabel() (remove _ from method
name) will handle cases 4 & 5, what about 1, 2, 3. 
> >     
> >     [1] ""
> >     [2] "Name of vSwitch/dvSwitch"
> >     [3] "Name of vSwitch/dvSwitch","VLAN ID"
> >     [4] "Name of vSwitch/dvSwitch","VLAN ID","vSwitch Type" - Example: dvSwitch0,100,vmwaredvs
> >     [5] "Name of vSwitch/dvSwitch",,"vSwitch Type" - Example: dvSwitch0,,vmwaredvs
> >     The way you are handling networkLabel doesn't match the description you have
provided

Update patch with additional label processing.
Prefixing method name with _ as it is private method.
Referred to code conventions at http://incubator.apache.org/cloudstack/develop/coding-conventions.html.
Didn't see specific recommendation for private methods. Hence followed _ prefixing of private
methods in other places of cloudstack, to quote we can find _getSocket in RawHttp.java 


- Sateesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9189/#review16085
-----------------------------------------------------------


On Feb. 7, 2013, 12:13 a.m., Sateesh Chodapuneedi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9189/
> -----------------------------------------------------------
> 
> (Updated Feb. 7, 2013, 12:13 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Kelven Yang.
> 
> 
> Description
> -------
> 
> This is 1st patch for feature 'Support for VMware dvSwitch in CloudStack'.
> This contains 3 newly introduced classes. Added apache license header for all 3 files.
> [1]TrafficLable and [2]VmwareTrafficLabel classes are to define and encapsulate virtual
switch type per traffic type along with other network label fields (VLAN ID and physical network).
> [3]DistributedVirtualSwitchMO class is wrapper class for vSphere API calls specific to
a distributed virtual switch in a vCenter datacenter.
> Feature highlights:
> Virtual switch type could be chosen at zone level or at cluster level for specific traffic
type. All virtual network orchestration would use the specified virtual switch. So far CloudStack
could use only vSwitch of type standard vSwitch, with this feature CloudStack can use VMware
dvSwitch as well. Support for VMware dvSwitch is available for guest and public traffic types.
> autoExpand of dvPortGroup is available in code but disabled as its breaking because vCenter
4.1 does not support autoExpand feature.
> 
> 
> This addresses bug CLOUDSTACK-657.
> 
> 
> Diffs
> -----
> 
>   plugins/hypervisors/vmware/src/com/cloud/network/VmwareTrafficLabel.java PRE-CREATION

> 
> Diff: https://reviews.apache.org/r/9189/diff/
> 
> 
> Testing
> -------
> 
> Manual testing:-
> 1) Tested guest traffic over dvSwitch on a dedicated physical network. In this case management
and public traffic uses standard vSwitch on a common physical network.
> 2) Tested both guest traffic and public traffic over dvSwitch on a physical network.
> 3) Use optional parameters added to AddClusterCmd to override Zone level network traffic
label. Tested 2 clusters, one with standard vSwitch and other with dvSwitch.
> 4) Tested all 3 traffic types on single physical network with global parameter 'vmware.use.dvswitch'
set to false. This is default configuration scenario.
> 
> 
> Added following tests,
> 1) Test fetching dvSwitch object from vCenter
> 2) Test for presence of dvPortGroup
> 3) Test presence of dvPortGroup
> 4) Test get existing dvPortGroup
> 5) fetch dvPortGroup configuration
> 6) Test compare dvPortGroup configuration
> 7) Test update dvPortGroup configuration
> 
> 
> Thanks,
> 
> Sateesh Chodapuneedi
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message