weingartner 50c4836c9f 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. ... Signed-off-by: wilderrodrigues <wrodrigues@schubergphilis.com>		2015-07-09 13:37:59 +02:00
..
resources/META-INF/cloudstack	Cleanup of Xen and XenServer terms. Cloned xen plugin creating a xenserver plugin, then removed xen plugin	2014-06-07 04:50:23 -04:00
src	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.	2015-07-09 13:37:59 +02:00
test/com/cloud/hypervisor/xenserver/resource/wrapper/xenbase	CLOUDSTACK-8607 - Improving unit tests	2015-07-06 14:58:17 +02:00
pom.xml	Bump master version to 4.6.0-SNAPSHOT after branching 4.5.0-SNAPSHOT	2014-10-29 14:54:23 +01:00