2011/5/2 Ronny Lindner <net-spider@users.sourceforge.net>
Hi!

I think I found another bug - I didn't write a minimal example yet but
something like this should trigger the bug:


yep it's one part of some others, all related to the current code handling the parsing of this service attribute :/

but as I said a fix for all that is in my pipe, just need that a few details be fixed :p

thx anyway,

regards,

greg



 

service {
hostgroup = this
host = !that
}

this seems to translate to "this OR NOT that".
And then I found something that's handled differently than in Nagios3:

In my Nagios Config I have several services with the same
service_description but a different service name. While Nagios uses the
name to identify a service, shinken warns about duplicate services and
seems to use the service description to identify a service.

These are just from memory, I'll try to send you a better test case for
the first bug tomorrow.

Bye, Ronny

Am 02.05.2011 21:00, schrieb Grégory Starck:
> hmmm,
>
> about below case that I'm "fully" on it (I am already deep in it so don't do
> anything on this specific case ;))  :
>
> """ parse(and after parse the "creation of the hosts list") problem of a
> "hostgroup_name" possible attribute of a service definition """ :
>
>
> does someone know if there exist somewhere a definition of the possible
> syntax for the expression value that can be set for this attribute ?
>
> more particularly about the "!" special char:
>
> i think (well I think it'd be good like that) that it should, syntactically,
> mean exactly something like :
> """
> not the members of :
>          the following group name (like " !  groupX")  (quite trivial case)
>     or the following (sub-)expression eventually, like "! (groupA&  groupB)"
>     ( == "not the members that are in both groups").
> """
>
> but in the current code it's implemented like :  """ all_hosts but not the
> members of the following subexpression """ :
>
>          # ! (not) should be changed as "ALL-" (all but not...)
>          if '!' in expr:
>              ALLELEMENTS = self.get_all_host_names_set(hosts)
>              # print "Changing ! by ALLELEMENTS- in ", expr
>              expr = expr.replace('!', 'ALLELEMENTS-')
>              hg_dict_mapping["ALLELEMENTS"] = ALLELEMENTS
>
>
> *shouldn't the "ALLELEMENTS" be in fact "all elements referenced by the
> current expression".*
> *
> *
> *Like if we have a hostgroup_name like this :*
>
> hostgroup_name     group1 , group2 , *!* group3
>
> with:
>   group1 = host1, host2, host3
>   group2 = host2, host3, host4
>   group3 = host2, host3
>
> but if in the config there is more hosts defined (like "host5, ...") then,
> as the code is actually, Houston we have a problem no, or am I missing
> something ??
> *
> *
> *personally I think this specific expression should result in the addition
> of the "host1" and "host4" hosts both (no more no less)  to the
> corresponding service..*
> *
> *
> *wdyt already of this ?*
> *
> *
> *
> *
> *more over, what about handling  the new case:*
>
> *hostgroup_name       expr1 ! expr2 *
>
> *where expr1 and expr2 would be 2 valid hostgroup_name expression, then the
> result of " expr1 ! expr 2"  would be : the hosts that are only in expr1 (so
> the members of the expr2 are removed from those of expr1).*
> *
> *
> *
> *
> *voilà that's my only 2 questions because the others operators are
> straightforward  ("*" and "&"  and "|"  (that's in fact quite useless
> because it does the same than "," imho).  (and there miss "^" that could
> also be very easily added/handled).*
> *
> *
> *
> *
> *regards,*
> *
> *
> *greg.*
> *
> *
> *
> *
> *
> *
> ---------- Forwarded message ----------
> From: shinken<noreply@sourceforge.net>
> Date: 2011/5/1
> Subject: Re: [shinken] #248: Parser bug
> To:
>
>
> #248: Parser bug
> --------------------------------------+-------------------------------------
>   Reporter:  net-spider                |       Owner:  leblutch
>      Type:  defect                    |      Status:  accepted
>   Priority:  major                     |   Milestone:
> Component:  Arbiter                   |     Version:  0.5 (Eruptive
> Earthworm)
>   Keywords:  parser hostgroup service  |
> --------------------------------------+-------------------------------------
>
> Comment(by leblutch):
>
>   well,
>
>   ok I've a fix that solve this specific bug but the problem is that I've
>   seen others bugs with the parsing of the hostgroup_name possible attribute
>   of a service/host definition.
>
>   Unfortunately these others bugs basically require a complete rewrite of
>   the functions doing this parsing job (when using complex hostgroup_name
>   expression).. I'm nearly done with it but not yet totally ;)
>
>   So in the meantime I'm already going to push the fix for this
>   case&substring problem within the hostgroups that can be put in
>   hostgroup_name directive.
>
>
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
>
>
>
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel