On 08/29/2012 12:26 PM, Tomáš Hrčka wrote:
---
src/dbomatic/dbomatic | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/dbomatic/dbomatic b/src/dbomatic/dbomatic
index 76fadf6..b20af71 100755
--- a/src/dbomatic/dbomatic
+++ b/src/dbomatic/dbomatic
@@ -33,7 +33,7 @@ dbomatic_pid_dir = "/var/run/aeolus-conductor"
# $dbomatic_timeout is also our polling interval between cloud status checks
$dbomatic_timeout = 60
$realms_timeout = 300
-$deltacloud_timeout = 30
+$deltacloud_timeout = 100
this timeout might be increased, but it should never be higher than
dbomatic_timeout. I think changing this to let's say 50 could help
little bit with connection timeout issues.
optparse = OptionParser.new do |opts|
opts.banner = <<BANNER
@@ -189,7 +189,7 @@ end
def check_one_account(account)
connection = account.connect
- account.instances.each do |instance|
+ account.instances.order("updated_at ASC").each do |instance|
# optimization; right now we ignore instances that are in the STOPPED,
NEW, or CREATE_FAILED states.
# when we get to stateful instances, this will need to change
unless [Instance::STATE_NEW, Instance::STATE_STOPPED,
Instance::STATE_CREATE_FAILED].include?(instance.state)
This works almost fine, only disadvantage is that instances which are
vanished for a long time will be always prioritized as first (updated_at
attribute will not be increased for them since there will be no state
change). We might add additional attribute "checked_at" and this
attribute would be updated always before state check request is invoked
from dbomatic. What do you think?
Jan
