Re: [galaxy-dev] Cloudman/Galaxy autoscaling

2014-04-28 Thread Dannon Baker
Ahh, ok. No, that isn't exposed currently, though we've talked about better autoscaling control before and I can see how it would be valuable. If this is something you'd want to change in the near term, you could always run a custom version of cloudman (launching via your own bucket instead of ou

Re: [galaxy-dev] Cloudman/Galaxy autoscaling

2014-04-28 Thread Jim McCusker
I was thinking of the job idle time, where we spin up more instances if jobs sit waiting for, say, 15 seconds instead of 60. Jim On Mon, Apr 28, 2014 at 2:05 PM, Dannon Baker wrote: > The time after which it culls instances? It is not, but because of the > way Amazon bills for instances, you n

Re: [galaxy-dev] Cloudman/Galaxy autoscaling

2014-04-28 Thread Dannon Baker
The time after which it culls instances? It is not, but because of the way Amazon bills for instances, you never want to kill an instance until the end of the hour (since, regardless of when you kill an instance, you're billed for the remainder of the hour). -Dannon On Fri, Apr 25, 2014 at 3:01

Re: [galaxy-dev] Cloudman/Galaxy autoscaling

2014-04-25 Thread Jim McCusker
Thanks, is the idle time configurable? On Fri, Apr 25, 2014 at 2:43 PM, Dannon Baker wrote: > You can review the exact code here( see 'slow_job_turnover') : > https://bitbucket.org/galaxy/cloudman/src/7b8f04895ad309e0168cb3de66446ae20f3d8b3e/cm/services/autoscale.py?at=default > > But, basically

Re: [galaxy-dev] Cloudman/Galaxy autoscaling

2014-04-25 Thread Dannon Baker
You can review the exact code here( see 'slow_job_turnover') : https://bitbucket.org/galaxy/cloudman/src/7b8f04895ad309e0168cb3de66446ae20f3d8b3e/cm/services/autoscale.py?at=default But, basically, load on any particular node isn't very useful for autoscaling in this context because most jobs cann