> On Feb. 5, 2013, 8:05 a.m., Koushik Das wrote: > > api/src/org/apache/cloudstack/api/ApiConstants.java, line 227 > > <https://reviews.apache.org/r/9191/diff/1/?file=254183#file254183line227> > > > > Why there are 2 ApiConstants.java? Which one is correct
Looks like format patch picked up 2 commits over this file. Updating the diff. > On Feb. 5, 2013, 8:05 a.m., Koushik Das wrote: > > api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java, > > line 87 > > <https://reviews.apache.org/r/9191/diff/1/?file=254185#file254185line87> > > > > Why only switch type and not name? Also where do they get stored? Any cluster that need to be added to cloudstack should already have the vswitches configured according to physical network configuration of zone. Switch type is supported here because administrator may like to use the same type of vswitch being used in that cluster. Name is not yet supported (its nice to have, and of course can be added as enhancement), administrator can rename vswitch as per physical network label before introducing that cluster to cloudstack. This point will be documented. > On Feb. 5, 2013, 8:05 a.m., Koushik Das wrote: > > server/src/com/cloud/configuration/Config.java, line 256 > > <https://reviews.apache.org/r/9191/diff/1/?file=254186#file254186line256> > > > > In the description you have mentioned that both nexus and vmware > > dvswitch is enabled/disabled. What happens to the existing parameter > > vmware.use.nexus.vswitch? > > > > Also if vmware.use.nexus.vswitch is enabled during cluster add VSM > > details are required, now what parameter governs that? Existing parameter vmware.use.nexus.vswitch still holds good. It would be activated only if vmware.use.dvswitch. Hence we use nexus 1000v dvswitch only when both the configuration parameters are true. If vmware.use.dvswitch is true by default VMware dvSwitch will be used. These parameters would be explained in documentation as well. > On Feb. 5, 2013, 8:05 a.m., Koushik Das wrote: > > server/src/com/cloud/configuration/Config.java, line 252 > > <https://reviews.apache.org/r/9191/diff/1/?file=254186#file254186line252> > > > > What is the upgrade logic? Since these are removed where do they get > > mapped to after upgrade? Thanks for bringing up upgrade scenario. These will be mapped to 1st field (comma separated field) of physical network traffic label for vmware. Added the mapping logic to upgrade manager's activity. - Sateesh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9191/#review16093 ----------------------------------------------------------- On Feb. 12, 2013, 1:17 a.m., Sateesh Chodapuneedi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9191/ > ----------------------------------------------------------- > > (Updated Feb. 12, 2013, 1:17 a.m.) > > > Review request for cloudstack, Murali Reddy and Kelven Yang. > > > Description > ------- > > This is 2nd patch for feature 'Support for VMware dvSwitch in CloudStack'. > > This patch introduces 2 new global configuration parameters > "vmware.use.dvswitch" - Enable dvswitch functionality. > "vmware.ports.per.dvportgroup" - Default number of ports per Vmware > dvPortGroup. > > > This addresses bug CLOUDSTACK-657. > > > Diffs > ----- > > api/src/org/apache/cloudstack/api/ApiConstants.java d242830 > api/src/org/apache/cloudstack/api/command/admin/cluster/AddClusterCmd.java > c64883c > server/src/com/cloud/configuration/Config.java 5e4996b > server/src/com/cloud/upgrade/dao/Upgrade40to41.java d3a8cd5 > > Diff: https://reviews.apache.org/r/9191/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 > >
