mray has changed the topic to: Zenoss Developers are here (10:04:22 AM)
10:04:41 AM mray: kells is the Dev on today's session, but other Zenossians lurk
10:04:57 AM kells: QubeZ: Can I get you to open a ticket on that, please?
10:04:58 AM rmatte: *glances around nervously*
10:05:15 AM Simon4: Zenossians... scary people
10:05:30 AM QubeZ: kells: sure
10:05:34 AM kells: Thank you!
10:06:05 AM rmatte: QubeZ: Maintenance mode affects servers in any state, Original can be screwy, it might have picked up the previous state of the device instead of the current state for whatever reason
10:07:02 AM kells: Well, you don't have a choice to what the return state is anymore (original).
10:07:21 AM rmatte: I try not to use maintenance windows because I've had bad experiences with them
10:07:33 AM kells: The original maintenance mode is saved on the device, and the maintenance mode *should* return it back to that saved device.
10:07:43 AM rmatte: I've had it where I moved 10 devices in to maintenance, 3 of the 10 at in Pre-Production state to begin with
10:07:47 AM kells: Yeah, there's a few bugs related to time changes.
10:08:04 AM QubeZ: rmatte: i have services that restart at 4am and need to add maintenace windows otherwise i get sms txt's at 4am which are very audible
10:08:05 AM rmatte: when the maintenance window is over, instead of moving to Original state, it moved them all to Production
10:08:14 AM rmatte: so I just do it by hand now
10:08:25 AM kells: I had thought that the nested windows/ overlapping windows was pretty solid since 2.5 though. It was a complete pain to get that going decently.
10:09:03 AM themactech: I have questions regarding the setup of a zenmail zenpop workflow
10:09:10 AM kells: Hmmm.... That's very weird.
10:09:12 AM themactech: anyone here familiar with it?
10:09:24 AM kells: Maybe...... <shudder>
10:09:34 AM rmatte: It's like the original production states aren't being stored or picked up properly
10:09:42 AM rmatte: *shrugs*
10:09:42 AM kells: There are some odd quirks with those ones (MS Exchange acts very oddly)
10:09:45 AM QubeZ: is there anything past 3.0? i know there were a tons of bugs in 3.0 that they were trying to fix in 3.0.1
10:09:54 AM mray: QubeZ: 3.0.2 is out
10:10:01 AM QubeZ: ill upgrade
10:10:02 AM kells: rmatte: That's probably an upgraded system then, right?
10:10:19 AM rmatte: kells: it was a 2.5.2 install
10:10:32 AM rmatte: though maintenance windows don't seem to have been changed at all between 2.5.2 and 3.0.2
10:10:52 AM themactech: traps still get thru maintenance windows though, that hasn't been fixed
10:11:09 AM kells: Maintenance windows haven't been changed since 2.5.2 to 3.0.2 with the exception of some time change fixes.
10:11:35 AM kells: Events will still be received during the windows, and that's not considered a bug. An alert, OTOH, would be a bug.
10:11:40 AM rmatte: themactech: really? they certainly don't get through decommed state, so why would they get through Maintenance state?
10:12:06 AM themactech: a machine set to maintenance by a maintenance window still sends alerts when receiving traps
10:12:14 AM kells: What happens is that traps and syslog events (which aren't polled, they're pushed by the endpoint) are received by Zenoss, even during MWs
10:12:18 AM rmatte: themactech: you need to add a rule to your alerting rules to only fire off when the device state is production
10:12:21 AM rmatte: themactech: that's just common sense
10:13:00 AM themactech: I agree there are workarounds, but a machine set to maintenance should not send alerts on traps
10:13:00 AM rmatte: I believe the idea is that you'll still want events to come in during maintenance windows so that you have an idea of what happened during the window
10:13:03 AM rmatte: but not alert on them
10:13:08 AM themactech: should be part of the maintenance window function
10:13:28 AM themactech: I do consider it a bug, albeit a minor one
10:13:34 AM rmatte: themactech: that would be very easy to do...
10:14:00 AM themactech: yeah but I haven't gotten intimate with transforms yet, it's on my to-do list
10:14:06 AM rmatte: themactech: create a new event class called Suppressed or something, and set it to -2 (in settings)
10:14:10 AM rmatte: -2:Suppressed
10:14:21 AM rmatte: then have the maintenance window set the devices to that state instead of Maintenance
10:14:30 AM rmatte: and voila, you have your expected behaviour
10:14:50 AM themactech: but then would I still get the alerts logged or will they all go away?
10:14:59 AM rmatte: you won't get alerts at all
10:15:03 AM themactech: I still want events to come in, just not trigger alerts
10:15:15 AM rmatte: it'll duplicate the functionality of the Decommissioned state, but under a different name
10:15:18 AM rmatte: meaning no alerts
10:15:35 AM themactech: I understand but will events still stay in the event console
10:15:39 AM themactech: which is what we want
10:15:55 AM rmatte: now you're confusing me, you want events, but you don't want events?
10:16:03 AM rmatte: you're wanting them sent to history?
10:16:17 AM fragfutter: what about adding a filter to your alert rule that only processes productive systems?
10:16:21 AM themactech: I want to be able to consult events that occured during a maintenance window, but not get alerts
10:16:49 AM rmatte: themactech: right, which is why you need to add an alerting rule not to alert on events when a device is in a maintenance state
10:17:08 AM rmatte: by default that rule gets added when you're creating a new alerting rule
10:17:09 AM themactech: A filter to alerts would work, but again these are all workarounds for what I consider a bug in the maintenance window function, how about just fixing the maintenance window function, wouldn't that be Plan A?
10:17:23 AM rmatte: How is that a bug?
10:17:26 AM themactech: ok, an alerting rule, not a transform
10:17:29 AM themactech: i get it
10:17:35 AM rmatte: yeh, an alert filter
10:17:48 AM themactech: I really don't think you should get alerts from traps sent to a machine in maintenance
10:18:01 AM themactech: That should not be the normal behaviour
10:18:02 AM kells: Hmmm.... We don't have an unit test for MWs and groups, systems
10:18:07 AM rmatte: yeh, but you're just one of many usage scenarios
10:18:17 AM rmatte: maybe some people want to receive them, but just not alert on them
10:18:24 AM rmatte: so they'd just add a filter to their alerting rules
10:18:31 AM fragfutter: system states (productive, maintenance) are only useful for filters, i think they don't change anything
10:18:33 AM rmatte: or perhaps someone wants to receive them but immediately move them to history
10:18:36 AM rmatte: so they'd write up a transform
10:19:00 AM themactech: I do want to receive the event, not get the alert, that is the normal behaviour for SNMP events, all except for traps
10:19:22 AM rmatte: right, so you add a filter, it takes 2 seconds to do
10:19:22 AM themactech: traps behave different then rest of events under a maintenance window, all I am saying is they should not behave differen t
10:19:40 AM rmatte: I don't get how they behave differently
10:19:42 AM themactech: yes, easy fix, but why not fix the source of the problem instead of implementing a workaround
10:19:43 AM rmatte: an event is an event
10:19:58 AM themactech: ok, lets say I put a Dell server in a maintenance window
10:20:04 AM rmatte: k
10:20:09 AM themactech: Now I pull one of the power supplies out
10:20:24 AM themactech: the SNMP POLLING event will come in, but not trigger an alert
10:20:44 AM themactech: the SNMP TRAP, will sent an event, but this one WILL trigger an alert
10:21:02 AM rmatte: ok, and the snmp trap comes in with a production state of Maintenance for the event I assume?
10:21:30 AM rmatte: so your argument is that Zenoss should know not to alert on the event without having an alert filter specified
10:21:48 AM themactech: I don't know the production state of the trap, but the device is properly set to maintenance by the maintenance window since all other SNMP event do not trigger alerts
10:21:57 AM themactech: yes for traps
10:22:23 AM themactech: it does it fine with everything else, but it seems that someone forgot a machine in maintenance state might receive traps as well
10:22:40 AM themactech: and those don't get filtered as they should
10:22:46 AM rmatte: Ok, here's a question...
10:22:49 AM themactech: this is probably a 10 minute fix for a developer
10:23:02 AM rmatte: when the trap comes in, is there an old trap sitting in the event console that it just increases the count on?
10:23:05 AM kells: Added ticket http://dev.zenoss.com/trac/ticket/7385 for unit tests on the MWs wrt checking group membership
10:23:06 AM rmatte: or is it a brand new trap?
10:23:16 AM themactech: new trap
10:23:20 AM rmatte: k
10:23:33 AM themactech: If I clear all the events in the console for that device it behaves the same
10:23:36 AM rmatte: I get what you're saying, but there are very simple workarounds to that
10:23:43 AM themactech: I know
10:24:01 AM rmatte: ...and there are bigger fish to fry when it comes to Zenoss
10:24:22 AM rmatte: If a guy comes in to the hospital with a heart attack, you don't treat the guy who stubbed his toe on a coffee table first
10:24:23 AM themactech: very simple in fact, but if you don't fix things because the workaround is simple, you end up down the road with 12 workarounds you need to put in
10:24:56 AM themactech: not saying they should drop everything but it should be on the to-do list
10:25:05 AM themactech: like i said its minor
10:25:18 AM rmatte: Is there a Trac ticket open for it?
10:25:25 AM themactech: I had opened one for 2.5.2
10:25:35 AM themactech: but I was told all tickets were cleared for 3.0
10:25:37 AM rmatte: Right, so it's on a very long to-do list
10:25:41 AM themactech: yup
10:25:54 AM rmatte: perhaps you should have a browse through trac and see all the other bugs/requests lined up, lol
10:25:56 AM fus10nx: Morning everyone
10:26:08 AM themactech: you are trying to drive me to suicide aren't you
10:26:11 AM themactech: lol
10:26:14 AM rmatte: not my intention
10:26:17 AM rmatte: you do that to yourself
10:26:34 AM rmatte: I'd be happy to write a 4 line transform for you that does exactly what you want during maintenance windows if you'd like
10:26:39 AM themactech: I personally have much more important things on my zenoss to-do list as well, so I won't be pushing this either
10:27:23 AM themactech: much appreciated but it's the perfect pet project for me to get my feet wet with transforms, I'll ping you if I can't figure it out, as always your support is greatly appreciated
10:27:35 AM rmatte:
10:27:40 AM themactech: right now I need to setup a zenmail zenpop workflow
10:28:10 AM themactech: I already have a heartbeat system working thru email that monitors the health of the zenoss daemons on my remote machines, all via email
10:28:26 AM themactech: now I need to sent all events via email thru zenpop zenmail
10:28:44 AM themactech: who is the developer on call today so I can bug him with this?
10:28:50 AM kells: That would be me
10:29:12 AM kells: Still trying to understand the "send all events via email"
10:29:14 AM themactech: soooo, how friendly are you with zenmail and zenpop?
10:29:16 AM kells: That sounds very odd
10:29:36 AM kells: I've done some debugging of them before
10:29:45 AM themactech: I have standalone zenoss setups at remote sites, I want the events sent via email, then picked up at our site and fed to our NOC
10:29:59 AM kells: They haven't been converted over to the new collector framework, so they're very grungy, code-wise
10:30:12 AM themactech: So our NOC replicates the client's event console without any live access to their network
10:30:28 AM kells: Heh. We have an enterprise feature that does that very nicely, but not via e-mail.
10:30:51 AM themactech: are you saying zenpop and zenmail are gone in 3.0.2?
10:30:55 AM kells: So you want a one-way push from one zenoss to another, right?
10:31:05 AM kells: No, they're still there
10:31:22 AM kells: But in this case I don't think that it's the tools you want to use atm
10:31:27 AM themactech: what I have manage to troll from the forums is zenoss can encode an event in an email and the decode it and assign it to a device at the other end, that's what I need
10:31:39 AM themactech: I would do it with scripting then?
10:32:05 AM themactech: like the way I pipe zenoss daemon status via email?
10:32:27 AM kells: That could be done that way, the problem is performance though.
10:32:45 AM themactech: Performance at which end, the sender or receiver?
10:32:50 AM kells: But to clarify, you just want a one-way push, right?
10:32:53 AM themactech: yes
10:32:57 AM kells: Cool
10:33:05 AM themactech: we have clients with strict security protocols
10:33:12 AM kells: The sender tends to die under heavy load with anything that uses pipes
10:33:22 AM themactech: the ability to replicate their event console at our end only via port 25 is a big feature
10:33:53 AM themactech: I monitor so far max 150 devices from remote sites
10:34:08 AM kells: So the crude first approximation is to set up an alerting rule to send events via e-mail from the remote to zenmail on the receiver
10:34:09 AM themactech: is that enough to turn my zenoss machine into a slug?
10:34:44 AM themactech: ok, so the first part to setting this up is getting zenmail up and running at our end
10:35:18 AM themactech: I also want to go thru a mail server, so the remote would send the event via email to the mail server, then our NOC zenoss machine would pull those emails from the mail server
10:35:27 AM kells: Yeah, but any event storm from even a few devices can be bad. It's all about the exact details of the setup with how "bad things" happen. With any setup there's going to be a worst case scenario, so you just have to understand what the worst case scenario is, and how your setup is going to react to it.
10:35:33 AM themactech: it would then go from A to B to C
10:35:54 AM kells: Of course, the flip side is that if you over-engineer it for one scenario, it might not work well for other ones.
10:36:15 AM kells: That sounds like a workable idea, yeah.
10:36:33 AM themactech: Is there any detailed info on settting up zenmail, I can't seem to find any, someone mentioned in the forum that you need to edit zenoss startup scripts to enable it, I have no idea what that means
10:36:55 AM kells: Oh, sorry, you want an in-between mail server?
10:37:02 AM themactech: yes
10:37:28 AM themactech: both the client machine and our NOC must not be visible on the WWW, so they would go thru a mail server for the transaction
10:37:37 AM kells: Actually, that should be fine too. But zenmail would still be running on the main Zenoss server. Yeah, that's cool.
10:37:43 AM kells: Sure.
10:37:52 AM kells: Let me check zenmail for a second
10:38:09 AM themactech: I feel that zemail is like the illegitimate child of zenoss, it doesn't get invited to the family parties
10:38:22 AM themactech: hence the lack of documentation
10:39:20 AM themactech: the whole point is to get complete NOC functionality without any inbound access to the client's network, that is a feature very appreciated by clients, specially those with tight network security
10:39:43 AM fragfutter: then initiate the vpn connection from the clients side
10:40:03 AM themactech: I need this to work even at sites that won't allow for that
10:40:25 AM themactech: but sending email thru their corporate mail server is usually ok since they can audit that traffic
10:41:24 AM fragfutter: i once wrote a program, that syncronized a distributed projects data over smtp/pop3 and i will never think of it again. placing huge wads of duct-tape just to avoid a resonable network setup is now unacceptable for me.
10:41:47 AM themactech: you are preaching to the quire
10:42:00 AM kells: So an event is created with the device being the sending Zenoss server (by default), and the subject line being the summary, and the message being the body of the e-mail. It then goes and does some other processing of the subject heading. Still looking....
10:42:10 AM kells: This is in ZenEvents/MailProcessor,py btw
10:42:49 AM themactech: but try as hard as you can to convince a client that VPN networks are secure, we deal with many clients that will simply not allow it
10:43:05 AM kells: Yeah, and they all get the same eventSeverity (at least from skimming through the code)
10:44:16 AM themactech: If I get this functionality up, we will switch over all our non-zenoss deployments over to Zenoss, that is MY motivation to get this working so I can drop older SNMP systems that were deployed before my time and that I really don't like
10:44:38 AM kells: Hmmm..... Looks like you would need to use transforms to de-mangle some of this and get what you want based on the contents of the e-mail
10:44:45 AM themactech: btw thanks for your help kells
10:45:03 AM themactech: From what I read the opposite daemon does this at the receiving end
10:45:12 AM themactech: This again is from the forums
10:45:45 AM themactech: so if zenmail encodes them, I was told zenpop decodes them and assigns to devices at the receiving end from the name of the device in the email
10:45:52 AM kells: zenpop? Yes, it does send events to another e-mail system. But you won't need it really, you can just use zenactions.
10:46:09 AM themactech: oh, that's news to me
10:46:12 AM kells: zenmail converts e-mails to events
10:46:18 AM themactech: I figured zenmail and zenpop worked together
10:46:43 AM kells: zenpop reads e-mails from a pop account and turns them into events
10:46:48 AM themactech: I am definitely saving this chat session
10:47:14 AM themactech: I would use a pop account for the email transaction, does zenpop read the email in the same format zenmail encodes it?
10:47:26 AM kells: So zenmail acts like a mail server and zenpop3 reads pop accounts.
10:47:55 AM themactech: sounds like what I need, point zenmail to my pop account from remote site, and pull it with zenpop from my NOC zenoss
10:47:59 AM kells: I was getting a zenpope3 little confused with the enterprise daemon that reads and writes e-mails.
10:48:17 AM themactech: but is there documentation out there on the nuts and bolts of setting this up?
10:48:30 AM kells: Hold on, that's not quite correct.
10:48:42 AM Grizmawe: Can anyone tell me where MAC addresses are held in the zope database? Im looking into writing a search provider that will search for the device that has a given MAC address but dont know what to search for...
10:48:59 AM kells: Both zenmail and zenpop3 do the conversion of an e-mail to an event. You need zenactions (ie on the remote end that you want to send events) to send out the e-mails.
10:49:08 AM themactech: there is a zenpack that give MAC address reports, maybe you could look into that zenpack to see how to address them
10:49:37 AM themactech: so zenaction is the trigger that pushed the event to zenmail
10:49:38 AM kells: The MAC addreses are in a catalog. I think 3.0.2 has the MAC address report so you should be able to re-use the report's plugins to get what you want.
10:49:40 AM Grizmawe: themactech, ahhh thanks... ill take a look
10:50:36 AM kells: Something like that. In your case, zenactions -(remote) > middle SMTP server -> zenmail or zenpop3 (main)
10:51:21 AM themactech: Ok, I think I got the workflow I need to use, how about docs on doing the zenmail and zenpop setup, does that even exist?
10:51:48 AM kells: Only in the code and what I've typed
10:52:11 AM themactech: that's pretty much a flashback of my entire zenoss experience
10:52:11 AM kells: You'll have to play with it a little bit because there's probably a few wrinkles that I missed from my quick glance at the code.
10:52:21 AM kells: Let me check the docs to double check.
10:52:41 AM kells: That feature doesn't get used a lot, and for our Enterprise customers there's a MUCH better way to do things.
10:52:46 AM themactech: It seems all the folks who got this running in the forums have the black and blue bruises on their forehead too
10:53:24 AM themactech: We are quoting the enterprise version for a large deployment, if we win the bid I will get to play with it.
10:53:26 AM kells: zenmailtx is the enterprise daemon I'm thinking of
10:54:04 AM themactech: ok, well I'll play with that, but my guess is I'll be bugging the on-call developer in 2 weeks as well
10:54:11 AM themactech: thanks for the help
10:55:55 AM kells: Hmmmm.... We do have some docs for it: docs/DOC-7738#d0e7372
10:57:10 AM kells: But it claims that MIME attachments get used for the event details. I missed that in looking through the code or it's trying to say something that I'm not quite understanding.
10:57:45 AM themactech: Ok, I'll save that doc and play with the process
10:57:54 AM kells: Coolio
11:07:38 AM rmatte: old news much?
11:07:40 AM rmatte:
11:08:00 AM fragfutter: s/Now/still/g
11:08:17 AM rmatte: hehe
11:15:59 AM ericenns_: kells: how would I just make a title in the new ui
11:16:08 AM ericenns_: i.e for datasource
11:16:51 AM kells: A title? Where?
11:17:16 AM ericenns_: like instead of example Name: then a textbox, just have Name:
11:17:50 AM ericenns_: in edit data source
11:18:21 AM kells: Hmmm...
11:19:04 AM ericenns_: I want for example to have Name: then option under there which each having a title
11:19:24 AM kells: Well, if you're subclassing a datasource (eg a particular type of COMMAND data source) then you might have a JS that is specific to that type and bind to it (eg through a mapping in the configure.zcml)
11:20:10 AM ericenns_: hmm, I don't really know any java script and I know it was possible in the old ui
11:20:31 AM ericenns_: I am triying to go through the new ui and find an example
11:20:50 AM kells: Yeah, I don't think that we have any examples of that in Core, just in Enterprise.
11:21:35 AM ericenns_: ok hmm
11:21:52 AM ericenns_: there is no schema.Title?
11:22:32 AM fragfutter: what happens if you add more ram to a system?
11:22:34 AM fragfutter: ...
11:22:45 AM fragfutter: developers eat it up and ask for more.
11:22:46 AM mray: fragfutter: it gets remodeled and updated
11:22:53 AM mray: mmm… tasty
11:23:00 AM Simon4: nom nom nom ram
11:23:35 AM kells: Heh. In 3.1 we should be able to give a lot of RAM back.
11:23:51 AM fragfutter: so i need to upgrade my developers to 3.1?
11:24:19 AM kells: Chet did some great stuff in using memcache and relstorage, and there were a number of other people (esp Ian) who did the productization for 3.1
11:24:25 AM st3v3o: When a device has an issue, does zenoss start to obsess over the event the higher the count ?
11:24:34 AM kells: No
11:24:42 AM cgibbons: Jevons paradox, baby!
11:25:44 AM kells: re: schema.Title, there is a title element, but I don't think it gets used, except in 'Details' forms on components.
11:25:45 AM kells: I think
11:25:49 AM davetoo: how far away are we from 3.1 beta, ya think?
11:26:03 AM cgibbons: really far
11:26:05 AM kells: Gonna be a while
11:26:08 AM davetoo: ok
11:26:10 AM davetoo: heehee
11:26:33 AM davetoo: I have a probable customer who wants to do HA with Core...
11:26:46 AM davetoo: thinking about how Relstorage affects that plan
11:27:33 AM kells: A few more daemons to swing, I think
11:27:46 AM kells: Other than that, I don't forsee anything else.
11:28:16 AM kells: In 3.1 we hope to make it a little more friendly for heartbeat, but that's VERY cosmetic (ie saner return codes from the shell scripts)
11:28:21 AM davetoo: What changes have to be made to which daemons?
11:28:35 AM davetoo: or is that more about ZenCollector?
11:28:46 AM kells: More about zenhub atm
11:28:59 AM davetoo: oh?
11:29:09 AM kells: Oh yeah, zodb moves into MySQL
11:29:16 AM kells: No more zeo daemon
11:29:37 AM davetoo: right, figured that out when I was looking at the trunk (by accident, trying to help somebody debug somethign)
11:29:59 AM davetoo: but what changes are being made to/regarding zenhub?
11:30:37 AM kells: They've done a lot of tuning and tweaking to improve zenhub performance, connections to MySQL, removal of bad things etc etc
11:30:47 AM davetoo: *nod*
11:30:55 AM kells: The zenstatus daemon was apparently a resource drain as well, so it got a rewrite.
11:31:17 AM kells: The next culprit is zenping, but that daemon is maybe half-way done and is on hold atm
11:31:50 AM kells: There's going to be a LOT of under-the-hood changes in 3.1, so it should perform quite well.
11:31:52 AM davetoo: does it get a full graph model to replace the pingtree? (plz plz plz)
11:32:31 AM kells: ATM, the current rewrite uses networkx to do the graph representation, and pingtree has been completely tossed out the window.
11:32:47 AM rmatte: kells: sounds nice
11:32:50 AM davetoo: right on; I've played with networkx a little bit
11:33:12 AM kells: There's some conceptual parts that are VERY sketchy atm, but....
11:33:23 AM davetoo: I used it to model an NTP network
11:33:50 AM kells: The fallback plan is to go back to pingtree, though. That's only if we can't work out some conceptual problems.
11:33:55 AM davetoo: but at least in Enterprise there's some Java graph modeling, though, right?
11:34:32 AM kells: The y-files graphign stuff? Yes, it's there, but it won't be tied to the zenping stuff (at least not in Avalon)
11:34:37 AM davetoo: ah
11:34:39 AM rmatte: kells: Is the move to MySQL going to eliminate the issue where the Zope database grows and eventually requires a zeopack?
11:34:52 AM davetoo: well, it couldn't be, because it can't go into core. Duh.
11:35:07 AM kells: I think that zeopack will still be required.
11:35:07 AM davetoo: I was confused
11:35:15 AM rmatte: kells: ah ok
11:35:26 AM kells: heck, mysql also needs to be redone every once in a while, so....
11:35:50 AM fragfutter: can i wish for Layer2 modelling?
11:36:04 AM rmatte: From what I hear, besides the performance improvements every other new feature is enterprise specific
11:36:23 AM kells: Right now Layer 2 modeling is off the table. We asked for time to do it, but there are other priorities ahead of it.
11:36:37 AM rmatte: kells: what about manual dependencies?
11:36:42 AM rmatte: adding the ability to just do it by hand
11:36:47 AM kells: Not at the moment
11:36:58 AM rmatte: indeed
11:36:59 AM cgibbons: it's not even on the radar
11:37:18 AM rmatte: yet it's one of the most requested features lol
11:37:19 AM cgibbons: let's say our top-n priority list is 255 deep, it's probably 300
11:37:19 AM rmatte: oh well
11:37:22 AM davetoo: I haven't figured it out, but the workaround is to add "fake" routes, right?
11:37:45 AM rmatte: There was the post on the forums asking what people wanted to see in 3.0, and every second post was about dependencies
11:38:06 AM rmatte: davetoo: that fake route this is massively tedious
11:38:13 AM rmatte: s/this/thing
11:38:14 AM xuru: Can anyone help me with this... I've tried just about everything except reinstalling. ZenModeler seems to go out to lunch every 10 minutes
11:38:37 AM Simon4: xuru: feed it more often
11:38:44 AM xuru: hehe
11:38:47 AM rmatte: xuru: Execute zenmodeler run -v10 --cycle
11:38:48 AM kells: Before completely ruling out dependencies, we'll have to see what actually happens for the event transform engine.
11:38:51 AM rmatte: and then watch for errors
11:39:05 AM kells: I don't know how far they're going to get, but they have some really cool ideas.
11:39:20 AM kells: But, feature wise, probably not going to make it into 3.1
11:39:33 AM xuru: it spits this out in the logs every half second: WARNING zen.ZenModeler: Client ks-mgmt-02.kingsolutions.local timeout
11:39:34 AM rmatte: I'd just like to see it in the next 2 years
11:39:35 AM davetoo: I want to learn how to write a daemon.. to wrap SEC and send Events to it
11:39:44 AM xuru: usually a different server
11:39:57 AM davetoo: WARNINGS are just that
11:40:04 AM rmatte: xuru: This is that Linux server you're trying to model
11:40:17 AM davetoo: but if you have enough timeouts, nothing'
11:40:23 AM rmatte: xuru: When I asked you to do the snmpwalk the other day, did you actually let it run all the way to completion?
11:40:24 AM davetoo: going to get done
11:40:36 AM xuru: rmatte: yes
11:40:50 AM kells: davetoo: Look at the documentation stuff written in ZenCollector/daemon.py, interfaces.py and then check out the closest daemon to what you want to do.
11:40:56 AM rmatte: davetoo: I've run in to that issue before, but the problem for me was that snmp on the device that I was modelling was screwed...
11:41:02 AM cgibbons: __init__.py first in that package
11:41:06 AM rmatte: davetoo: It would spit out snmp info up to a point then end with a timeout
11:41:07 AM cgibbons: has the overview docs
11:41:15 AM cgibbons: the 'how to write a daemon' docs
11:41:21 AM kells: In trunk, zenstatus, zenperfsnmp and zencommand have been rewritten so there are a LOT of good examples now.
11:41:27 AM xuru: whoa, I actually have a traceback this time in the logs
11:41:32 AM cgibbons: zenwin, zeneventlog, zenprocess, too
11:41:32 AM davetoo: kells: thanks. I was reading some of the Twisted docs the other day.
11:41:42 AM rmatte: xuru: good, pastebin it
11:42:34 AM ericenns_: kells: So I figured out how to make a label, now is there a way to make other items left justified?
