Description:
1) Added a setProxyObject() method to CloudException and RuntimeCloudException
2) Modified a bunch of throw exceptions in NetworkManagerImpl.java to call setProxyObject() before throwing an exception.
3) Changed scope of ProxyIdentity attribute to protected.
4) Added routines to ServerApiException to get/set IdentityProxy object, and
routine in RuntimeCloudException to get the Idproxy object.
5) Modified the exception handling around the dispatcher and handlerequest()
to copy over the IdentityProxy information before rethrowing an exception
eventually back to handle().
6) Removed duplicate IdentityProxy object in ServerApiException.
It was extending RuntimeCloudException which already had an
IdentityProxy object.
Description:
1) Moved RuntimeCloudException from api/ to utils/.
Added simple constructor to RuntimeCloudException.
Modified all classes that extended RuntimeException
to extend RuntimeCloudException. These classes
are listed below:
ServerApiException
CloudAuthenticationException
CloudExecutionException
AsyncCommandQueued
HypervisorVersionChangedException
RuntimeCloudException
2) Added overloaded constructed to CloudException.
Modified all classes that extend Exception to extend CloudException instead.
These classes are listed below:
ConcurrentOperationException
ConflictingNetworkSettingsException
ConnectionException
DiscoveryException
InsufficientCapacityException
ManagementServerException
ResourceUnavailableException
VirtualMachineMigrationException
AgentControlChannelException
OperationTimedoutException.java
UnsupportedVersionException.java
UsageServerException.java
UnableDeleteHostException.java
AgentAuthnException.java
HttpCallException.java
ActiveFencingException.java
ClusterInvalidSessionException.java
GreTunnelException.java
OvsVlanExhaustedException.java
Description:
1) Adding two new classes, CloudException and RunTimeCloudException.
The former extends Exception and the latter RunTimeException.
These will be used by classes that formerly directly extended
Exception and RuntimeException. These two classes have an attribute
of type IdentityProxy to enable exceptions fill in db ids in separate
attribute fields rather than in a string. Doing so will allow the
serialization module (GSON for JSON and other for XML) to kick in
and convert this db id to a uuid in ApiServer.java just before the
JSON/XML responses are sent out.
2) Moving IdentityProxy.java from api/ to utils/ since
both CloudException and RuntimeCloudException refer to it.
3) Changing references to IdentityProxy class from api/ to utils/.
4) While rebasing to master, a new file was added, merging
api/src/com/cloud/api/response/IsoVmResponse.java to this diff.
Changes for Script.java:
1. Even the script is non-timeout one, set default timeout to one hour. This avoid a wrongn script forever hang
2. When InterruptedException happens, check if timeout is really reached, if not, continue
status 13962: resolved fixed
reviewed-by: Alex, Edison
Reviewed-by: Sheng Yang
Changes:
- Do not check if allocation_state is 'Enabled' in planner if the caller is Root Admin.
- This should let Root Admin create a VM in a disabled Zone.
Reviewed-by: Kishan
Changes:
- Separated out the External Network Usage task from the ExternalLBDeviceMgr because ExternalLbDeviceMgrImpl :: start() was getting multiple times during management server satrtup. The reason for this is that this is the baseclass for F5 and NetScalarElement.
- This caused us to schedule the ExternalNetworkUsageTask multiple times
- Also we have LBRulesMgr calling this ExternalLbDeviceMgrImpl by creating an instance of this class which is declared abstract
- Hence having a separate implementation to manage the network usage stats should solve this.
- configuring unique persistence profile for each LB rule with sticky method applied
- removing source based sticky method for source based LB method which is not supported by F5
And per Alex's request, add default value directly into the database, rather
than using it at last minute of implemention.
status 13829: resolved fixed
Reviewed-by: Alex
Reviewed-By: Alex
Changes:
- Reuse the same storagepool where the Volume is ready on each retry of VM deployment until the cluster where the volume is has capacity
- After the cluster is out of capacity, we look in other clusters and find a new storagepool.
- At this point if the volume is recreatable on the new storagepool, depoyment will succeed provided everytyhing else goes through
- But if the volume is not recreatable and its cluster is out of capacity, we will still fail to deploy the VM
Vijayendra Bhamidipati
U-CITRITE\vijayendra1
Kelven Yang
Alena Prokharchyk
frank
anthony
Sheng Yang
prachi
Edison Su
kishan
Murali reddy
abhi
Nitin Mehta