search

auser / poolparty

Run a self-healing, auto-scaled and monitored cloud simply, in the clouds, on nearly any hardware, such as EC2, eucalyptus and vmware
http://www.poolpartyrb.com
MIT License
371 stars 54 forks source link

extend monitoring to include user written monitors #5

Closed fairchild closed 15 years ago

fairchild commented 15 years ago

User definable monitors for cloud expansion and contraction. for example:

class MyLoadMonitor def run %x[uptime].split(/\s+/)[-1].to_f end end

The custome monitors could be loaded from the users .poolparty/monitors directory Then in the clouds.rb we could have something like

expand_when "my_load>1.0" 
contract_when "my_load<0.2", :votes_required=>"30%"
auser commented 15 years ago

Agreed. Should be relatively easy. I dig the votes_required syntax too

contentfree commented 15 years ago

For people managing multiple pools, we shouldn't load much (if anything) from ~/.poolparty. They should be relative to clouds.rb (so maybe a monitors directory adjacent to clouds.rb) or expressed inside clouds.rb itself.

fairchild commented 15 years ago

I think loading the monitors/ directory in the same dir as clouds.rb sounds like a good idea. We have a similar issue with plugins. Should we adopt a similar layout for plugins/ Or, maybe we should just autoload everything in a poolparty/ dir in the same dir as clouds.rb.

After writing the above, I think I would like, clouds.rb monitors/ plugins/ chef/

All being loaded by default. What do you guys think?

auser commented 15 years ago

This is in place