From ingvar at hexapodia.net Thu Jun 5 06:33:58 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 05 Jun 2008 07:33:58 +0100 Subject: [noctool-devel] My current work Message-ID: I thought I'd knock the network bits into order and get some testing done. There's been some check-in thanks to that (mostly in config.lisp and packages.lisp, so there's a way of configuring remote nodes). Once that's done (unless someone preempts me), I'll write a wrapper to run NAGIOS call-outs. Can't say I remember off-hand how they interface, but I wrote some a couple of years ago, so a bit of searching should take care of that. If anyone wants to preempt me and do that I won't complain. Oh, with "done" I mean "can successfully make a network connection and authenticate", not "all of the network protocol is implemented". :) //Ingvar From download at hpc.unm.edu Thu Jun 5 16:59:44 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 5 Jun 2008 10:59:44 -0600 (MDT) Subject: [noctool-devel] compact configurations for identical machines In-Reply-To: References: Message-ID: > Does this look at least vaguely sane? > (cluster ("rtr-~3,'0d" 1 10) > (machine name linux-host > (user "testuser"))) I've been thinking more about this. It seems to me that we need something a little more general that what you're proposing. One example is that I probably want to have an IP range as well. I'm thinking syntax like this might work: (my-cluster 12 ;; system count ((name (trucha-name-func)) ;; variable elements (ip (trucha-ip-func))) (machine ;; machine template name linux-host (user "download") (ip ip) (disks (disk "/dev/hda1" 80 95)))) where trucha-name-func and trucha-ip-func basically are generators, each time they are called, they produce a new result. With this particular cluster, we have an interesting problem. The IP space is 129.24.244.21 - 129.24.244.30 and 129.24.244.43 - 129.24.244.44. There are a total of 12 IPs, but they are not in a contiguous block. (this is a legacy issue :P ) I realize that the above syntax still leaves something to be desired. It is, IMO, too general for what most users need. I think we could probably make a couple of convienance macros that would expand into the above. I'm not sure yet if I like the idea of using "generators" here, or if each function should be given an argument of which machine it is. Jim From ingvar at hexapodia.net Thu Jun 5 17:53:42 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 05 Jun 2008 18:53:42 +0100 Subject: [noctool-devel] compact configurations for identical machines In-Reply-To: References: Message-ID: Jim writes: > > Does this look at least vaguely sane? > > (cluster ("rtr-~3,'0d" 1 10) > > (machine name linux-host > > (user "testuser"))) > > I've been thinking more about this. It seems to me that we need something > a little more general that what you're proposing. One example is that I > probably want to have an IP range as well. > > I'm thinking syntax like this might work: > > (my-cluster > 12 ;; system count > ((name (trucha-name-func)) ;; variable elements > (ip (trucha-ip-func))) > (machine ;; machine template > name > linux-host > (user "download") > (ip ip) > (disks > (disk "/dev/hda1" 80 95)))) > > where trucha-name-func and trucha-ip-func basically are generators, each > time they are called, they produce a new result. > > With this particular cluster, we have an interesting problem. The IP > space is 129.24.244.21 - 129.24.244.30 and 129.24.244.43 - 129.24.244.44. > There are a total of 12 IPs, but they are not in a contiguous block. > (this is a legacy issue :P ) > > I realize that the above syntax still leaves something to be desired. It > is, IMO, too general for what most users need. I think we could probably > make a couple of convienance macros that would expand into the above. > > I'm not sure yet if I like the idea of using "generators" here, or if each > function should be given an argument of which machine it is. Something that MIGHT work is having a "template mechanism" of some sort. The cluster config should do what you need, as long as there's DNS (at least I think so, the general thought was "use hostname, unless IP is provided"). Another option would be to declare a cluster-host class, with suitable defaults for disks and the like, but that MIGHT get hairier. >From the feedback I've seen, most other systems deal wit htis by having the admin generate teh config in full, one way or another (either by clever editor tricks or by writing some code to generate config stanzas). //Ingvar From annis at biostat.wisc.edu Thu Jun 5 18:36:17 2008 From: annis at biostat.wisc.edu (William Annis) Date: Thu, 5 Jun 2008 13:36:17 -0500 (CDT) Subject: [noctool-devel] compact configurations for identical machines In-Reply-To: (message from Jim Prewett on Thu, 5 Jun 2008 10:59:44 -0600 (MDT)) References: Message-ID: <20080605183617.ECAC74087A6@cydonia.biostat.wisc.edu> >From: Jim Prewett > >I realize that the above syntax still leaves something to be desired. It >is, IMO, too general for what most users need. I think we could probably >make a couple of convienance macros that would expand into the above. > >I'm not sure yet if I like the idea of using "generators" here, or if each >function should be given an argument of which machine it is. IP ranges are easy enough to generate and loop over: (require :split-sequence) (defun addr4->int (ipaddr) (destructuring-bind (a1 a2 a3 a4) (mapcar #'parse-integer (split-sequence:split-sequence #\. ipaddr)) (dpb a1 (byte 8 24) (dpb a2 (byte 8 16) (dpb a3 (byte 8 8) a4))))) (defun int->addr4 (intaddr) (format nil "~D.~D.~D.~D" (ldb (byte 8 24) intaddr) (ldb (byte 8 16) intaddr) (ldb (byte 8 8) intaddr) (ldb (byte 8 0) intaddr))) (defmacro do-ip-range ((var start-ip end-ip &optional return) &body body) (let ((start (gensym "start")) (end (gensym "end")) (a (gensym))) `(let ((,start (addr4->int ,start-ip)) (,end (addr4->int ,end-ip))) (loop for ,a from ,start to ,end do (let ((,var (int->addr4 ,a))) , at body) finally (return ,return))))) (do-ip-range (addr "128.104.206.15" "128.104.206.33" 'woohoo) (print addr)) Seems like this might be useful in several places (network discovery, say). -- wm, trying to decide if DO-CIDR-RANGE is in order... From download at hpc.unm.edu Thu Jun 5 20:21:16 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 5 Jun 2008 14:21:16 -0600 (MDT) Subject: [noctool-devel] what is a cpu-monitor? Message-ID: Hi Ingvar, What is the CPU monitor supposed to do? I can't find a PROCESS method for it. :P :) I'd be happy to try to write such a method if only I could grok what you're thinking here. :) Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 From ingvar at hexapodia.net Thu Jun 5 21:31:18 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 05 Jun 2008 22:31:18 +0100 Subject: [noctool-devel] what is a cpu-monitor? In-Reply-To: References: Message-ID: > Hi Ingvar, > > What is the CPU monitor supposed to do? I can't find a PROCESS method for > it. :P :) I'd be happy to try to write such a method if only I could grok > what you're thinking here. :) I think it was supposed to log in and snag the system load. I also thought it was all written. It isn't, though. Oh, hang on, it's one of those that'll need a multi-stage PROCESS, one that just gets the cpu-monitor object, then another one that also has teh equipment as a class (since getting CPU utilisation is OS specific, IOS, linux and windows do it all differently). Might've been why I didn't write it. I'll probably be busy with the network code for a bit more and then have a play with a NAGIOS-test framework, so feel free to go ahead. //Ingvar From ingvar at hexapodia.net Thu Jun 5 21:39:23 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 05 Jun 2008 22:39:23 +0100 Subject: [noctool-devel] what is a cpu-monitor? In-Reply-To: References: Message-ID: > > Hi Ingvar, > > > > What is the CPU monitor supposed to do? I can't find a PROCESS method for > > it. :P :) I'd be happy to try to write such a method if only I could grok > > what you're thinking here. :) > > I think it was supposed to log in and snag the system load. I also thought it > was all written. It isn't, though. Er, no, there's a load-monitor class. I am confused now. Maybe it was something intended for (say) routers, switches and windows machines? Because, you know, load and cpu utilisation aren't identical. Not that I could find a PROCESS method for load-monitors either. //Ingvar //Ingvar From download at hpc.unm.edu Thu Jun 12 14:01:23 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 12 Jun 2008 08:01:23 -0600 (MDT) Subject: [noctool-devel] anonymous CVS works! Message-ID: Hey All, I found that anonymous CVS access (using the directions provided on the main noctool webpage) works! Wha-Hoo! Ingvar, do you want to modify that webpage to remove the statement that it is not yet working? Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 From download at hpc.unm.edu Thu Jun 12 14:12:31 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 12 Jun 2008 08:12:31 -0600 (MDT) Subject: [noctool-devel] image.asd fixes Message-ID: Hi Ingvar, While using ASDF-INSTALL to get a new noctool setup going, I found that the image package used strings instead of symbols for the packages that it depends on. This confuses the heck out of asdf-install (but seems to work OK for ASDF - HMMM... sounds like it might be a bug in ASDF-INSTALL, but... well, I don't want to spend the time reading the spec to determine that ;P :) I've attached a modified version of image.asd from image-0.6 - the changes are by no means profound :) Using the attached image.asd made my asdf-install go very smoothly. :) hth, Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 -------------- next part -------------- (in-package #:cl-user) (asdf:defsystem "image" :version "0.6" :author "Ingvar Mattsson" :license "MIT" :depends-on (:skippy :clx :zpng) :components ((:file "package") (:file "helpers" :depends-on ("package")) (:file "image" :depends-on ("package")) (:file "image-text" :depends-on ("package" "image")) (:file "x11" :depends-on ("package" "image")) (:file "imports" :depends-on ("package" "image" "helpers")) (:file "exports" :depends-on ("package" "image" "x11")))) From ingvar at hexapodia.net Thu Jun 12 14:37:01 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 12 Jun 2008 15:37:01 +0100 Subject: [noctool-devel] anonymous CVS works! In-Reply-To: References: Message-ID: > Hey All, > > I found that anonymous CVS access (using the directions provided on the > main noctool webpage) works! > > Wha-Hoo! > > Ingvar, do you want to modify that webpage to remove the statement that it > is not yet working? Can do, probably when I get home. Worst case, the web pages are in CVS. //Ingvar From ingvar at hexapodia.net Thu Jun 12 14:39:30 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 12 Jun 2008 15:39:30 +0100 Subject: [noctool-devel] Re: image.asd fixes In-Reply-To: References: Message-ID: > Hi Ingvar, > > While using ASDF-INSTALL to get a new noctool setup going, I found that > the image package used strings instead of symbols for the packages that it > depends on. This confuses the heck out of asdf-install (but seems to work > OK for ASDF - HMMM... sounds like it might be a bug in ASDF-INSTALL, > but... well, I don't want to spend the time reading the spec to determine > that ;P :) > > I've attached a modified version of image.asd from image-0.6 - the changes > are by no means profound :) > > Using the attached image.asd made my asdf-install go very smoothly. :) If you look at noctool.asd, it too is using strings instead of symbols. I suspect it's more of an issue with ASDF-INSTALL than with the ASDF system definition, myself. //Ingvar From ingvar at hexapodia.net Thu Jun 12 14:44:28 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 12 Jun 2008 15:44:28 +0100 Subject: [noctool-devel] anonymous CVS works! In-Reply-To: References: Message-ID: I wrote: > Can do, probably when I get home. Worst case, the web pages are in CVS. Not only are they in CVS, the change was minor enough that it's been done, checked in and pushed to the project site. //Ingvar From download at hpc.unm.edu Thu Jun 12 15:59:31 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 12 Jun 2008 09:59:31 -0600 (MDT) Subject: [noctool-devel] anonymous CVS works! In-Reply-To: References: Message-ID: awesome! thanks Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 On Thu, 12 Jun 2008, Ingvar wrote: > I wrote: > > Can do, probably when I get home. Worst case, the web pages are in CVS. > > Not only are they in CVS, the change was minor enough that it's been done, > checked in and pushed to the project site. > > //Ingvar > > _______________________________________________ > noctool-devel mailing list > noctool-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/noctool-devel > From download at hpc.unm.edu Thu Jun 12 16:02:43 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 12 Jun 2008 10:02:43 -0600 (MDT) Subject: [noctool-devel] Re: image.asd fixes In-Reply-To: References: Message-ID: I'm going to go ahead and change the strings in noctool.asd into symbols. When we do get something ready for the general public, I want the ASDF-INSTALL process to be as painless as possible :) Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 On Thu, 12 Jun 2008, Ingvar wrote: > > Hi Ingvar, > > > > While using ASDF-INSTALL to get a new noctool setup going, I found that > > the image package used strings instead of symbols for the packages that it > > depends on. This confuses the heck out of asdf-install (but seems to work > > OK for ASDF - HMMM... sounds like it might be a bug in ASDF-INSTALL, > > but... well, I don't want to spend the time reading the spec to determine > > that ;P :) > > > > I've attached a modified version of image.asd from image-0.6 - the changes > > are by no means profound :) > > > > Using the attached image.asd made my asdf-install go very smoothly. :) > > If you look at noctool.asd, it too is using strings instead of symbols. I > suspect it's more of an issue with ASDF-INSTALL than with the ASDF system > definition, myself. > > //Ingvar > > _______________________________________________ > noctool-devel mailing list > noctool-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/noctool-devel > From ingvar at hexapodia.net Thu Jun 12 16:12:18 2008 From: ingvar at hexapodia.net (Ingvar) Date: Thu, 12 Jun 2008 17:12:18 +0100 Subject: [noctool-devel] Re: image.asd fixes In-Reply-To: References: Message-ID: Jim writes: > I'm going to go ahead and change the strings in noctool.asd into symbols. > When we do get something ready for the general public, I want the > ASDF-INSTALL process to be as painless as possible :) Hm, my own "mucks with ASDF systems" code doesn't seem to be having any problems. :( But, looking at (for example) Skippy, it seems as it is indeed using symbols rather than strings. I've always used strings, myself, since I believe taht's how Dan Barlow did it, back in the days. Go ahead and clean it up! //Ingvar From ingvar at hexapodia.net Sat Jun 14 13:12:04 2008 From: ingvar at hexapodia.net (Ingvar) Date: Sat, 14 Jun 2008 14:12:04 +0100 Subject: [noctool-devel] We (almost) have network! Message-ID: I've successfully managed to connect one noctool image to another noctool image and identify one way. Next step, make sure that everything seems to work and make it happen both ways. Once that is in place, it's time to start testing proxy objects and the like. After that, it's time to modify the scheduler slightly (well, the PROCESS method(s)), to send updates across the wire on an as-needed basis. //Ingvar From ingvar at hexapodia.net Sun Jun 15 11:00:44 2008 From: ingvar at hexapodia.net (Ingvar) Date: Sun, 15 Jun 2008 12:00:44 +0100 Subject: [noctool-devel] More network protocol things Message-ID: Some thinking later and I've split the network code into three files. If anyone wants to play around with it, I have a (temporary) extra ASDF definition to make it possibel to load noctool and noctool-with-network separately (makes it slightly easier to find network-specific compilation issues), I'll paste it in towards the end. Now, what I've done, to make the protocol dispatch easier (hahaha) to follow, is a dispatch table, keyed off the protocol message header and a macro taht defines handlers. The defhandler macro looks like this: (defhandler ( ...) ... function body goes here) This does two things, it defines a function , with CONN as the first argument (in most cases, you need to know what connection to send a reply back to) and the message type thingie declared as ignorable (since, most of the time, it's only used for dispatching, anyway). Not very tested, as of yet, I'll probably need to frob around with how to retrieve and set proxy objects, but... And here's the system definition (once the network code is a bit more stable and "with it", I'll merge this into the main system definition, I won't check this temp definition into CVS): (in-package :asdf) (defsystem "noctool-network" :depends-on ("noctool") :components ((:file "network-globals") (:file "network-utils" :depends-on ("network-globals")) (:file "network" :depends-on ("network-utils" "network-globals")))) //Ingvar From download at hpc.unm.edu Mon Jun 16 13:34:17 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Mon, 16 Jun 2008 07:34:17 -0600 (MDT) Subject: [noctool-devel] what is a cpu-monitor? In-Reply-To: References: Message-ID: Hi Ingvar, I was wondering if the CPU monitor might be intended to monitor the number of CPUs on a system. I'm looking at a Ganglia monitoring webpage right now and one of the things they report is the total number of CPUs a given host or group of hosts has. Could this be what it is for? If so, anyone know how to get this information from a host that doesn't have something like /proc/cpuinfo ? Specifically, I'm thinking my Mac laptop (which I do some bogus monitoring of for testing/hacking purposes). Whaddya think?, Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 On Thu, 5 Jun 2008, Ingvar wrote: > > > Hi Ingvar, > > > > > > What is the CPU monitor supposed to do? I can't find a PROCESS method for > > > it. :P :) I'd be happy to try to write such a method if only I could grok > > > what you're thinking here. :) > > > > I think it was supposed to log in and snag the system load. I also thought it > > was all written. It isn't, though. > > Er, no, there's a load-monitor class. I am confused now. Maybe it was > something intended for (say) routers, switches and windows machines? Because, > you know, load and cpu utilisation aren't identical. > > Not that I could find a PROCESS method for load-monitors either. > > //Ingvar > > //Ingvar > > _______________________________________________ > noctool-devel mailing list > noctool-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/noctool-devel > From ingvar at hexapodia.net Mon Jun 16 14:05:05 2008 From: ingvar at hexapodia.net (Ingvar) Date: Mon, 16 Jun 2008 15:05:05 +0100 Subject: [noctool-devel] what is a cpu-monitor? In-Reply-To: References: Message-ID: > Hi Ingvar, > > I was wondering if the CPU monitor might be intended to monitor the number > of CPUs on a system. I'm looking at a Ganglia monitoring webpage right > now and one of the things they report is the total number of CPUs a given > host or group of hosts has. > > Could this be what it is for? > > If so, anyone know how to get this information from a host that doesn't > have something like /proc/cpuinfo ? Specifically, I'm thinking my Mac > laptop (which I do some bogus monitoring of for testing/hacking purposes). I think it might've been one of those things I intened for routers and switches, where you don't get a load, per se, but a "CPU utilisation percentage". Not a problem if it means different things for different equipment, though. Or, yes, there is, but... Whoever first writes a PROCESS method for it gets to decide, I think. //Ingvar From ingvar at hexapodia.net Tue Jun 17 12:10:24 2008 From: ingvar at hexapodia.net (Ingvar) Date: Tue, 17 Jun 2008 13:10:24 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source/docs In-Reply-To: References: <20080617060036.5EA6C117D@common-lisp.net> Message-ID: Jim writes: [ I am CCing this to the devel list, as it probably shoudl be archived there ] > Ingvar writes: > > Some sort of GUID? It gets REAL messy, REAL fast. I've just changed (but > > not yet checked in) an improved GET-PROXY that uses both connection and > > ID to find a proxy object (one needed on each end, though the client end > > instantiates equipment and montitor objects as needed and link to them > > in the proxy object, whereas the server end uses the proxy objects to > > know where to send updates). > > I've done GUID's before, but its been 10 years and I don't really recall > the issues :P :) I'm happy to say "Hell NO!" ;) For one, I want IDs to persist across reboots, if at all possible (this is, obviously, much easier with in-process interafces, though saving off a list with remote-node-name/ID-there as key is doable). This should, ideally, also survive "pack everything up and ship to new server", but as the classic GUID implementation use (among other things) the MAC address (well, "a" MAC address) on the generating computer, you suddenly lose the ability to check IDs that have been generated before, once the original box is sufficiently rebuilt (NOTE: I think they usually mix in time-of-day, in these things). > > > 2. I was thinking of factoring out the ID slot into an id-object class and > > > then creating an after method for initialize-instance to throw the > > > instance into a hash table based on its ID > > > > Better to just change the basic storage for *equipment* and change > > NOCTOOL-CONFIG:LOAD to do The Right Thing > > Hmmm... I don't know that I agree. I think its possible, for example, > that a monitor might be created by some process besides > noctool-config:load - making CLOS do The Right Thing seems better to me. Well, there are examples of that already (disk-monitor or whatever it's called generates monitors for individual volumes) and will only become more prevalent (traffic-monitoring on, say, a switch will need to do the same). It's probably sane doing that in CLOS. > I'm a big fan of "mixin" classes. > > > > 3. Is there any particular reason you chose to use uninterned symbols for > > > the IDs (GENSYM instead of GENTEMP)? > > > > Yeah, kinda. It's guaranteed to exist on all lisps and we're essentially > > doing string-compares anyway (ooops, need to fix that in the network > > code). As long as we're OK with having only locally-unique IDs, we could > > fall back on a plain counter. > > Well, we're using Common Lisp and GENTEMP is part of the standard > according to CLHS. Also, I think we should be realistic about targeting > *ONLY* SBCL for the first (real) release. If it doesn't work with SBCL it > doesn't work with Noctool. :P > > Why I'd wanted an ID to be an interned symbol is that it makes it so much > easier to convert from a string given by the user. The other way to do it > is to hash on the symbol-name of the gensym'd symbol - that actually is a > tad more efficient since I don't always have to convert between strings > and symbols. I am thinking that we should move to using (one or two) plain counters, as we'd have to make sure there are no ID collisions after un-persisting stored data. > So, In short, I no longer care if we use gensym or gentemp. :P :) > > I think my arguments of if its in the spec its fair game and if its > supported by SBCL its fair game should still be considered. (If its in > the spec and not suppored by SBCL, I'll take the abuse and submit a bug > report ;) Yeah, SBCL first, the world later. :) > > > I'm thinking about the web interface stuff and, man would I like to be > > > able to look up a monitor by its name for the purposes of the GUI... > > > > Name and ID are different, though. The name is supposed to be human-friendly > > and the ID is supposed to be code-friendly (with the obvious problem that > > human-friendly doesn't necessarily imply unique). > > OOOPS! I was speaking /far/ too losely :) NEED MORE COFFEE! Can't have too much. Speaking of that, I realy should get some lunch. > I want to look up a monitor by its ID, not its name. (I probably also > want to look it up by its name at some point, but... ) > > > It gets even bizarrer with monitors, since they don't (strictly > > speaking) have names, they do have associated equipment objects, though > > (and they have names). > > > > I suspect the best (as in "easiest", not necessarily as in "technically > > most superior) is to have something akin to: > > http://noctolweb/equipment-by-name/jprewett-server-17/ping-monitor > > This looks up jprewett-server-17 (a piece of equipment), by name and > > spots that there are more stuff after. It then checks the ID and > > builds a new URL and redirects to > > http://noctoolweb/equipment/EQ-42/MON-872 > > > > That way, you tend towards persisting ugly (but fast-to-render) URLs, but > > still have an easy way of actually finding them. > > Thats pretty much what I was thinking. Your suggested URI's are > remarkably simular to what I was playing with yesterday :) They make sense, in some sort of human-readable way. > I'm intentionally *not* looking at your X11 GUI until I've taken a first > stab at the Web-based one. I don't want to be biased by your interface. > After I've got something I'm reasonably happy with, I'll take a look at > your X11 GUI and fix all the things I flubbed ;) At the moment, there isn't an X11 GUI. The closest you get is using either an XLIB:DISPLAY or XLIB:DRAWABLE as a sink for IMAGE:EXPORT-IMAGE. //Ingvar From download at hpc.unm.edu Tue Jun 17 12:25:36 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Tue, 17 Jun 2008 06:25:36 -0600 (MDT) Subject: [noctool-devel] CSS is good, right? Message-ID: Hi everyone, I've never been much of a web person and am certainly not up on the latest trends :P Are the kids still using CSS for making their webpages pretty? If so, I was thinking something like CSS could be really useful for the Noctool web UI. Mostly because I couldn't design a decent color scheme to save my life ;P I don't know any CSS, but I'm willing to learn a little ... Jim James E. Prewett Jim at Prewett.org download at hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210 From annis at biostat.wisc.edu Tue Jun 17 12:41:49 2008 From: annis at biostat.wisc.edu (William Annis) Date: Tue, 17 Jun 2008 07:41:49 -0500 (CDT) Subject: [noctool-devel] CSS is good, right? In-Reply-To: (message from Jim Prewett on Tue, 17 Jun 2008 06:25:36 -0600 (MDT)) References: Message-ID: <20080617124149.ABBA940E6E9@cydonia.biostat.wisc.edu> >I've never been much of a web person and am certainly not up on the latest >trends :P I know the feeling. >Are the kids still using CSS for making their webpages pretty? Oh, yes. > If so, I >was thinking something like CSS could be really useful for the Noctool web >UI. Mostly because I couldn't design a decent color scheme to save my >life ;P I've never been convinced that web pages are the best way to interact with system monitoring data, except for the most trivial of cases. What I'd *really* like is something like this (viewable in Safari, Firefox or Opera - requires a plugin for IE): http://www.carto.net/papers/svg/gui/Window/index.svg I've been banging away at an SVG library for CL entirely because of this one URL. -- wm From download at hpc.unm.edu Tue Jun 17 13:36:09 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Tue, 17 Jun 2008 07:36:09 -0600 (MDT) Subject: [noctool-devel] CSS is good, right? In-Reply-To: <20080617124149.ABBA940E6E9@cydonia.biostat.wisc.edu> References: <20080617124149.ABBA940E6E9@cydonia.biostat.wisc.edu> Message-ID: > >I've never been much of a web person and am certainly not up on the latest > >trends :P > > I know the feeling. Glad its not just me :P :) I was a sys-admin during the "dot com boom". Those web guys only made my life hell ;P They seemed to think their infinite loops were the fault of my server - the jerks :P ;) > I've never been convinced that web pages are the best way to > interact with system monitoring data, except for the most trivial of > cases. I think thats true in a lot of cases for sure. BUT, my boss *LOVES* his Ganglia pages, etc. If I can give him a decent web interface, he's /much/ more likely to continue funding my work on Noctool :) What I've been thinking would be really slick would be an Emacs-based "Noctool Console" (if you will) I've only done the most rudimentary of hacking with Emacs, but SLIME sure is sweet and I've seen some UI stuff thats not too bad... Then the web would be a view for more userly types and THE Console would be more for admin types. But thats a dream... > What I'd *really* like is something like this (viewable in > Safari, Firefox or Opera - requires a plugin for IE): > > http://www.carto.net/papers/svg/gui/Window/index.svg THAT'S SEXY! I'm gonna show that to our "web guy". :) > I've been banging away at an SVG library for CL entirely because of > this one URL. Awesome! I was thinking SVG would be nice for graph plots (the things we're currently exporting to GIF) as well simply because, well, they're scalable :) I wouldn't have to re-render the image for every size I might want to display it at, the network bandwidth usage is also not bad when you use gzip compressed SVG. :) From annis at biostat.wisc.edu Tue Jun 17 14:10:13 2008 From: annis at biostat.wisc.edu (William Annis) Date: Tue, 17 Jun 2008 09:10:13 -0500 (CDT) Subject: [noctool-devel] CSS is good, right? In-Reply-To: (message from Jim Prewett on Tue, 17 Jun 2008 07:36:09 -0600 (MDT)) References: <20080617124149.ABBA940E6E9@cydonia.biostat.wisc.edu> Message-ID: <20080617141013.6F78240E92E@cydonia.biostat.wisc.edu> >From: Jim Prewett > >> I've never been convinced that web pages are the best way to >> interact with system monitoring data, except for the most trivial of >> cases. > >I think thats true in a lot of cases for sure. BUT, my boss *LOVES* his >Ganglia pages, etc. If I can give him a decent web interface, he's /much/ >more likely to continue funding my work on Noctool :) There's no doubt sexy blink-panels dazzle managers nicely. >> I've been banging away at an SVG library for CL entirely because of >> this one URL. > >Awesome! I was thinking SVG would be nice for graph plots (the things >we're currently exporting to GIF) as well simply because, well, they're >scalable :) I wouldn't have to re-render the image for every size I might >want to display it at, the network bandwidth usage is also not bad when >you use gzip compressed SVG. :) Even better, SVG is programmable, with Javascript. Instead of reloading images every time you have new data, you could just grab the new data points and update the graph. And they don't have to be complex graphs, either. Tufte has convinced people that even his little sparklines are valuable, and I always found the lightweight, live graphs in Tkined (an underrated SNMP/Tcl/Tk tool) useful: http://www.ibr.cs.tu-bs.de/projects/nm/scotty/gifs/news.gif You can cram a lot of useful information into a small space, and minimize pointless web traffic. Potentially, at least. I've still got plenty of work to do. -- wm From ingvar at hexapodia.net Fri Jun 20 13:00:34 2008 From: ingvar at hexapodia.net (Ingvar) Date: Fri, 20 Jun 2008 14:00:34 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: <20080620121958.37A2BA103@common-lisp.net> References: <20080620121958.37A2BA103@common-lisp.net> Message-ID: Jim writes: > Modified NEXT-TIMESLOT so if it is called without the optional > scheduler and there is no *DEFAULT-SCHEDULER*, a default scheduler is > created and bound to *DEFAULT-SCHEDULER*. Good one! Managed to get bitter by the lack of a PROCESS method for CPU-MONITOR this morning (no, yesterday morning). Quick cheat, until we know what to do with it: (defmethod process ((mon cpu-monitor)) nil) I'm populating a LINUX-HOST equipment with data and will hopefully have time to get data flowing from one lisp instance to another either beginning of next week or over the weekend, depending on how much hack time there is. Unfortunately, this means my source code is FULL of stuff that really should be submitted together, so I'll hold off checking in any changes for now. //Ingvar From download at hpc.unm.edu Fri Jun 20 13:15:34 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Fri, 20 Jun 2008 07:15:34 -0600 (MDT) Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080620121958.37A2BA103@common-lisp.net> Message-ID: > Jim writes: > > Modified NEXT-TIMESLOT so if it is called without the optional > > scheduler and there is no *DEFAULT-SCHEDULER*, a default scheduler is > > created and bound to *DEFAULT-SCHEDULER*. > > Good one! Glad I didn't screw things up too bad ;P > > Managed to get bitter by the lack of a PROCESS method for CPU-MONITOR this > morning (no, yesterday morning). > > Quick cheat, until we know what to do with it: > (defmethod process ((mon cpu-monitor)) > nil) I did the same in my REPL :) > I'm populating a LINUX-HOST equipment with data and will hopefully have > time to get data flowing from one lisp instance to another either > beginning of next week or over the weekend, depending on how much hack > time there is. > > Unfortunately, this means my source code is FULL of stuff that really > should be submitted together, so I'll hold off checking in any changes > for now. Big commits kinda suck, don't they? :P :) I'm working on some web stuff which, simularly, I am planning on committing in one fell swoop. Does anyone have an opinion on if the web UI stuff should have its own subdirectory? Jim From ingvar at hexapodia.net Fri Jun 20 13:27:26 2008 From: ingvar at hexapodia.net (Ingvar) Date: Fri, 20 Jun 2008 14:27:26 +0100 Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080620121958.37A2BA103@common-lisp.net> Message-ID: Jim writes: > > I'm populating a LINUX-HOST equipment with data and will hopefully have > > time to get data flowing from one lisp instance to another either > > beginning of next week or over the weekend, depending on how much hack > > time there is. > > > > Unfortunately, this means my source code is FULL of stuff that really > > should be submitted together, so I'll hold off checking in any changes > > for now. > > Big commits kinda suck, don't they? :P :) Well, the bits that were, on the whole, localised to packages.lisp and network.lisp I checked in as I went. Now it's just the rest of the code... (that touches, at least, scheduler.lisp and classes.lisp). What I have now is: head$ cvs status | grep File | grep -v Up-to-date cvs status: Examining . cvs status: Examining docs cvs status: Examining test-files File: classes.lisp Status: Needs Merge File: network-globals.lisp Status: Locally Modified File: network.lisp Status: Locally Modified File: packages.lisp Status: Locally Modified File: scheduler.lisp Status: Locally Modified > I'm working on some web stuff which, simularly, I am planning on > committing in one fell swoop. > > Does anyone have an opinion on if the web UI stuff should have its own > subdirectory? Unless it's going to be more than 6-10 files, I think it can live in the same directory, though it should probably have its own ASDF file. However, I will not complain if it's subdirectoried off. //Ingvar From download at hpc.unm.edu Fri Jun 20 13:40:26 2008 From: download at hpc.unm.edu (Jim Prewett) Date: Fri, 20 Jun 2008 07:40:26 -0600 (MDT) Subject: [noctool-devel] Re: [noctool-cvs] CVS source In-Reply-To: References: <20080620121958.37A2BA103@common-lisp.net> Message-ID: > Unless it's going to be more than 6-10 files, I think it can live in the same > directory, though it should probably have its own ASDF file. However, I will > not complain if it's subdirectoried off. I was really thinking of adding two files: web.lisp (I'll take suggestions for a better name) and style.css - I'm really not sure where to put the style sheet - really, I intend it to be modified locally so your monitor can match your corporate colors, etc. ;P Initially, I was thinking of generating the CSS from Lisp, but then I thought better of it and decided I'd rather be able to hand the style sheet to some web monkey to make my page pretty (and web monkeys don't know Lisp ;) and I don't want the latest CVS version of the web code to kill the style sheet I worked so long and hard on ;P . Jim From ingvar at hexapodia.net Sun Jun 22 16:04:55 2008 From: ingvar at hexapodia.net (Ingvar) Date: Sun, 22 Jun 2008 17:04:55 +0100 Subject: [noctool-devel] More network protocol success! Message-ID: Haha! One step further, I have now managed to transfer a list of equipment objects in a specified class. Unfortunately, I need to flange things around a bit, so things get put in the right place, in the right places, as it were (not happening right just yet). But the networky side is looking brighter, day by day. //Ingvar