Hi,
I never thought about this. It sounds good, but it should ba an option (I
like to get host_name in address, it's the DNS role to do this after all),
but it can be fun as an arbiter module : it lookup all (or not) address at
the module starting, update the first conf pakages before being send to the
schedulers, then one a X minutes, it update all, and update the values in
the schedulers (will need an extra scheduler interface call, but should not
be so hard). With all in a module, admins will have all power on this, and
will not fear about it.
And with it, it will improve the arbiter modules way of working (update
instead of full rewrite) and the scheduler interface too (incremental update
instead of full one), so it's ok for a module, but not in the core I think,
because it's not to the core to to dns lookup one a X minutes, but it fill
perfectly to a module.
We can also add a "property" add feature for modules, because this one will
need an extra parameters for hosts. I'll look at it for the 0.6 feature
plan, so very very soon ;)
Jean
2011/1/15 Grégory Starck <g.sta...@gmail.com>
> hi dev guys,
>
> what would you think of this :
>
>
> (tests)greg@brutus:~/Documents/Projets/shinken$ git show
> bc37d7ee46dc03ab244a3c4af1406ad72c4a54e6
> commit bc37d7ee46dc03ab244a3c4af1406ad72c4a54e6
> Author: Grégory Starck <g.sta...@gmail.com>
> Date: Sat Jan 15 14:44:45 2011 +0100
>
> * host: try to get real address for address property if unprovided.*
>
> diff --git a/shinken/host.py b/shinken/host.py
> index e155b05..ff649c0 100644
> --- a/shinken/host.py
> +++ b/shinken/host.py
> @@ -26,6 +26,7 @@ scheduling/consome check smart things :)
>
> import time
> import re #for keys generator
> +from socket import getaddrinfo
>
> from shinken.autoslots import AutoSlots
> from shinken.item import Items
> @@ -624,7 +625,11 @@ class Host(SchedulingItem):
> # Fill adresse with host_name if not already set
> def fill_predictive_missing_parameters(self):
> if hasattr(self, 'host_name') and not hasattr(self, 'address'):
> - self.address = self.host_name
> + try:
> + self.address = getaddrinfo(self.host_name, 0)[0][4][0]
> + except Exception as e:
> + logger.log("Couldn't translate %s to address ; using it as
> address (err=%s)" % (self.host_name, e))
> + self.address = self.host_name
> if hasattr(self, 'host_name') and not hasattr(self, 'alias'):
> self.alias = self.host_name
>
> (tests)greg@brutus:~/Documents/Projets/shinken$
>
>
> on my side this permit me to declare in my hosts config with only the
> 'host_name' property set (and obviously I put in host_name the "dns" name of
> some hosts/servers that I want to monitor) and then the address property is
> then generated like above (so simpler config ; and if you want still to
> force a specific address for a host then just still declare/put the address
> attribute it in the host declaration in the cfg file).
>
> this permits to have nicer and "clean" view from Thruk map : all hosts -
> when display by ip address - are then correctly grouped by
> networks/subnetworks/.. ; well if you see what I mean and if you don't then
> check attached screenshot ;)
>
> but i don't know how that could affect good behaviors about everywhere..
> especially when there would be DNS change (somefqdn -> IP1 change to ->
> IP2) .. then the address field should be re-computed by some way..
>
> so eventually (if this previous "enhancement/change" would be ok) I could
> see and look for generating a kind of "dynamic" 'address' attribute in
> instances of host class :
>
> if address isn't explicitly provided in a host declaration : then the
> address attribute would be changed to a property so everytime it's accessed
> then we do a getattrinfo() and let the job be done by the OS name resolving
> facilities/functions..
> could even make this more robust : only redo a getaddrinfo once every X
> minutes or so and always cache the last correctly resolved address ; so that
> if on next refresh the dns system (local or remote) would be bad then we
> have still the last address previously used.. (if admin would see that dns
> system would stay down longuer than refresh_time : then he can eventually
> even force shinken to keep all current cached value by having some way..)
>
>
> so something like this:
>
> class host(..):
>
> ...
>
> def address_get(self):
> now = time()
> if not self._addr_cached_value or now - self._addr_last_refresh >
> self._addr_refresh_time:
> try:
> newaddr = getaddrinfo(self.host_name)...
> except:
> ## imho we should log that..
> if not self._cached_address:
> return self.host_name ## this still leave a chance to
> upper code to resolv it later on when value would be used..
> else:
> self._addr_cached_value = newaddr
> self._addr_last_refresh = now
>
> return self._addr_cached_value
>
>
> in fill_predictive_missing_parameters() :
>
> if not getattr(self, 'address', None):
> self._addr_cached_value = None
> self._addr_refresh_time = 3600 ## but could/should be put somewhere
> in some config file
> self._addr_last_refresh = 0
> self.address = property(address_get)
> self.address ## to do a first getaddrinfo and see if it resolved ok
> .. if not:
> if not self._addr_cached_value:
> log("can't get address of host %s" % (self.host_name))
> ## return failure ??
>
>
> and with this if ever we want to force for a particular host a new
> getaddrinfo we have only to do : "self._addr_last_refresh = 0" somewhere.
>
> but I'm unsure if we can use a python property for this attribute in host
> class and also on the good way of doing this (as hosts objects are passed
> from some place to others that can be on distinct servers or even networks..
> (and so could have different name resolving results ..! (but I think it'd be
> quite good like that)
>
> so wdy globally think of this ?
>
> regards,
>
> greg.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
