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
..
baremetal	findbugs: masking fields removed	2015-06-24 12:24:12 +02:00
hyperv	Fix findbugs warning in HypervDirectConnectResource.java Two boxed Longs were being created instead of simple long	2015-06-15 12:09:34 +03:00
kvm	Merge branch 'improvement/CLOUDSTACK-8607' change the host password on the host itself via the updateHostPassword API	2015-07-06 16:15:22 +02:00
ovm	Fix findbugs DM_BOXED_PRIMITIVE_FOR_PARSING in OvmResourceBase.java	2015-06-22 10:50:48 +02:00
ovm3	Specify all dependency versions in pom.xml	2015-06-22 13:01:19 +02:00
simulator	Merge branch 'volume-upload' into master	2015-04-29 11:12:53 +05:30
ucs	Fix findbugs warning in UcsManagerImpl.java Integer was being created to assign value to int	2015-06-15 12:09:37 +03:00
vmware	CLOUDSTACK-8600. Upon detaching a disk, delete VM folder if empty.	2015-07-01 14:53:23 +02:00
xenserver	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