11:01:20 AM chickenandbeans: I could do with a hand on: message/44457
11:01:25 AM rmatte: ckrough: well, the problem is that I know that this device has a disk listed on the OS tab, and if I go to the management interface I can see that the property I'd need to grab is f.mount
11:01:30 AM rmatte: but it's not letting me
11:01:41 AM rmatte: actually, hmmm, I may know why
11:01:42 AM chickenandbeans: could be a bug, could be me
11:02:41 AM rmatte: bleh, nope, thought it might have been because the device was in decommed state
11:03:12 AM rmatte: ohhhhhhhhh
11:03:15 AM rmatte: bleh
11:03:23 AM rmatte: forgot the () after d.os.filesystems
11:03:29 AM rmatte: *slaps forehead*
mrayzenoss has changed the topic to: Zenoss Developers are Here (and Zenoss QA Day: http://bit.ly/7wT0Fw) (11:03:31 AM)
11:03:32 AM mrchippy: rmatte: doh! you beat me to it!
11:03:43 AM rmatte: lol
11:03:54 AM cgibbons: shoot the clock has chimed
11:04:09 AM chickenandbeans: so.... umm yeah... is it a bug?
11:04:14 AM chickenandbeans: I could do with a hand on: message/44457
11:04:45 AM chickenandbeans: been playing around with it since... I haven't seen any side effects
whitemice left the room (quit: "Ex-Chat"). (11:05:33 AM)
11:06:41 AM mrchippy: chickenandbeans: looking now
11:06:49 AM chickenandbeans: cool
11:07:08 AM mrayzenoss: venturaville: it's available in the objects.xml, ${here/ZenPackManager/packs/ZenPacks.community.VMwareEsx/path}/
11:08:46 AM Simon4: question from me... the code at http://pastie.org/788441 works, however it doesn't set the DS type to COUNTER as expected... can anyone point me in the direction of how to make it fly?
11:08:55 AM chickenandbeans: it's a weird one, 'rocket' did a good job on finding that line
mm_ [n=chatzill@gateb.thls.bbc.co.uk] entered the room. (11:10:15 AM)
11:10:32 AM rmatte: well, time to test this transform out
11:11:17 AM cgibbons: i suspect that commit is there for a very good reason
11:11:51 AM chickenandbeans: I would agree
11:12:03 AM chickenandbeans: but it does seem to be causing the error
11:12:21 AM cgibbons: is your 2nd script working with any of the same database objects or is it just the act of running the 2nd dmd that causes the contention?
11:12:57 AM chickenandbeans: it's just the 2nd dmd
11:13:14 AM chickenandbeans: scripts just print out vars, nothing crazy
11:13:33 AM cgibbons: but vars from zeo objects?
11:13:54 AM cgibbons: hold on, i'll try something silly
11:15:07 AM chickenandbeans: ummm it's just: print dmd.Devices.rrdTemplates.....
11:15:33 AM chickenandbeans: All the paths exist, etc
11:15:43 AM cgibbons: and the first one?
11:15:58 AM rmatte: woot, my transform works
11:16:07 AM chickenandbeans: just outputs a text var
11:16:18 AM chickenandbeans: dmd.blah.blah.viewName()
11:19:15 AM Muti: Question for devs: After looking through the bug-fixes I didn't see anythink talking about whether the SQL query from the deviceStatus page that reports Up/Down has been optimized for the case of a large history table
You have disconnected (11:20:04 AM)
You have connected (11:21:18 AM)
The topic for #zenoss is: Zenoss Developers are Here (and Zenoss QA Day: http://bit.ly/7wT0Fw) (11:21:18 AM)
mode (+o mrayzenoss ) by ChanServ (11:21:31 AM)
venturaville left the room (quit: Read error: 110 (Connection timed out)). (11:21:51 AM)
11:22:06 AM mrayzenoss: Muti: was there a ticket for that somewhere?
11:22:28 AM cgibbons: the dev that did that code is out to lunch, but I pinged him and added it to my task list for the day so I'll follow up on your forum post once I chat with him. okay?
11:22:49 AM chickenandbeans: cool
11:23:14 AM chickenandbeans: another problem that may be related was the setting of the rrdtype
11:23:31 AM Muti: mrayzenoss: I'm an enterprise customer and had a case open for it, but I didn't see a Trac ticket for the issue.. I figured I'd just hop in here today and check up on it
11:24:07 AM mrayzenoss: Muti: ahh, send me the case number and I'll poke around
11:24:09 AM Simon4: question from me... the code at http://pastie.org/788441 works, however it doesn't set the DS type to COUNTER as expected... can anyone point me in the direction of how to make it fly?
11:24:22 AM Simon4: (this is related to chickenandbeans  )
11:24:53 AM cgibbons: looking
11:25:17 AM Simon4: thanks
11:26:20 AM mrchippy: chickenandbeans:  i replied in the forums.  give me a shout if you need more info or i wasn't clear
11:26:41 AM chickenandbeans: *reading *
11:27:34 AM baffle: I've had a problem since my first ZenOss installation; I get huge gaps in *most* data polled via perfsnmp.. Is it just me? I've had the problem since 1.x, and now we run 2.5.1. It comes and goes, but it is quite consistent, and the gaps seems to occur on most devices at the same time. MySQL is separate, and a beefy server. Zenoss is on a beefy server. No iowait to speak of (RAID10, 6 or 8 15k disks) and 20G memory.
11:27:41 AM baffle:  Graps ceated from zenping i always 100%. Also if data is polled via local or remote commands. Sometimes I geet gaps in all graphs from the Device template, but not in any other custom templates that also pull from SNMP; I.e. we have MySQL, Apache, Memcache etc SNMP templates that may or might not have gaps at the same time on the same device.
11:27:43 AM mrchippy: Simon4: it doesn't set type to COUNTER on the object or in the RRD file?
11:27:46 AM baffle: Example where all graphs are broken: http://i.imgur.com/mDzJI.png - Example where some graphs are broken: http://imgur.com/XYJdZ.png
11:27:49 AM baffle: rmatte: I pinged out mentally yesterday it seems.
11:28:03 AM Simon4: mrchippy: no.. it doesn't throw errors, but it stays as GAUGE in the template
11:28:10 AM Simon4: has me well stumped
11:28:15 AM rmatte: baffle: lol
11:28:18 AM cgibbons: hrm
vstrick left the room (quit: "Quit"). (11:28:42 AM)
11:28:50 AM mrchippy: Simon4: It stays GAUGE via the UI or when you look in zendmd? or both?
11:28:59 AM rmatte: baffle: I'm doing some dev work right now so can't try to help until I'm done
11:29:26 AM baffle: Actually, I have to modify my earlier statement; I have 20% iowait on the server it seems.
11:29:30 AM Simon4: it says GAUGE in the UI... when I was playing in comandline it would say COUNTER in zendmd, but only for that zendmd session - i.e. exit zendmd and re-enter it, and ti would be back to gauge
11:29:38 AM Simon4: it's like the commit() doesn't take or something
11:29:52 AM chickenandbeans: mrchippy: yeah, thanks for that, but there are no commits.
11:29:54 AM baffle: Or, hm, not now.
11:30:40 AM cgibbons: isn't it rrdtype not rrdType ?
11:31:05 AM cgibbons: yeah I get an attribute exception if I do ds.datapoints()[0].rrdType but not if I do .rrdtype
11:31:15 AM Simon4: *tries quickly*
11:31:15 AM rmatte: cgibbons: yeh, you're right
11:31:25 AM baffle: Hmm, actually, it seems as if some devices are quite happy now. Maybe my problems have changed..
11:31:27 AM chickenandbeans: i've found the same problem occurs thought using the lowercase
11:31:46 AM rmatte: baffle: honestly, it sounds like it has to do with your network link more than with your hardware
11:31:49 AM mrayzenoss: baffle: I assume your machine isn't overloaded with I/O?
11:31:56 AM rmatte: baffle: how many datapoints are you polling per cycle?
11:32:03 AM rmatte: (check the collector performance info)
11:32:36 AM cgibbons: it saved for me when I did it with lowercase
11:32:37 AM baffle: mrayzenoss: I sometimes see bursts of IOwait, typically 20% in top. Now it is 0%.
11:33:18 AM baffle: rmatte: zenperfsnmp avg: 21.46k
11:33:31 AM rmatte: baffle: yeh, that's a pretty decent amount
11:33:31 AM baffle: rmatte: zencommand avg: 353.52 .. zenprocess 2.07k.
11:33:41 AM mrchippy: chickenandbeans: which means the commits (as you pointed out) are in the zenoss code.  i can give evil foo for your script if you would like--
11:33:44 AM rmatte: baffle: what's your average cycles times?
11:33:48 AM rmatte: cycle*
11:34:20 AM chickenandbeans: mrchippy:  what does that mean?
11:34:23 AM baffle: rmatte: zenperfsnmp avg: 25.87, zenping avg: 789.88m, zenstatus 3.51u   zenmodeler 22.54k.
11:34:36 AM baffle: (Uhh, does the notation actually mean something? )
11:34:36 AM Simon4: mrchippy: works a treat - nice spotting  thanks
11:34:41 AM rmatte: chickenandbeans: it's like tofu, but eviler
11:35:24 AM baffle: The graph for Data Points is spotty for zenperfsnmp too.
11:35:50 AM rmatte: baffle: those cycles times are decent, hmmm
11:36:59 AM rmatte: baffle: is all the stuff that you're monitoring on the same LAN?
11:37:05 AM rmatte: or are you monitoring a bunch of remote sites?
11:37:07 AM baffle: rmatte: Noooo, hardly anything.
11:37:18 AM baffle: rmatte: Not remote.
11:37:27 AM baffle: rmatte: As in; They're in the same datacenter.
11:37:35 AM baffle: rmatte: But 100 different VLANs.
11:37:38 AM rmatte: I'm basically wondering if latency is a factor, but apparently it's not
11:37:51 AM baffle: rmatte: And a huge amount of firewalls and routers galore.
11:38:12 AM rmatte: you sure you're not just saturating the interface that you're monitoring through?
11:38:35 AM rmatte: that's all I can think of in terms of causes
11:38:43 AM Simon4: your firewalls aren't munching large UDP SNMP packets on the way through?
11:38:59 AM baffle: Simon4: No, this happens on links without firewalls as well.
11:39:21 AM baffle: Simon4: And ZenOss is not behind a firewall, only local IP-table rules.
11:39:32 AM rmatte: baffle, go to zProperties for all devices and try changing zMaxOIDPerRequest from 40 to 20
11:40:51 AM rmatte: you may also want to increase all timeout values in zProperties
11:41:04 AM rmatte: just as a starting point
11:41:18 AM rmatte: if you notice an improvement after doing that, you'll know it's most likely network related
11:41:40 AM rmatte: the fact that it comes and goes as you describe is why I'm thinking network related
11:41:50 AM baffle: rmatte: It has me stumped as well.
11:42:07 AM rmatte: but make the changes that I just specified and see what happens
11:42:46 AM rmatte: You can also try some of this: docs/DOC-2521
11:42:48 AM baffle: rmatte: Changed, guess I'll take a new look after and hour or so.
11:42:56 AM rmatte: you have a beefy server, but your Zenoss may not be taking full potential of it
swygue [n=rheron@69.64.209.66] entered the room. (11:46:47 AM)
bbibeault left the room. (11:50:40 AM)
11:59:49 AM etank: is there a way to set up zenoss so that when people log in they are anonymous (no rights to see anything) except for the Welcome portal?
12:00:28 PM etank: or in other words where do i set the default portal layout for all users?
12:00:53 PM rmatte: you can't really set a default portal layout for all users as far as I'm aware
12:00:57 PM robo: $25,000 minimum for zenoss enterprise
12:01:00 PM mrayzenoss: not yet
12:01:01 PM robo: that's crazy
12:01:02 PM rmatte: as far as the permissions go, that could be configured from ZMI
12:01:20 PM rmatte: robo: you can talk them down lol
12:01:28 PM etank: rmatte: ZMI?
12:01:35 PM rmatte: etank: Zope Management Interface
12:01:35 PM etank: zope
12:01:39 PM etank: gotcha
12:01:55 PM etank: i think i have the permissions right now
12:02:18 PM etank: people logging in through LDAP auth can not see anything
12:02:38 PM etank: but i would like to set it so that they can see the Welcome in the dashboard
12:02:40 PM rmatte: well, I'll give you a little hint in terms of the portal...
12:03:02 PM rocket: robo: there is the free version if you are willing to do your own coding of zenpacks and support yourself ...
12:03:03 PM rmatte: navigate to settings, users
12:03:05 PM rmatte: click on a user
12:03:16 PM rmatte: put /manage after the URL
12:03:27 PM rmatte: Click on the Properties tab
12:03:45 PM etank: you mean the dashboardstate
12:03:45 PM rmatte: you'll see a dashboardState property with something like...
12:03:47 PM rmatte: {"layout":"2colbs", "columns":[[{"id":"googlemaps1246911720079", "title":"Locations", "datasource":{"baseLoc":"/Locations/Ottawa", "__class__":"YAHOO.zenoss.portlet.GoogleMapsDatasource"}, "bodyHeight":400, "refreshTime":"60", "__class__":"YAHOO.zenoss.portlet.GoogleMapsPortlet"}, {"id":"toplevelorgs1246559840062", "title":"Systems", "datasource":{"url":"/zport/getRootOrganizerInfo", "queryArguments":{"dataRoot":"Systems", "_dc":"1246912163112"}, "postContent"
12:03:58 PM etank: right
12:04:05 PM rmatte: so you need to somehow figure out where Zenoss grabs that from when creating a new user and modify it
12:04:42 PM rmatte: It would be nice if they'd just add an option in the UI to do this sort of thing
12:04:46 PM rmatte: but I'm sure it'll come eventually
12:04:56 PM etank: but can not set defaults at this point
12:05:07 PM etank: good enough i guess
12:06:56 PM rmatte: *wonders why it's taking forever for Zenoss to realize that an nfs share has been remounted and monitor it again*
12:07:06 PM rmatte: wonder if the snmp index changed
12:07:32 PM rmatte: *remodels*
12:07:58 PM rmatte: nope, it didn't
12:07:59 PM rmatte: hmmm
12:08:49 PM Simon4: rmatte: zenperfsnmp has cached the config that it's not there, and has a long config cycle interval set?
12:09:08 PM rmatte: Simon4: that's possible, just thought of that, pushes changes to the device
12:09:11 PM rmatte: pushed*
12:09:14 PM rocket: robo: I dont know of any monitoring system that is cheap.  There is no single api available to gather anything .. bugs in snmp .. all of that takes time and resources to support ..
12:09:26 PM Simon4: *runs into that far too often *
12:10:09 PM robo: rocket, yeah. We're spending about that much now for foglight
12:10:25 PM rocket: robo: BMC is $1000 a node .. IBM's pricing isnt much better .. and neither of them really have a free version that you can use
12:10:31 PM robo: i could get away with getting management to fork over $5k or so.. but $25k -- no way
12:10:45 PM rmatte: Solarwind's pricing is off the wall too, it's like $15,000 per collector
12:10:51 PM robo: wow
12:11:17 PM rocket: robo: at least you could start with the free version and the zenpacks you build would be compatible as you move up if you need to
12:11:35 PM rmatte: yeh, we're using the core version quite successfully
12:11:36 PM mrayzenoss: there's discounted pricing for .edus and Sales is looking for ways to lower their minimums
12:11:40 PM rmatte: we just have a ton of core boxes
12:12:05 PM etank: rmatte: we just switched from foglight to zenoss
12:12:20 PM rmatte: I've never seen foglight
12:12:27 PM rocket: robo: I am sure if you can think of a more reasonable way to do licensing with a decent business for zenoss they might consider it
12:12:32 PM rmatte: the only other ones I've seen are Solarwinds and OpenView
12:12:40 PM rmatte: an ancient version of OpenView at that
12:12:45 PM rocket: robo: they are quite decent guys trying to make a living like all of us ..
12:12:52 PM rmatte: yup
12:12:59 PM rmatte: development costs money
12:13:01 PM QubeZ: rmatte did you get that wiki up?
12:13:02 PM robo: rocket, yeah -- I totally get that. I put in a call to sales to see if they can work with me
12:13:09 PM etank: the sales guy at Zenoss that i worked with was great
12:13:09 PM rmatte: QubeZ: still testing the code
12:13:11 PM robo: why i had to leave a voice mail with someone from sales is beyond me
12:13:17 PM QubeZ: rmatte sweet
12:13:28 PM rmatte: QubeZ: code is done, but there appear to be a couple of kinks, just need to iron them out
12:13:29 PM mrayzenoss: robo: they're in the Sales kick-off meetings all week
12:13:35 PM robo: ah
12:13:39 PM mrayzenoss: 3 days of all day meetings
12:14:24 PM mrayzenoss: I can poke them with a virtual stick if you don't hear back soon enough
12:14:40 PM rmatte: man, for what we're spending no solarwinds collectors we could have unlimited Zenoss Enterprise
12:14:44 PM rmatte: on*
12:14:55 PM cgibbons: and don't forget there's always the balance that small customers are more expensive to service than big ones, so there's another reasonf or minimums
12:14:58 PM rmatte: the only reason that our management wants to buy solarwinds over Zenoss is because of the reporting
12:15:08 PM rmatte: Zenoss' reporting really really needs to improve
whitemice [n=whitemic@mail.mormail.com] entered the room. (12:15:17 PM)
12:15:36 PM mrayzenoss: at least our dev staff is finally ramping up
12:15:49 PM forsberg: http://www.youtube.com/watch?v=CjOQ9r35uiU
12:15:50 PM mrayzenoss: up to 8 right now and still hiring
12:15:54 PM forsberg: ups sorry wrong chan
QubeZ left the room (quit: ). (12:16:03 PM)
12:16:04 PM rmatte: yeh, I'm glad to see that, maybe in about a year Zenoss will be at the point where I can push to have use actually buy the MSP Enterprise package
12:16:10 PM rocket: mrayzenoss: I heard ..
12:16:14 PM rmatte: s/use/us
12:17:15 PM mrayzenoss: speaking of making Zenoss better… go grab a 2.5.2 beta and kick the tires… we want this thing to be solid and we need more testing http://alpha.zenoss.com/files/2.5.2-beta/
12:17:38 PM rmatte: I've already installed the beta
12:17:43 PM Simon4: cgibbons: question... if I run zenperfsnmp stop, and then zenperfsnmp start on our core install... it fails to load config for some devices... if I then reindex the db (via reindex() in zendmd), zenperfsnmp starts cleanly and things tick along as before
12:17:55 PM Simon4: is this something other people run into?
12:17:55 PM rmatte: ...and I really like the improvements that I've seen so far
12:18:20 PM rmatte: Unfortunately I can't even consider upgrading until this is fixed: http://dev.zenoss.org/trac/ticket/5978
12:18:31 PM rmatte: because it ruins half of my performance templates
12:18:33 PM cgibbons: hmmm i've never seen anything like that just from starting/starting a daemon, unless there's more stuff going on (like device issues, etc.). but zenperfsnmp batch loads config, iirc.
12:18:46 PM Simon4: yeah, it does, at the start
12:19:00 PM rmatte: I also won't be able to release any of the new ZenPacks that I've been working on until that is fixed either
12:19:07 PM mrayzenoss: rmatte: why no 2.5.2 proposed?
12:19:20 PM Simon4: *will document better and post on the forums - was just on the off-chance that it had been seen before as it's fairly irritating*
12:19:25 PM rmatte: no idea
12:19:36 PM rmatte: bbibeault backlogged it and that was it
12:19:56 PM mrayzenoss: we must have been in the defect review and reviewed it
12:20:13 PM rmatte: I think it's a pretty major one
12:20:22 PM rmatte: I had to actually go in and comment out that line on all of my servers
12:20:27 PM rmatte: and they've been running fine without it
12:22:09 PM cgibbons: chickenandbeans, you still around?
12:23:03 PM Simon4: *heads away, thanks all*
Simon4 left the room. (12:23:05 PM)
12:23:52 PM chickenandbeans: still here
12:24:26 PM chickenandbeans: *is reading up*
12:27:32 PM chickenandbeans: mrchippy was extremely  helpful... so much thanks
12:27:45 PM cgibbons: think we've got a fix for you on that conflict error thinger
12:28:28 PM chickenandbeans: yeah, tell me tell me
12:28:33 PM chickenandbeans: *jumps up and down*
12:31:54 PM cgibbons: ok edit ZenScriptBase.py and change line 55 to
12:32:14 PM cgibbons: if getattr(self.dmd, 'propertyTransfomers', None) is None:
12:32:21 PM cgibbons: save & try your scripts again
12:33:40 PM chickenandbeans: ok, cool... i'll comment out the work around and give it a go
12:33:42 PM chickenandbeans: two secs
mode (+o cgibbons_ ) by ChanServ (12:33:49 PM)
cgibbons_ [n=cgibbons@75-148-215-110-Houston.hfc.comcastbusiness.net] entered the room. (12:33:49 PM)
cgibbons_ left the room (quit: Remote closed the connection). (12:34:25 PM)
cgibbons left the room (quit: Read error: 104 (Connection reset by peer)). (12:34:26 PM)
cgibbons [n=cgibbons@75-148-215-110-Houston.hfc.comcastbusiness.net] entered the room. (12:34:51 PM)
mode (+o cgibbons ) by ChanServ (12:34:52 PM)
chris______ left the room (quit: ). (12:35:03 PM)
12:35:05 PM cgibbons: grr UPS took a header
12:35:21 PM chickenandbeans: mm no dice... the fix didn't work
12:35:28 PM cgibbons: hrm
12:35:48 PM cgibbons: still a conflict on DataRoot ?
12:36:36 PM chickenandbeans: yeah, same error as in the thread
12:37:00 PM chickenandbeans: ah two secs
12:37:05 PM chickenandbeans: i'm an idiot
12:37:19 PM rmatte: lol
12:37:33 PM chickenandbeans: shush you
12:37:36 PM chickenandbeans:
12:37:59 PM cgibbons: typo?
12:38:48 PM chickenandbeans: indeed
12:38:51 PM cgibbons: good
12:39:06 PM chickenandbeans: ah ok that works!
12:39:12 PM cgibbons: shew!
12:39:14 PM chickenandbeans: tell me what we fixed
12:39:19 PM chickenandbeans: by 'we' i mean you
12:39:21 PM chickenandbeans:
12:39:32 PM cgibbons: not me, I didn't notice the bug, but the author did immediately
12:39:50 PM cgibbons: that code should have only ever set propertyTransformers once and only once, but it was doing it every time
12:40:03 PM cgibbons: lemme get you a defect link in a moment
12:40:10 PM cgibbons: i'll see if i can talk them into putting it into 2.5.2 too
12:40:40 PM rmatte: cgibbons: maybe you can help me out with this...
12:41:02 PM rmatte: if I unmount an nfs share, Zenoss generates a debug message and stops monitoring the share...
12:41:07 PM chickenandbeans: what effect would that have?
12:41:14 PM rmatte: when I remount the share I need to push changes to get Zenoss to start monitoring it again
12:41:34 PM rmatte: is there some property that gets set on that object which tells Zenoss to stop checking it?
12:42:06 PM rmatte: Basically, I'm working on a way to monitor NFS share status, I have a large portion of it done, this is the last thing that I need to figure out
12:42:19 PM cgibbons: how is it being monitored?
12:42:34 PM rocket: cgibbons: woohoo way to go ..
12:42:36 PM cgibbons: chickenandbeans: benign except in your case only
12:42:58 PM rmatte: cgibbons: ok, here's the transform: http://pastebin.com/m65b12350
12:43:08 PM rmatte: I apply that to the /Perf/Snmp class
12:43:27 PM rmatte: if it sees a debug message come in for filesystem OID it checks to make sure the drive is of type "networkDisk"
12:43:43 PM rmatte: it then modifies the debug event to become an alert event for NFS being unavailable
12:44:09 PM rmatte: but if I remount the nfs share right afterwards Zenoss completely ignores monitoring it for about an hour unless I manually push changes
12:44:18 PM chickenandbeans: ah cool
12:44:31 PM chickenandbeans: is there a ticket/defect link somewhere
12:44:31 PM rmatte: I'm wondering if there's some bit that gets set on that object to tell Zenoss to ignore monitoring of it until next config cycle
12:44:55 PM rmatte: If there is, I could have the transform unset the bit to have it continuously alert each cycle until the share is available again
12:45:58 PM rmatte: NFS status monitoring is often requested so I decided to come up with a solution
12:46:32 PM cgibbons: what about the monitored attribute of the component?
12:46:41 PM rmatte: that doesn't seem to change
12:48:09 PM rmatte: I'm looking at the properties for the root and the nfs share on the same server
12:48:15 PM rmatte: and there's nothing obviously different
12:50:19 PM rmatte: do you know of a way via dmd/python that I could force Zenoss to push changes to the collector for that particular object?
12:50:52 PM rmatte: oh, I can do: d.collectDevice()?
12:50:58 PM dec3pti0n: from 1 to 10 , how hard is it to setup collectors using the core free version ?
12:51:10 PM rmatte: oh no, that's to remodel
12:51:11 PM rmatte: not push
12:51:12 PM rmatte: hmmmm
12:51:13 PM rocket: dec3pti0n: from 1 to 10 ..
12:51:18 PM dec3pti0n:
12:51:24 PM cgibbons: if zenhub sees that the device/components changes, it's supposed to do an asynchronous update to the collector... but lesee
12:51:33 PM cgibbons: there's that UI push config command so it must do something
12:51:40 PM rocket: dec3pti0n: different people find it hard .. others find it easy .. its hard to say ..
12:51:45 PM cgibbons: hang on lemme finish with this defect real quick
12:52:01 PM dec3pti0n: rocket: is it explained how to do somewhere ?
12:52:10 PM rmatte: cgibbons: thanks, no rush
12:53:13 PM rocket: dec3pti0n: found this via google almost right away docs/DOC-2496
12:53:31 PM rmatte: aha d.pushConfig() looks like
12:53:34 PM rmatte: going to try it
12:54:01 PM dec3pti0n: rocket: cool thanks
12:55:01 PM cgibbons: chickenandbeans: http://dev.zenoss.org/trac/ticket/6081
12:55:14 PM cgibbons: we've got a defect review in an hour so it'll come up there
12:55:26 PM cgibbons: you can zenpatch 16698 until it gets shipped
12:57:06 PM chickenandbeans: editing the thread
12:58:44 PM rmatte: if this d.pushConfig() works this'll be awesome
12:58:57 PM cgibbons: either that or it'll eat your database
12:59:12 PM rmatte: what will?
12:59:23 PM rmatte: *looks around worriedly*
1:00:52 PM rmatte: according to a post by chet there's nothing wrong with d.pushConfig()
1:00:59 PM cgibbons: i was joking
1:01:04 PM rmatte: don't do that
1:01:04 PM cgibbons: poorly
1:01:05 PM rmatte:
1:01:25 PM rmatte: when a Zenoss developer says something like that I take it seriously
1:01:25 PM rocket: lol
1:02:29 PM cgibbons: i have this strange way of causing things to break that i interact with, so it might be safe, but it might not be just because
1:02:30 PM cgibbons: ask rocket
1:02:39 PM rmatte: lol
1:02:58 PM rocket: cgibbons: I have a strange ability to notice breaking things ..
1:03:00 PM rmatte: I did notice that there are often netsplits shortly after you join the channel
1:03:20 PM rocket: cgibbons: skype wont work for me at all today ..
1:03:44 PM cgibbons: so far mine has been great, so don't jinx me!
1:03:52 PM rmatte: lol
1:03:56 PM rocket: thats cuz I am offline .. ;p
themurph left the room (quit: Read error: 110 (Connection timed out)). (1:05:00 PM)
1:05:32 PM rmatte: am I going to have to do a txnCommit() after this d.pushConfig()?
1:05:39 PM rmatte: or should it just work?
1:05:48 PM chickenandbeans: updating forum thread
mrchippy left the room. (1:06:09 PM)
Muti left the room. (1:06:11 PM)
1:07:19 PM chickenandbeans: right im outta here
1:07:50 PM rmatte: later
1:07:54 PM chickenandbeans: thanks guys for all your help
chickenandbeans left the room (quit: "ChatZilla 0.9.86 [Firefox 3.5.3/20091020102323]"). (1:08:55 PM)
mrayzenoss has changed the topic to: Today's QA Test Day in #zenoss-testing: Zenoss 2.5.2: http://bit.ly/7wT0Fw (1:09:44 PM)