2) added "tags" request parameter to the banch of list* Api commands (listVirtualMachines, listSnapshots - all commands are listed in the resource tags functional spec)
Bug CS-14448: Wrong error message on using the createVlanIpRange cmd
Cherry-picking from master for bug 14448 into 3.0.x. Resolved
conflicts encountered during cherry-picking.
Description:
Adding overloaded addProxyObject() function to CloudException
and RuntimeCloudException classes and using this function
to stuff exceptions with IDs, to reduce code footprint.
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/resource/ResourceManagerImpl.java
Bug CS-14448: Wrong error message on using the createVlanIpRange cmd
Cherry-picking from master for bug 14448 into 3.0.x. Resolving
conflicts arising from the pick.
Description:
Modifying the API functions' exception handling to call
addProxyObject() wherever applicable, and removing some
wrong calls to addProxyObject() that were put in in an
earlier commit for this bug.
With this commit, we cover many API functions to use the
new exception handling code, but some pieces may still be
left out. These will be covered as work in progress, when
making changes to the CS API code.
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
server/src/com/cloud/resource/ResourceManagerImpl.java
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.
Summary of changes:
- applyLoadBalancerConfig(long lbRuleId) method applies only one rule if it is Netscalar otherwise applies all the rules in add/revoke state.
Summary of changes: Database changes will be rollbacked while applying the LB rule to the Netscaler device.
- Database changes will be rollbacked to previous state during the following Lb API's:
1) assignVM to LB rule
2) remove VM from LB rule
3) updateLb rule
4) deleteLb rule
5) create/attach sticky policy to Lb rule
6) delete sticky policy from Lb rule
- Database changes of the Lb rule will be not be rolledback during:
1) Removing IP
2) removing VM
Reviewed-by: Kishan
Changes:
- When an LB rule is deleted or the IP address having an LB rule configured is released, ExternalNetworkUsageCommand is fired to gather the usage
accumulated on that IP after the last run of the ExternalNetworkUsage job.
Summary of Changes:
- created a generic way for LB rule validations, so as LB device(like Haproxy) specific validations can be done syncronously.
- Removed asyncronous validations from Haproxy and done syncronously.
When elb capability is enabled on the network offering, we:
1) on each createLB command:
* associate ip address to the LB rule owner
* create LB rule
2) on each deleteLb command:
* delete the rule
* disassociate ip address
The rule belongs to the owner, so proper usage events are generated
2)Re-apply all existing firewall rules as a part of implement call. TODO: Cleanup all existing rules from the backend (leave them in the DB) as a part of shutdown call
Alena Prokharchyk
Vijayendra Bhamidipati
frank
prachi
kishan
Naredula Janardhana Reddy
Sheng Yang
Edison Su
Alex Huang
alena
Nitin