GitHub user rafaelweingartner opened a pull request: https://github.com/apache/cloudstack/pull/560
Cleaned class âcom.cloud.hypervisor.xenserver.resource.XcpOssResourceâ It seems that the class "XcpOssResource" was forgotten during the evolution of the ACS. It was removed a few methods that were already coded properly in its parent class âcom.cloud.hypervisor.xenserver.resource.CitrixResourceBaseâ. It was also removed some methods that seemed to cause weird behaviors. The methods removed/fixed are detailed as follows: ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.fillHostInfo(Connection, StartupRoutingCommand) â it was removed, because it always added the string â, hvmâ to the host capabilities. Therefore, if one uses XCP hypervisor it could cause a lot of trouble when deploying HVM virtual machines in an environment that has PV and HVM clusters. The method is already properly coded in parent class. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.launchHeartBeat(Connection) â It was removed. It was not performing anything and always returns a true value. The method of parent class is properly coded and works for XCP environments. The heartbeat plugin exists in XCP environment. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.initializeLocalSR(Connection) â it was removed. The method of the parent class works properly for XCP environments. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.createPatchVbd(Connection, String, VM) â It was removed. This method causes a bug in XCP environments, because of its half-implementation, it was not possible to migrate system VMs. The parent class implementation works properly for XCP. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.execute(NetworkUsageCommand) â removed, hence it was already coded into parent class and its respective wrappers (âcom.cloud.hypervisor.xenserver.resource.wrapper.xcp.XcpServerNetworkUsageCommandWrapperâ). BTW: I noticed that the class XcpServerNetworkUsageCommandWrapper and XenServer56NetworkUsageCommandWrapper are almost the same, with the exception that XenServer56NetworkUsageCommandWrapper deals with VPC. I believe that those wrappers could be converted into one, and moved to parent. I am not doing that here because I do not have a XCP environment with advanced networking to test it. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.executeRequest(Command) â removed, hence it is not needed anymor. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.execute(StopCommand) â I did not understand that method. It seemed weird and its removal did not change any behavior of the environment I tested it with. I strongly encourage you guys to review the classes XcpServerNetworkUsageCommandWrapper and XenServer56NetworkUsageCommandWrapper, I think they can be merged. I also believe that the VPN code should be execute to XCP, which today is not happening. You can merge this pull request into a Git repository by running: $ git pull https://github.com/rafaelweingartner/cloudstack master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/560.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #560 ---- commit b2704dd0faec61fc73c8faaa8b4045cad6648e44 Author: weingartner <rafaelweingart...@gmail.com> Date: 2015-07-04T15:12:02Z Cleaned class âcom.cloud.hypervisor.xenserver.resource.XcpOssResourceâ that seemed to be forgotten during the evolution of the ACS. It was removed a few methods that were already coded properly in its parent class âcom.cloud.hypervisor.xenserver.resource.CitrixResourceBaseâ. It was also removed some methods that seemed to cause weird behaviors. The methods removed/fixed are detailed as follows: ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.fillHostInfo(Connection, StartupRoutingCommand) â it was removed, because it always added the string â, hvmâ to the host capabilities. Therefore, if one uses XCP hypervisor it could cause a lot of trouble when deploying HVM virtual machines in an environment that has PV and HVM clusters. The method is already properly coded in parent class. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.launchHeartBeat(Connection) â It was removed. It was not performing anything and always returns a true value. The method of parent class is properly coded and works for XCP environments. The heartbeat plugin exists in XCP environment. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.initializeLocalSR(Connection) â it was removed. The method of the parent class works properly for XCP environments. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.createPatchVbd(Connection, String, VM) â It was removed. This method causes a bug in XCP environments, because of its half-implementation, it was not possible to migrate system VMs. The parent class implementation works properly for XCP. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.execute(NetworkUsageCommand) â removed, hence it was already coded into parent class and its respective wrappers (âcom.cloud.hypervisor.xenserver.resource.wrapper.xcp.XcpServerNetworkUsageCommandWrapperâ). BTW: I noticed that the class XcpServerNetworkUsageCommandWrapper and XenServer56NetworkUsageCommandWrapper are almost the same, with the exception that XenServer56NetworkUsageCommandWrapper deals with VPC. I believe that those wrappers could be converted into one, and moved to parent. I am not doing that here because I do not have a XCP environment with advanced networking to test it. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.executeRequest(Command) â removed, hence it is not needed anymor. ⢠com.cloud.hypervisor.xenserver.resource.XcpOssResource.execute(StopCommand) â I did not understand that method. It seemed weird and its removal did not change any behavior of the environment I tested it with. ---- --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---