status 9688: resolved fixed
To verify that the rule was removed:
* make sure that there is no record with lb id in load_balancer table
* verify that lb.delete event was generated for this rule
Changes:
- When a host connects, we check if it has a CPU and RAM entry in capacity table. If the entry is found, the values are updated if possible. If the entry is not found a new one is inserted.
- The searchCriteria used to check if CPU entry is present was wrong. We were passing in a criteria which did not specify capacityType. So for hostId >= 200, the serach would return capacity entries of storage pools also since poolIDs start from 200 onwards.
- Since an entry was found (although the wrong one), we tried to update it. But update does not happen since the capacity ranges dont match.
And a new insert for CPU also does not happen since an entry is found.
- So as a result CPU entries are never inserted in the table for hostIds >=200
- As a fix, corrected the search criteria.
- During VM deployment, when the entry is not found, we get a NPE. Added a null check to avoid that.
Changes:
- When the ROOT volume of a VM is found to be READY, changed planner to reuse the pool for every volume(root or data) that is READY and that has a pool not in maintenance and not in avoid state
- If ROOT volume is not ready, we dont care about the DATA disk. Both would get re-allocated.
- When a pool is reused for a ready volume, Planner does not call storagepool allocators. And such volumes are not assigned a pool in the deployment destination returned by the planner. Accordingly StorageManager :: prepare method wont recreate these volumes since they are not mentioned in the destination.
- This NPE happened when starting the DomR and its Volume's podId was null.
- This case should never happen that podId of a Volume is null.
- It looks like this is a side-effect of some other bug- most likely another DomR and basic networking issue (9578)
- While reviewing this bug, found out that we need not use the RecreateHostAllocator anymore. Using it actually is not good, since this allocator ignores what is passed to it in the plan by the DeploymentPlanner and lists pods once again.
- Changed components.xml to use FirstFitRoutingAllocator instead.
David Nalley
alena
kishan
nit
Jessica Wang
prachi
Alex Huang
Edison Su
anthony
Kelven Yang
will
keshav
Frank
Murali Reddy