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 <[email protected]>
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 [email protected] or file a JIRA ticket
with INFRA.
---
