noctool-devel June 2008

noctool-devel@common-lisp.net

3 participants
11 discussions

[noctool-devel] More network protocol success!
by Ingvar 22 Jun '08

22 Jun '08

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

1 0

[noctool-devel] Re: [noctool-cvs] CVS source
by Ingvar 20 Jun '08

20 Jun '08

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

2 3

[noctool-devel] CSS is good, right?
by Jim Prewett 17 Jun '08

17 Jun '08

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(a)Prewett.org download(a)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

2 3

[noctool-devel] Re: [noctool-cvs] CVS source/docs
by Ingvar 17 Jun '08

17 Jun '08

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

1 0

[noctool-devel] what is a cpu-monitor?
by Jim Prewett 16 Jun '08

16 Jun '08

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(a)Prewett.org download(a)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

2 4

[noctool-devel] More network protocol things
by Ingvar 15 Jun '08

15 Jun '08

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 name> (<protocol header> <rest> <of> <message>...) ... function body goes here) This does two things, it defines a function <function name>, 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

1 0

[noctool-devel] We (almost) have network!
by Ingvar 14 Jun '08

14 Jun '08

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

1 0

[noctool-devel] image.asd fixes
by Jim Prewett 12 Jun '08

12 Jun '08

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(a)Prewett.org download(a)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

2 3

[noctool-devel] anonymous CVS works!
by Jim Prewett 12 Jun '08

12 Jun '08

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(a)Prewett.org download(a)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

2 3

[noctool-devel] compact configurations for identical machines
by Jim Prewett 05 Jun '08

05 Jun '08

Hello, I was thinking about what a bear it will be to have to specify each of my compute node systems in my clusters individually. I was thinking about syntax such as the following that would create an equipment object for each of 256 hosts named l001 through l256. (machine-cluster "LosLobos" linux-host (user "download") (disks (disk "/dev/sda1" 80 95)) (machinerange "l001-l256")) What do y'all think? Is there a better way to do this? Something like this would reduce the size of my shop's config file a couple orders of magnitude - in turn, I'd screw things up accordingly less often :) Jim James E. Prewett Jim(a)Prewett.org download(a)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

3 20

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

noctool-devel June 2008