Status: Accepted
Owner: ----
Labels: Type-Defect Milestone-Release2.7 Priority-Critical
New issue 324 by [email protected]: Network locking is defective and has
other issues
http://code.google.com/p/ganeti/issues/detail?id=324
Below is a list of issues I found in LUNetwork* and related code during a
quick review. There might be more.
General:
- Why are so many errors.AddressPoolError swallowed silently?
- Exception handling should be more targeted, e.g. try: pool.Reserve(…);
except …: pass; else: logging.info(…)
LUNetworkAdd:
- Uses nodes without locking
- CheckPrereq: MAC address check can go into CheckArguments, should use
custom error message as the second half is hardcoded
Exec uses hardcoded IP address family (“4”)
LUNetworkRemove:
- Uses node groups without locking
LUNetworkSetParams:
- ExpandNames: Gets network from config before actually having the lock
- CheckPrereq: Same issue as LUNetworkAdd regarding MAC address
_NetworkQuery:
- Doesn't support synchronous queries
- Duplicate logic from _GroupQuery, should be abstracted
LUNetworkConnect:
- Doesn't lock network at all
- ExpandNames: Gets network and node group from config before actually
having the lock
- Doesn't lock node group
- Acquired instance locks are not verified (even though there's a
copy-and-pasted comment saying so)
- CheckPrereq: Uses cfg.GetInstanceInfo many times instead of one
GetMultiInstanceInfo
- Exec: Should use owned locks instead of calling cfg.GetNodeGroupInstances
again
LUNetworkDisconnect:
- Doesn't lock network at all
- ExpandNames: Gets network and node group from config before actually
having the lock
- Exec: Should use owned locks instead of calling cfg.GetNodeGroupInstances
again
lib/network.py:
- Lacks many docstrings
