bedwards: hello, I am a Zenoss developer
cgibbons: ohnoes!
bedwards: are you driving?
cgibbons: nope i'm still asleep
rmatte: lol
mrayzenoss has changed the topic to: Zenoss Developers are here for your Questions (9:59:37 AM)
cluther: rmatte: Are you around to talk about ticket #4997?
rmatte: yessir
rmatte: ok people, so Chet and I are having a discussion in regards to the following Trac ticket: http://dev.zenoss.org/trac/ticket/4997
rmatte: we're bringing it in to the channel in case anyone else wants to jump in with opinions/suggestions
ckrough: oh, its thuirsday
cluther: Great. So what I'm still stubbornly thinking about this is that the ifOperStatus should be completely ignored when determining which interfaces to monitor, but ifAdminStatus plays an important role.
rmatte: I see what you're saying, and quite honestly that would be fine... but this is how I'd envision that working...
ckrough: Hmm
ckrough: as a rep of a NOC I would prefer NOT to see those merged.
cluther: ckrough: I'm glad you're here for this one.
rmatte: First off, when someone manually tells Zenoss to monitor a port, it should check the port at that time (without requiring a remodel) to see if it's admin down
rmatte: if it is, there should be some sort of dialog popup saying something like "The following ports are currently admin down and could not be set to monitored"
rmatte: If it's not admin down, then Zenoss should start monitoring the port
rmatte: none of this should require any kind of remodelling
cluther: Ah.. I like that.
ckrough: That sounds like a larger scope than #4997, what is that a solution for ?
rmatte: ckrough: It's a solution for the current behaviour of King Crab
ckrough: I'm not up to speed on the problem at hand
rmatte: ckrough: 4997 is what led to the problem, so it's really a regression related to 4997 in my opinion
cluther: rmatte: To put this into context the behavior for all versions leading up to King Crab (2.5) was completely ridiculous in that if the modeled ifOperStatus was down, the interface would not be monitored.
rmatte: If we need to open a new ticket for this then so be it
cluther: #4997 changed this from using ifOperStatus to ifAdminStatus.
cluther: So it is at least a small step in the right direction.
rmatte: cluther: gotcha, which is awesome and what I expected
ckrough: yeah, makes much more sense
ckrough: Are you saying that interfaces are automatically monitored if they are ifAdmonStatus UP at modelling time?
rmatte: cluther: let me try something, maybe I misinterpreted how it works due to the lack of a dialog indicating why it wouldn't let me select a certain port to be monitored
rmatte: ah I see, so if it's not admin down it does let you activate monitoring
rmatte: didn't realize that's what the new design was based on, definitely need some sort of popup dialog box explaining to the user why it's not letting them enable monitoring
rmatte: because everyone is pretty used to it just letting you enable monitoring on whatever you wish at this point
bedwards: the bug states that O/A is obvious to network admins. I disagree. operational and admin status is a well known concept, but using O and A to represent them is Zenoss specific and confusing to any new user.
cluther: Do you think that would suffice? Is remodeling the device too much to ask to get the current admin status? The reason I ask is that the only good alternative to doing this would be to stick ifAdminStatus in the ethernetCsmacd performance template to keep a more up-to-date view. This would add another data point to collect for every interface.
rmatte: cluther: I don't like having to remodel to get current admin status of ports, there's no reason why you can't make Zenoss just quickly check that when enabling monitoring on a port
cluther: rmatte: It becomes a bit trickier in distributed setups.
rmatte: cluther: some devices that we manage are in europe over really slow links and it takes like 30 minutes to remodel them
rmatte: so we basically never remodel them
rmatte: the fact that we need to do a full remodel just to enable monitoring on one port is insane
heckj: Are there any good guides/notes written out there for how to drive Zenoss programatically (REST or XMLRPC)? I've seen the notes in the community site about how to call methods, but haven't found much else
cluther: In the context of a 30 minute remodel I would agree.
rmatte: It's also very inefficient to have to remodel and have it poll tons of OIDs on the device when you only really need it to poll 1
rmatte: cluther: you kind of have to look at this from all possibilities including devices monitored over slow links, there are many applications for Zenoss and it's features should take things like slow networks in to account
rmatte: plus, from what I know about coding for Zenoss, wouldn't it just be another like 5 lines of code added to whatever function enables monitoring on interfaces to make it behave the way I'm describing?
cluther: Yeah.. the implementation is what bothers me though. We really don't like to have common UI operations actually go down and try to poll the devices. If you selected 400+ interfaces and enabled monitoring on them this would require 400 OIDs by polled.. potentially by a distributed collector that has the required network access to the monitored device. If the device was unreachable or slow this could take a very long time.
mrayzenoss: heckj: community/documentation/official_documentation/zenoss-dev-guide/
rmatte: well, we're monitoring hundreds of interfaces on one of our Zenoss boxes and it's not causing that major of performance issues honestly
rmatte: it's barely noticeable
rmatte: actually, probably thousands of interfaces, I'd have to check
ckrough: rmatte: zenoss box = a single zenoss install ?
mrayzenoss: heckj: community/developers
rmatte: ckrough: yeh
heckj: mrayzenoss: thanks, I was hoping for something a bit more external. I'm trying to drive Zenoss from another system - adding systems as they're spun up and setting the appropriate class from a customer facing UI by calling back to Zenoss in the background and using that as the core.
rmatte: cluther: oh sorry, I see what you meant
heckj: mrayzenoss: Ahh - this helps: docs/DOC-3563
mrayzenoss: heckj: we're seeing some weirdness with attached tarballs, if you can't untar that email me and I'll send it to you
rmatte: cluther: yeh, but that argument is kind of shot down when you consider the fact that if you need to remodel the device to enable those 400 interfaces, then you're not only polling those same 400 OIDs all at once, but also every other OID involved in a remodel
mrayzenoss: heckj: mray@zenoss.com
cluther: rmatte: True.
heckj: mrayzenoss: just nabbed it down and decompressed it - no issues.
rmatte: cluther: in most cases I would agree, but in this case I find that doing that would be totally acceptable
ckrough: I've got some boxes with over 4000 interfaces. How would this change affect soemthing like that
ckrough: some devices I mean
rmatte: actually the box I was talking about has well over 3000 interfaces
cluther: ckrough: I don't think it would affect you at all.. what we're talking about now really only matters to people who are manually setting certain interfaces to be monitored in the UI.
ckrough: cluther: I see
cluther: ckrough: You just let the modeler do it on its regular schedule.
rmatte: I manually set interfaces to be monitored all the time, since we monitor tons and tons of switches, and we don't care about all of the user ports on them
rmatte: I just want to be able to set ports to be monitored or not without having to remodel each device while doing it. I'd also like to see a popup dialog explaining that a device can't be set to monitored because it is currently admin down
rmatte: those 2 things would make it mint
ckrough: I want to monitor ports at the aggregation and distribution layers, but not access ports
rmatte: we just monitor trunk ports, and things like vlans on switches
rmatte: and the odd server port
cluther: rmatte: I think your proposal is a good one. I'm going to make a new ticket for it.
ckrough: but that should be compatible with the way we currently do it
rmatte: cluther: awesome
rmatte: cluther: and then throw built in active status monitoring in to the mix and you'll really have something there
rmatte: cluther: I assume we'll be able to modify that transform that you wrote for doing active status monitoring to actually change the status value of a device when it sees the port go down or up.
ckrough: I have a question for the devs. How do Config Cycles work? Are all configs sent or just changes, what if it's been 'asynchronously updated' in the meantime - posts in the forum claim that it doesnt update in this case. Does that mean it will still send configs for devices that have changed?
cluther: rmatte: I'll definitely be revisiting the transform for completeness as part of ticket #5627.
rmatte: cluther: does status represent interface.operStatus?
rmatte: In King Crab I mean
cluther: ckrough: The config cycle reloads everything. It is primarily a relic from when all of the daemons didn't support asynchronous updates.
cluther: rmatte: Status represents events for the particular interface in the /Status/IpInterface event class. Just like all other components.
rmatte: I'm thinking we could use the transform that I wrote up in http://dev.zenoss.org/trac/ticket/5376 to do the active status monitoring with your threshold method until it's actually natively implemented
rmatte: but I need to know what value needs to be toggled in zope to change the value of the status icon
cluther: rmatte: So once the transform creates the interface down event in that /Status/IpInterface event class, the status of the interface will reflect that.
cluther: rmatte: No Zope toggling required.
rmatte: ah, I see
rmatte: so if the threshold and transform listed in docs/DOC-2494 were moved from /Events/Net/Link to /Events/Status/IpInterface, it should display active status?
rmatte: Just trying to wrap my mind around how I'd get it working in the mean time until it's actually natively implemented
cluther: rmatte: In King Crab that is correct.
cluther: It's crucial that the component field of the event match the interface's name exactly.
rmatte: Ok, cool, I'll have to try that out
cluther: I believe the transform already does that though.
rmatte: yeh it does
rmatte: ok, sounds good
rmatte: http://dev.zenoss.org/trac/ticket/5548 needs to be addressed as well
rmatte: but that should hopefully be a quick one
cluther: rmatte: Could you review http://dev.zenoss.org/trac/ticket/5628 to make sure I've described the issue properly?
rmatte: sure
ckrough: dynamic modelling here we come
rmatte: cluther: well worded
mrayzenoss: anyone else have any questions?
mrayzenoss:
davetoo: yeah
davetoo: how do I encourage y'all to keep the ZMI working?
rmatte: mrayzenoss: what's your favourite breakfast cereal?
rmatte:
davetoo: there continue to be new properties added that aren't being initialized
mrayzenoss: davetoo: ummm... we're upgrading to Zope 2.11.2 with 2.5. Does that do anything?
cluther: davetoo: We just discussed this on Tuesday. We're seeing what we can do to do better testing for these omissions.
mrayzenoss: davetoo: did the beta work?
davetoo: I'm not sure, but I doubt it
davetoo: Which part of the beta?
davetoo: Actually all I have time to do right now is attempt to use the new enterprise SolarisMonitor plugin in my 2.4.5 systems
cluther: davetoo: I have ticket #5608.. let me know what other uninitialized properties you've found.
mrchippy: rmatte: mray's favorite breakfast cereal is meaty-o's, the only cereal made of puffed squares of roast beef.
davetoo: I'm not sure which versions of Solaris y'all used to develop this with, but none of mine have top in /usr/local/bin
mrayzenoss: davetoo: Solaris 9,10 and OpenSolaris I believe
rmatte: mrchippy: thanks for clearing that up
rmatte: nice to see so many devs online today
rmatte: usually it's just cgibbons
mrchippy: we like to lurk
mrayzenoss: they have to take turns answering questions
rmatte: ah
mrayzenoss: mrchippy prefers food-related questions
rmatte: hehe
davetoo: I keep forgetting that you do this on thursdays
rmatte: hmmm, think I'll go ahead and install the new beta, still working on beta 3...
davetoo: or .. some thursdays
heckj: mrayzenoss: one last question - what's the method and object that gets called to do the "Make local copy" to create a device specific template that you can adjust?
heckj: If one of you know if off the top...
mrchippy: i'll take a look real quick
mrayzenoss: I'm putting together an announcement about free beta tester t-shirts for King Crab tickets
mrayzenoss: rmatte and ckrough already have tickets for King Crab
mrayzenoss: so they're already in the queue
rmatte: I plan to have quite a few more soon too
rmatte: Once I have time to work on more testing
ke4qqq: *wonders if these shirts have 'I ate fresh crab' on them *
mrayzenoss: http://imagebin.org/66050
rmatte: that sounds like a food question, mrchippy?
mrchippy: heckj: obj.makeLocalRRDTemplate
cgibbons: odd
davetoo: here's a question that I probably already know the answer to
mrchippy: that crab looks like it's all hopped up on the goofballs
davetoo: I'm trying to figure out how to do dependencies other than layer 3
rmatte: mrchippy: yeh, chocolate goofballs
ckrough: softshell crab
davetoo: and I discovered the "dependents" and "dependencies" properties, which seem to be used by the zenpack system
rmatte: davetoo: only way is to manually build them using trannsforms
heckj: mrchippy: thank you, where would I have found that in the API docs? Poking around under ZenModel.Device and didn't see it - where should I be looking?
davetoo: would it be a really bad idea to abuse that for object instances and check them in transforms?
rmatte: zenpack dependencies are just if one zenpack depends on another
davetoo: I'm looking for a place to store the dependency info
davetoo: as relations
mrchippy: heckj: it's on the class RRDView which is inherited by all the template-bearing objects. d.makeLocalRRDTemplate( templateName ) should do the trick
davetoo: rather than as text
davetoo: I'm sure I should not re-use those relations, I guess
heckj: mychippy: perfect, thank you
rmatte: davetoo: docs/DOC-3231
mrchippy: heckj: as far as finding it, i did it by checking the url for the page for the templates on a device, which is ..../objTemplates. Then I went to objTemplates.pt which says that it call makeLocalRRDTemplate when the 'Make local copy' button is pressed.
rmatte: davetoo: there was also a guide for manually building layer 2 dependencies using transforms but I can't find it on the new site
davetoo: thanks
rmatte: hmmm, can anyone get ian to pop on for a bit?
rmatte: I've been wanting to speak with him about the event console
feutete: I asked this question yesterday, and then had to step away for a bit so I don't know if anyone responded...is it possible to query snmp on 2 ports on a single device?
ke4qqq: so while people are here - let me ask a question that shouldn't require devs, but is confounding me.
rmatte: feutete: what do you mean?
ke4qqq: feutete: last I heard, no
feutete: we have a webapp that listens on a high port and is essentially a snmp daemon providing stats on the appserver itself
feutete: kinda strange, I know
rmatte: oh I see, no, Zenoss can only do 1 port per device
feutete: but we also want to be able to query standard snmp
feutete: ok, i thought that was the case
feutete: thanks
rmatte: np
rmatte: ke4qqq: shoot
ke4qqq: feutete: I know some larger places have asked for that functionality - as Bea does that
ke4qqq: it's proc monitoring problem - I am trying to do some more rigid process monitoring - and used Jane Curry's paper to get my examples
ke4qqq: so I am monitoring parameters
ke4qqq: but it never finds them
ke4qqq: http://fpaste.org/y62J/
davetoo: I'm having really a lot of trouble having to monitor parameters
ke4qqq: ^^ has the line from ps and what I am monitoring
ke4qqq: am I missing something obvious???
ke4qqq: I am willing to document whatever the solution is.
rmatte: you can try using http://gskinner.com/RegExr/ to test your regex and make sure it's correct
davetoo: You might want to do an snmp walk to see what the snmp agent/daemon is providing
rmatte: yeh, I think he's already done that
ke4qqq: so I have done that - and it of course has process, path, and parameters in diff. oids, but it's all there
davetoo: and Ignore Parameters is set to False?
ke4qqq: davetoo: yes
cryptographrix: I'm having problems monitoring httpd still
cryptographrix: using the Apache zenpack, but httpd is often listed as 'down' except when I'm first adding it to OSProcesses
ke4qqq: if it's really a bug, I'll be happy to file a bug, but figure I am doing something stupid.
mrayzenoss has changed the topic to: Zenoss Beta 4 Is Now Available: http://tinyurl.com/ya437zl (11:19:02 AM)
cgibbons: ohnoes!
bedwards: are you driving?
cgibbons: nope i'm still asleep
rmatte: lol
mrayzenoss has changed the topic to: Zenoss Developers are here for your Questions (9:59:37 AM)
cluther: rmatte: Are you around to talk about ticket #4997?
rmatte: yessir
rmatte: ok people, so Chet and I are having a discussion in regards to the following Trac ticket: http://dev.zenoss.org/trac/ticket/4997
rmatte: we're bringing it in to the channel in case anyone else wants to jump in with opinions/suggestions
ckrough: oh, its thuirsday
cluther: Great. So what I'm still stubbornly thinking about this is that the ifOperStatus should be completely ignored when determining which interfaces to monitor, but ifAdminStatus plays an important role.
rmatte: I see what you're saying, and quite honestly that would be fine... but this is how I'd envision that working...
ckrough: Hmm
ckrough: as a rep of a NOC I would prefer NOT to see those merged.
cluther: ckrough: I'm glad you're here for this one.
rmatte: First off, when someone manually tells Zenoss to monitor a port, it should check the port at that time (without requiring a remodel) to see if it's admin down
rmatte: if it is, there should be some sort of dialog popup saying something like "The following ports are currently admin down and could not be set to monitored"
rmatte: If it's not admin down, then Zenoss should start monitoring the port
rmatte: none of this should require any kind of remodelling
cluther: Ah.. I like that.
ckrough: That sounds like a larger scope than #4997, what is that a solution for ?
rmatte: ckrough: It's a solution for the current behaviour of King Crab
ckrough: I'm not up to speed on the problem at hand
rmatte: ckrough: 4997 is what led to the problem, so it's really a regression related to 4997 in my opinion
cluther: rmatte: To put this into context the behavior for all versions leading up to King Crab (2.5) was completely ridiculous in that if the modeled ifOperStatus was down, the interface would not be monitored.
rmatte: If we need to open a new ticket for this then so be it
cluther: #4997 changed this from using ifOperStatus to ifAdminStatus.
cluther: So it is at least a small step in the right direction.
rmatte: cluther: gotcha, which is awesome and what I expected
ckrough: yeah, makes much more sense
ckrough: Are you saying that interfaces are automatically monitored if they are ifAdmonStatus UP at modelling time?
rmatte: cluther: let me try something, maybe I misinterpreted how it works due to the lack of a dialog indicating why it wouldn't let me select a certain port to be monitored
rmatte: ah I see, so if it's not admin down it does let you activate monitoring
rmatte: didn't realize that's what the new design was based on, definitely need some sort of popup dialog box explaining to the user why it's not letting them enable monitoring
rmatte: because everyone is pretty used to it just letting you enable monitoring on whatever you wish at this point
bedwards: the bug states that O/A is obvious to network admins. I disagree. operational and admin status is a well known concept, but using O and A to represent them is Zenoss specific and confusing to any new user.
cluther: Do you think that would suffice? Is remodeling the device too much to ask to get the current admin status? The reason I ask is that the only good alternative to doing this would be to stick ifAdminStatus in the ethernetCsmacd performance template to keep a more up-to-date view. This would add another data point to collect for every interface.
rmatte: cluther: I don't like having to remodel to get current admin status of ports, there's no reason why you can't make Zenoss just quickly check that when enabling monitoring on a port
cluther: rmatte: It becomes a bit trickier in distributed setups.
rmatte: cluther: some devices that we manage are in europe over really slow links and it takes like 30 minutes to remodel them
rmatte: so we basically never remodel them
rmatte: the fact that we need to do a full remodel just to enable monitoring on one port is insane
heckj: Are there any good guides/notes written out there for how to drive Zenoss programatically (REST or XMLRPC)? I've seen the notes in the community site about how to call methods, but haven't found much else
cluther: In the context of a 30 minute remodel I would agree.
rmatte: It's also very inefficient to have to remodel and have it poll tons of OIDs on the device when you only really need it to poll 1
rmatte: cluther: you kind of have to look at this from all possibilities including devices monitored over slow links, there are many applications for Zenoss and it's features should take things like slow networks in to account
rmatte: plus, from what I know about coding for Zenoss, wouldn't it just be another like 5 lines of code added to whatever function enables monitoring on interfaces to make it behave the way I'm describing?
cluther: Yeah.. the implementation is what bothers me though. We really don't like to have common UI operations actually go down and try to poll the devices. If you selected 400+ interfaces and enabled monitoring on them this would require 400 OIDs by polled.. potentially by a distributed collector that has the required network access to the monitored device. If the device was unreachable or slow this could take a very long time.
mrayzenoss: heckj: community/documentation/official_documentation/zenoss-dev-guide/
rmatte: well, we're monitoring hundreds of interfaces on one of our Zenoss boxes and it's not causing that major of performance issues honestly
rmatte: it's barely noticeable
rmatte: actually, probably thousands of interfaces, I'd have to check
ckrough: rmatte: zenoss box = a single zenoss install ?
mrayzenoss: heckj: community/developers
rmatte: ckrough: yeh
heckj: mrayzenoss: thanks, I was hoping for something a bit more external. I'm trying to drive Zenoss from another system - adding systems as they're spun up and setting the appropriate class from a customer facing UI by calling back to Zenoss in the background and using that as the core.
rmatte: cluther: oh sorry, I see what you meant
heckj: mrayzenoss: Ahh - this helps: docs/DOC-3563
mrayzenoss: heckj: we're seeing some weirdness with attached tarballs, if you can't untar that email me and I'll send it to you
rmatte: cluther: yeh, but that argument is kind of shot down when you consider the fact that if you need to remodel the device to enable those 400 interfaces, then you're not only polling those same 400 OIDs all at once, but also every other OID involved in a remodel
mrayzenoss: heckj: mray@zenoss.com
cluther: rmatte: True.
heckj: mrayzenoss: just nabbed it down and decompressed it - no issues.
rmatte: cluther: in most cases I would agree, but in this case I find that doing that would be totally acceptable
ckrough: I've got some boxes with over 4000 interfaces. How would this change affect soemthing like that
ckrough: some devices I mean
rmatte: actually the box I was talking about has well over 3000 interfaces
cluther: ckrough: I don't think it would affect you at all.. what we're talking about now really only matters to people who are manually setting certain interfaces to be monitored in the UI.
ckrough: cluther: I see
cluther: ckrough: You just let the modeler do it on its regular schedule.
rmatte: I manually set interfaces to be monitored all the time, since we monitor tons and tons of switches, and we don't care about all of the user ports on them
rmatte: I just want to be able to set ports to be monitored or not without having to remodel each device while doing it. I'd also like to see a popup dialog explaining that a device can't be set to monitored because it is currently admin down
rmatte: those 2 things would make it mint
ckrough: I want to monitor ports at the aggregation and distribution layers, but not access ports
rmatte: we just monitor trunk ports, and things like vlans on switches
rmatte: and the odd server port
cluther: rmatte: I think your proposal is a good one. I'm going to make a new ticket for it.
ckrough: but that should be compatible with the way we currently do it
rmatte: cluther: awesome
rmatte: cluther: and then throw built in active status monitoring in to the mix and you'll really have something there
rmatte: cluther: I assume we'll be able to modify that transform that you wrote for doing active status monitoring to actually change the status value of a device when it sees the port go down or up.
ckrough: I have a question for the devs. How do Config Cycles work? Are all configs sent or just changes, what if it's been 'asynchronously updated' in the meantime - posts in the forum claim that it doesnt update in this case. Does that mean it will still send configs for devices that have changed?
cluther: rmatte: I'll definitely be revisiting the transform for completeness as part of ticket #5627.
rmatte: cluther: does status represent interface.operStatus?
rmatte: In King Crab I mean
cluther: ckrough: The config cycle reloads everything. It is primarily a relic from when all of the daemons didn't support asynchronous updates.
cluther: rmatte: Status represents events for the particular interface in the /Status/IpInterface event class. Just like all other components.
rmatte: I'm thinking we could use the transform that I wrote up in http://dev.zenoss.org/trac/ticket/5376 to do the active status monitoring with your threshold method until it's actually natively implemented
rmatte: but I need to know what value needs to be toggled in zope to change the value of the status icon
cluther: rmatte: So once the transform creates the interface down event in that /Status/IpInterface event class, the status of the interface will reflect that.
cluther: rmatte: No Zope toggling required.
rmatte: ah, I see
rmatte: so if the threshold and transform listed in docs/DOC-2494 were moved from /Events/Net/Link to /Events/Status/IpInterface, it should display active status?
rmatte: Just trying to wrap my mind around how I'd get it working in the mean time until it's actually natively implemented
cluther: rmatte: In King Crab that is correct.
cluther: It's crucial that the component field of the event match the interface's name exactly.
rmatte: Ok, cool, I'll have to try that out
cluther: I believe the transform already does that though.
rmatte: yeh it does
rmatte: ok, sounds good
rmatte: http://dev.zenoss.org/trac/ticket/5548 needs to be addressed as well
rmatte: but that should hopefully be a quick one
cluther: rmatte: Could you review http://dev.zenoss.org/trac/ticket/5628 to make sure I've described the issue properly?
rmatte: sure
ckrough: dynamic modelling here we come
rmatte: cluther: well worded
mrayzenoss: anyone else have any questions?
mrayzenoss:
davetoo: yeah
davetoo: how do I encourage y'all to keep the ZMI working?
rmatte: mrayzenoss: what's your favourite breakfast cereal?
rmatte:
davetoo: there continue to be new properties added that aren't being initialized
mrayzenoss: davetoo: ummm... we're upgrading to Zope 2.11.2 with 2.5. Does that do anything?
cluther: davetoo: We just discussed this on Tuesday. We're seeing what we can do to do better testing for these omissions.
mrayzenoss: davetoo: did the beta work?
davetoo: I'm not sure, but I doubt it
davetoo: Which part of the beta?
davetoo: Actually all I have time to do right now is attempt to use the new enterprise SolarisMonitor plugin in my 2.4.5 systems
cluther: davetoo: I have ticket #5608.. let me know what other uninitialized properties you've found.
mrchippy: rmatte: mray's favorite breakfast cereal is meaty-o's, the only cereal made of puffed squares of roast beef.
davetoo: I'm not sure which versions of Solaris y'all used to develop this with, but none of mine have top in /usr/local/bin
mrayzenoss: davetoo: Solaris 9,10 and OpenSolaris I believe
rmatte: mrchippy: thanks for clearing that up
rmatte: nice to see so many devs online today
rmatte: usually it's just cgibbons
mrchippy: we like to lurk
mrayzenoss: they have to take turns answering questions
rmatte: ah
mrayzenoss: mrchippy prefers food-related questions
rmatte: hehe
davetoo: I keep forgetting that you do this on thursdays
rmatte: hmmm, think I'll go ahead and install the new beta, still working on beta 3...
davetoo: or .. some thursdays
heckj: mrayzenoss: one last question - what's the method and object that gets called to do the "Make local copy" to create a device specific template that you can adjust?
heckj: If one of you know if off the top...
mrchippy: i'll take a look real quick
mrayzenoss: I'm putting together an announcement about free beta tester t-shirts for King Crab tickets
mrayzenoss: rmatte and ckrough already have tickets for King Crab
mrayzenoss: so they're already in the queue
rmatte: I plan to have quite a few more soon too
rmatte: Once I have time to work on more testing
ke4qqq: *wonders if these shirts have 'I ate fresh crab' on them *
mrayzenoss: http://imagebin.org/66050
rmatte: that sounds like a food question, mrchippy?
mrchippy: heckj: obj.makeLocalRRDTemplate
cgibbons: odd
davetoo: here's a question that I probably already know the answer to
mrchippy: that crab looks like it's all hopped up on the goofballs
davetoo: I'm trying to figure out how to do dependencies other than layer 3
rmatte: mrchippy: yeh, chocolate goofballs
ckrough: softshell crab
davetoo: and I discovered the "dependents" and "dependencies" properties, which seem to be used by the zenpack system
rmatte: davetoo: only way is to manually build them using trannsforms
heckj: mrchippy: thank you, where would I have found that in the API docs? Poking around under ZenModel.Device and didn't see it - where should I be looking?
davetoo: would it be a really bad idea to abuse that for object instances and check them in transforms?
rmatte: zenpack dependencies are just if one zenpack depends on another
davetoo: I'm looking for a place to store the dependency info
davetoo: as relations
mrchippy: heckj: it's on the class RRDView which is inherited by all the template-bearing objects. d.makeLocalRRDTemplate( templateName ) should do the trick
davetoo: rather than as text
davetoo: I'm sure I should not re-use those relations, I guess
heckj: mychippy: perfect, thank you
rmatte: davetoo: docs/DOC-3231
mrchippy: heckj: as far as finding it, i did it by checking the url for the page for the templates on a device, which is ..../objTemplates. Then I went to objTemplates.pt which says that it call makeLocalRRDTemplate when the 'Make local copy' button is pressed.
rmatte: davetoo: there was also a guide for manually building layer 2 dependencies using transforms but I can't find it on the new site
davetoo: thanks
rmatte: hmmm, can anyone get ian to pop on for a bit?
rmatte: I've been wanting to speak with him about the event console
feutete: I asked this question yesterday, and then had to step away for a bit so I don't know if anyone responded...is it possible to query snmp on 2 ports on a single device?
ke4qqq: so while people are here - let me ask a question that shouldn't require devs, but is confounding me.
rmatte: feutete: what do you mean?
ke4qqq: feutete: last I heard, no
feutete: we have a webapp that listens on a high port and is essentially a snmp daemon providing stats on the appserver itself
feutete: kinda strange, I know
rmatte: oh I see, no, Zenoss can only do 1 port per device
feutete: but we also want to be able to query standard snmp
feutete: ok, i thought that was the case
feutete: thanks
rmatte: np
rmatte: ke4qqq: shoot
ke4qqq: feutete: I know some larger places have asked for that functionality - as Bea does that
ke4qqq: it's proc monitoring problem - I am trying to do some more rigid process monitoring - and used Jane Curry's paper to get my examples
ke4qqq: so I am monitoring parameters
ke4qqq: but it never finds them
ke4qqq: http://fpaste.org/y62J/
davetoo: I'm having really a lot of trouble having to monitor parameters
ke4qqq: ^^ has the line from ps and what I am monitoring
ke4qqq: am I missing something obvious???
ke4qqq: I am willing to document whatever the solution is.
rmatte: you can try using http://gskinner.com/RegExr/ to test your regex and make sure it's correct
davetoo: You might want to do an snmp walk to see what the snmp agent/daemon is providing
rmatte: yeh, I think he's already done that
ke4qqq: so I have done that - and it of course has process, path, and parameters in diff. oids, but it's all there
davetoo: and Ignore Parameters is set to False?
ke4qqq: davetoo: yes
cryptographrix: I'm having problems monitoring httpd still
cryptographrix: using the Apache zenpack, but httpd is often listed as 'down' except when I'm first adding it to OSProcesses
ke4qqq: if it's really a bug, I'll be happy to file a bug, but figure I am doing something stupid.
mrayzenoss has changed the topic to: Zenoss Beta 4 Is Now Available: http://tinyurl.com/ya437zl (11:19:02 AM)
