--On Tuesday, April 23, 2002 11:00 AM -0700 Matthew Rechs <[EMAIL PROTECTED]> wrote: > I think this project is a great idea, though I share another poster's > concern that we ought to strive to keep things as simple and monolithic > as possible. I've responded to that message on the mailing list, hopefully I've addressed your concerns. > > - The XML layer adds a lot of complexity and I wonder if it pays off > enough to be worth it. I realize that XSLT is suited to the job of > translating from our schema to the platform-specific configuration files, > but it sure adds a lot of complexity for this relatively modest benefit. > Would we just be better off with some Perl code that knew how to do the > translation for each platform? I don't really know anything about XML > application servers, so I find that part really very scary. > I think it is worth it. Especially since we want this system to be extendable to support other monitoring systems. We definitely want to use the same system to configure both MON and Cricket. And I think other monitoring systems might be interested in writing tools to convert our XML output to their own configuration syntax. Looking at the current files I just posted on the netsage website, I'm beginning to think that an XML format very similar to our current output format might be a far more elegant way to configure MON, and at some point I might write patches to allow MON to read an XML config file directly, rather then continuing to use the 'generate a mon.cfg file' approach longterm. As to the XML Application Server idea, we haven't really made that decision yet (and won't need to for another 3 months probably). But we're thinking about that in order to provide separation between the logic and the presentation. (I.e. the database UI code outputs XML which the XML App Server converts to HTML). An XML Application Server in its simplest form is basically just an XML style sheet processor embedded into the web server. The separation between logic and presentation could be handled in other ways (writing our own layout engine, for example) but I definitely want the separation to exists. One of my biggest annoyances with another project I've worked on is that changing the UI layout involves editing a lot of raw HTML code interspersed with all the logic code, which is just a mess. Adding a single entry into a table shouldn't require having to rearrange the <td> and <tr> elements in the rest of the code that generates that web page. > - I'm a little confused about the exact scope of the project. "NetSage" > is just the database that contains abstract configuration information, a > web interface to that database, and the code that exports > platform-specific config files. Right? NetReg and NetMon are CMU-specific > tools that I guess you'll use to put data into NetSage, but the rest of > us will most likely use the web interface, right? > Correct. Since NetReg and NetMon have been released as open-source, anyone who is interested in using them could set them up and use the scripts we'll write for syncing that data into NetSage, but it will NOT be a requirement. We just want to make sure we leverage (I hate that word) the data we already have in those systems. For example in NetReg we might have a list of load-balanced web servers, and rather then maintaining a separate list of those machines in NetSage for monitoring them, we'd rather propagate that data automatically, and mark it as 'external' data so that the NetSage web interface doesn't allow it to be updated. > - What would be really useful would be to see a punch-list of > modifications that would be required to the existing Mon system. I think > that would really help contextualize the project for everybody. > The list of changes to the Mon is actually pretty small. Off the top of my head I can think of: -Adding a better security model to Mon clients (i.e. use your favorite flavor of Apache authentication module, and make the Mon CGI scripts pass the user to the Mon server) (I don't think thats currently available) -Adding a better security model to Mon "traps", probably using a shared key and an MD5 hash of the trap+key to verify authenticity of the trap -Improving/Expanding the support for user 'views' in Mon clients, so that when you view the status web page you don't see things you don't care about (network engineers probably don't care about web server status) Views are already built into our NetSage database design, with hierarchical views (i.e. subviews) supported. > I am a fairly decent Perl programmer, but I'm afraid I've become rather > more of a manager/project manager in the last couple of years. We have > some other programming resources we might be able to contribute. If > anyone was interested in taking project planning/documentation seriously, > I think I could be useful there, and perhaps contribute some of our > professional project managers' time, as well. > Having somebody to write the documentation might be helpful, as past experience tells me that our own tech writing group is only available to document things available to our users (the campus commmunity) and not internal systems (which this will definitely qualify as). And I really have no clue how to document some things, like our database schema. > We also have extremely good web UI/design skills in-house, and our team > is actually very good at designing tight UIs for very technical > applications. I have checked it out with our management, and there is > support for contributing some resources to this project, once we can > quantify what the right way to do that would be. Thats the place where I think we could use the most assistance. Our two developers (me and a coworker) don't really have any UI *design* experience. I've spent a lot of time maintaining and extending UIs designed by other people, but this will involve starting from scratch. Heres my favorite UI design issue for this so far: What web interface would you use for allowing users to defined periods? We probably don't REALLY need to allow periods down to the level of detail that Time::Period allows (periods that match every other second seem really useful for monitoring to anyone??), so perhaps just giving granularity down to minutes is sufficient. If anyone has any brilliant ideas on this one, let me know. (I'd definitely like to avoid Java, and preferably javascript as well, but I'm not sure I'll be able to) If left to our own resources we won't start developing the web interface till about the end of the summer (school-wise, not weather-wise) as we're trying to get the monitoring part of the system out the door as fast as possible. But in theory as soon as a week from now somebody else could start developing a web interface in parallel to us working on other things (the Mon changes from above, and a bunch of monitor scripts we need to write). -David Nolan Network Software Developer Computing Services Carnegie Mellon University
