Firewall manager was being used instead of LoadBalancingRules manager
while applying the load balancer rules in shut down network. Changing it
to LoadBalancingRules manager.
- Mgmt server impl is a pluggable service, fix it's method
- Fix getCommands() to return all cmd api classes supported by this mgmt server
- For api-discovery, get commands from pluggable services only, don't use reflections
- Don't use reflections in ApiServer, iterate pluggableservices
- Fix api discovery unit test
- The fix was done automatically using following python program along with
following step:
1. Get all apis provided by default mgmt server, all of them are in cloud-api now
cd api/src/org/apache/cloudstack/api/command
find . >> apis
2. For all apis, generate java code that adds the class to the cmdList arraylist:
f = open('apis', 'r')
data = f.read()
f.close()
output = ""
for a in data.split('\n'):
output += "cmdList.add(%s);" % a.split('/')[-1].replace('.java', '.class')
# wrote output to a file, copied content to mgmt server impl's getCommands()
# similarly, fixed import statements using same code, splitting on /
Testing:
Ran apiserver, put breakpoints in ApiServer's init() where classes are processed
Total cmd classes found by reflections (ReflectUtil) = 354
Total cmd classes found by getCommands for all pluggable services = 354
Next, copied the comma separated values for each set to a string in ipython, a & b
set(a).difference(set(b)) returned null.
The above test implies both set of cmd classes found by both methods, i.e. using
reflections and using getCommands() had same set of apis and all were unique.
Conclusion:
The changes are idempotent and don't break api server's cmd class api discovery
processing.
BUG-ID: CLOUDSTACK-1210
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
The new policy is:
1. Generate a random IP.
2. Find the next available IP, start from the generated IP.
3. If we cannot find an available IP after certain times(10000 by default,
network.ipv6.search.retry.max) retry, give up.
- Get rid of boolean decode arg
- Method assumes that OTW params have been already decoded
- Remove redundant code that tries to decode again based on boolean arg
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
The issue happens randomly when hosts in a cluster gets distributed across multiple MS. Host can get split in following scenarios:
a. Add host – MS on which add host is executed takes ownership of the host. So if 2 hosts belonging to same cluster are added from 2 different MS then cluster gets split
b. scanDirectAgentToLoad – This runs every 90 secs. and check if there are any hosts that needs to be reconnected. The current logic of host scan can also lead to a split
The idea is to fix (b) to ensure that hosts in a cluster are managed by same MS. For (a) only the entry in the database is going to be created except in case if the host getting added is first in the cluster (in this case agent creation happens at the same time) and then (b) will take care of connection and agent creation part. Since currently addHost only creates an entry in the db there is a small window where the host state will be shown as 'Alert' till the time (b) is scheduled and picks up the host to make a connection. The MS doing add host will immediately schedule a scan task and also send notification to peers to start the scan task.
