Fleeting doesn't need plugins to keep track of this count (I believe it already has handling for things like "an instance wasn't deleted when it should have been" and "additional instances were unexpectedly provisioned"), and I suspect it could lead to concurrency-related bugs if Fleeting invokes plugin methods on multiple goroutines simultaneously.
In any case, it leads to frequent "ERROR: out-of-sync capacity" log messages which are actually entirely harmless. For example, after you ask OpenStack to destroy an instance, it takes a few moments before the instance is actually listed as deleted – if Fleeting calls Update() during that time, two such log messages would be emitted:
instance is scheduled for destruction, and g.size is decremented
Update() runs, observes an "extra" instance (because it's not yet destroyed), and g.size is "corrected" (causing a log message)
the instance is actually destroyed
Update() runs again, observes a "missing" instance (because it's now been destroyed), and g.size is corrected again (causing a second log message)
Fleeting doesn't need plugins to keep track of this count (I believe it already has handling for things like "an instance wasn't deleted when it should have been" and "additional instances were unexpectedly provisioned"), and I suspect it could lead to concurrency-related bugs if Fleeting invokes plugin methods on multiple goroutines simultaneously.
In any case, it leads to frequent "ERROR: out-of-sync capacity" log messages which are actually entirely harmless. For example, after you ask OpenStack to destroy an instance, it takes a few moments before the instance is actually listed as deleted – if Fleeting calls
Update()during that time, two such log messages would be emitted:g.sizeis decrementedUpdate()runs, observes an "extra" instance (because it's not yet destroyed), andg.sizeis "corrected" (causing a log message)Update()runs again, observes a "missing" instance (because it's now been destroyed), andg.sizeis corrected again (causing a second log message)