Hrvoje,
Happy new year to you as well (and everyone else on the list)!
I agree with you that the second solution is better. I have added
our discussion to the ticket...
http://dev.zenoss.org/trac/ticket/131
Anyone else have input to give on this one?
-EAD
On Jan 2, 2007, at 3:25 AM, Hrvoje Habjanić wrote:
Hi! And happy new year! :-D
On Saturday 30 December 2006 00:13, Erik A. Dahl wrote:
Hrvoje,
Added the patches with some minor mods thanks for the input!
Great.
Clearly
we need to do a little better with the way performance templates work
so that they can augment as well as override higher level templates.
I have thought of two possible ways to do this. First is to allow
multiple templates to be bound to an object. These can be selected
from any level of the hierarchy above the current location. The
second is to accumulate datapoints, thresholds and graphs up the
chain overriding any objects that have the same name. Second way
would be more like normal inheritance.
Any thoughts on which is more desirable?
The first one will, probably, prove to be very complicated. Please
note that
in the first case, you also need sorting-and-overriding function. This
function would probably be very complicated because you need to:
- sort all data (templates) by depth
- disable/delete from chain all templates that have same name in
upper chain
- it becomes fuzzy - no more 1to1 mapping for devices ... this can
bring in
another problems ... :-(
The way i see it, second way is more "natural", and it seems to be
fairly
simple. You go down the chain, and insert into "cache". When there is
datasource/graph/threshold with same name in cache, delete it from
cache and
put the new one in. Note, there is no special sorting needed.
I vote for second version.
Also, i think, we need here some "null" template. For example,
assume that
parent template have "pero" datasource. If i wish to delete (not
override)
that from my current template, i would need to mark it "deleted" in
this
current template. That can be done with some kind of "null"
datasource, with
same name. I'm guessing it can be datasource with same name, but no
oid
specified in it, nor datapoint. It is just the way you display it.
It would
be nice to be disaplayed "grey", and you only can delete it (not
modify like
other sources).
H.
-EAD
On Dec 27, 2006, at 7:59 AM, Hrvoje Habjanić wrote:
Hi!
Sorry for any ... errors, since this is my first post to this
list. :-)
Attached are 3 files:
1. FileSystem.patch
- for some reason, function getRRDNames is returning wrong name,
and snmp
collector is then trying to open nonexistent file
2. HRSWRunMap.patch
- when we query system which has broken HRSWRun, there should be
another
check. For example, Tru64 returns empty string for Name of the
process
3. zenmodeler.patch
- here are 3 separate patches:
a) autoconversion for some reason doesn't work as expected, so
there is
one "float" casting. There should be better error checking ...
b) when starting another scan after finished previously one, we
miss "by-one",
because deleting from client array is after this check
c) when there is timeout on one of clients, code will not spawn
another scan
for some other client - it will just stop. I think that we could
keep going
from next client instead of "dying" here ...
I hope that this will get included in next release ... :-)
Also, one feature-request - it would be nice when "device" could
inherit
PerfConf from parent, instead of copying it on multiple
locations. For
example, if we have following structure (Sun and linux under Server
subdir):
/Device -> Server -> Linux
-> Sun
Then define sysuptime under "Server" perfconf. Be this, sysuptime
should be
visible under Linux and Sun perfconf, without need to make local
copy. The
idea behind this is that when i modify sysuptime, there is no need
to modify
all local copies in subdirs.
And keep up the good work! :-D
H.
<FileSystem.patch>
<HRSWRunMap.patch>
<zenmodeler.patch>
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users
