NAME: ----- chekker - ups_database / schedule sanity chekker and utilities SYNOPSIS: --------- $ setup chekker $ chekker [options] [ups_database(s)] $ schedule [options] $ status [options] [ups_database(s)] OVERVIEW: --------- Report writing utilities developed by Marc Mengel and Lauri Loebel Carpenter to help determine: - what has been declared as CURRENT (or any other chain) in the KITS ups_database (or any other ups_database)? (status) - what is the current development schedule for the uas-group (or any other group)? (schedule) - are we in uas-group (or any other group) meeting our published schedules for product declaration (as TEST or CURRENT) in the KITS and/or FNALU ups_databases? (chekker) HISTORY: -------- v1_0: ----- Matt Wicks, previous UAS group leader, maintained all of this information by hand (i.e., did NOT report on the reality of what was in kits etc., but reported his best guess as to what SHOULD be in kits/fnalu/etc.). I couldn't keep up with things and asked Marc to throw together some automated scripts which would allow me to maintain ONE schedule database (instead of the 4 that Matt had been maintaining) and to look at what was REALLY installed/declared in kits/fnalu (with the possibility of checking the local declarations on the oss cluster as well). Marc put the guts of this together in an amazingly short time, and I've prettied it up and reformatted the output a bit, as well as parameterizing and productizing it. v1_1: ----- Add -raw option, useful when you want to do something different with the output (like, sort it for internal use to compare multiple ups databases, etc.). Add -chain nochain and fix the code so that it works. v1_1a: ----- Add html documentation, doc directory. v1_1b: ----- Fix bug with -chain nochain. In previous versions, where only chained versions were reported, there could only be one chain per product/flavor. This is not true with unchained versions -- there can be many unchained versions per product/flavor. Required some rethinking about how we handle that section of reports.pl; the results is that sometimes the dates shown in the report will be different than what we had before. The date is now the MOST RECENT DATE that any flavor of this particular version was touched -- i.e., the most recent date that a new instance was added (for support of a new architecture, e.g.) or the most recent date that a chain was made, etc. IMPLEMENTATION: -------------- Set of perl scripts living in $CHEKKER_DIR/src. Output is written to stdout. The setup implements the three commands as aliases, because I don't see a need for extending the $PATH variable in this instance. ENVIRONMENTAL VARIABLES: ----------------------- CHEKKER_PRODUCTS - used by status and chekker; the ups_database(s) to be checked. Overwritten by commandline argument ups_database. CHEKKER_DBSCHEDULE - used by schedule and chekker; the personally maintained db of product development schedules. Overwritten by commandline switch -schedule schfile. CHEKKER_DBSUPPORT - used by all three; the personally maintained db of who-supports-what. Overwritten by commandline switch -support supportfile. CHEKKER_NOTEFILES - used by status and schedule; the directory containing auxiliary note files referenced by DBSCHEDULE and DBSUPPORT (for additional printed information on the output reports). Overwritten by commandline switch -notes notepath. SOURCE CODE: ----------- The source code and all supporting documents have been placed in the shared ols/uas cvs repository, /usr/products/olsshare/cvs. USAGE: ------ $ setup chekker $ chekker \ [-group support-group] \ # (default: all groups; special case for -group unknown) [-support dbfile] \ # (default: $CHEKKER_DBSUPPORT) [-schedule dbfile] \ # (default: $CHEKKER_DBSCHEDULE) [-notes notepath] \ # (default: $CHEKKER_NOTEFILES/) [ups_database] # (default: $CHEKKER_PRODUCTS) $ schedule \ [-group support-group] \ # (default: all groups; special case for -group unknown) [-support dbfile] \ # (default: $CHEKKER_DBSUPPORT) [-schedule dbfile] \ # (default: $CHEKKER_DBSCHEDULE) [-notes notepath] # (default: $CHEKKER_NOTEFILES/) $ status \ [-group support-group] \ # (default: all groups; special case for -group unknown) [-support dbfile] \ # (default: $CHEKKER_DBSUPPORT) [-schedule dbfile] \ # (default: $CHEKKER_DBSCHEDULE) [-notes notepath] \ # (default: $CHEKKER_NOTEFILES/) [-chain value] \ # (default: current; special case for -chain nochain) [-raw] \ # (default: absent) [ups_database] # (default: $CHEKKER_PRODUCTS) Note, legal chains for the status command are: - chain current - chain development - chain new - chain test - chain old - chain nochain Structure of CHEKKER_DBSUPPORT: ------------------------------- CHEKKER_DBSUPPORT is a file which correlates support-group with product-name (and, optionally, support-person and auxiliary notefile). Format (and example text): #Support:Product:Notefile:Person: clubs-group:------------::: clubs-group:clubstools::: clubs-group:fmss::: uas-group:------------------::: uas-group:allocate:obsolete:debaun: uas-group:blt::mengel: abandoned:------------------::: abandoned:capsqs:capsqs:: Products not listed in the CHEKKER_DBSUPPORT file will show up as being supported by "unknown" in the output reports. (In fact, you can use -group unknown to see a list of products which *aren't* in the database, at least for the status report). Structure of CHEKKER_DBSCHEDULE: -------------------------------- CHEKKER_DBSCHEDULE is a file which lists schedules for products going into "test" and "current" phase in both kits and fnalu (and could be extended to include other places as well, though this hasn't been tested; the hooks are there to determine if other ups_database test/current dates have been entered). In this file, the string is a shorthand for the "standard" flavors of uas-group products: AIX,IRIX+5,OSF1+V3,SunOS+5. A single question mark (?) should be used to indicate that no date has been scheduled for test/current release. Dates must be entered in the form yyyy-mm-dd. Format (and example text): #Product:Version:Notefile:kitsSchedule:kitsFlavors:fnaluSchedule:fnaluFlavors: fulib:v4_2:systools:test=1996-06-25, current=?:,HP-UX+09:test=1996-06-25, current=?:: rbio:v9_0f::test=1996-07-10, current=?:,IRIX+5+debug:test=1996-07-10, current=?:: fmb:v6_4::test=1996-06-18, current=1996-07-02:NULL:test=1996-06-18, current=?:NULL: mbone:v2_0c:mbone:test=1996-03-02, current=?:IRIX+5,SunOS+5,OSF1+V3:test=1996-03-02, current=?:IRIX+5,SunOS+5: Examples: --------- The following are the commands that I use each week to generate three reports: - schedule.out = uas-group product development schedule - status.out = current products in kits for *all* groups - chekker.out = sanity check on uas-group products 1) schedule -group uas-group \ -support $REPORT_DIR/DBSupport \ -schedule $REPORT_DIR/DBSchedule \ -notes $REPORT_DIR/Notefiles/ \ > ./schedule.out 2) status -support $REPORT_DIR/DBSupport \ -schedule $REPORT_DIR/DBSchedule \ -notes $REPORT_DIR/Notefiles/ \ -chain current \ /usr/kits/declared \ > ./status.out 3) chekker -group uas-group \ -support $REPORT_DIR/DBSupport \ -schedule $REPORT_DIR/DBSchedule \ -notes $REPORT_DIR/Notefiles/ \ /usr/kits/declared /afs/fnal/products/ups_database/declared \ > ./chekker.out (These reports go through additional post-processing before they are posted to news and/or on the web). 4) status -group uas-group -chain nochain -raw \ /usr/kits/declared /afs/fnal/products/ups_database/declared \ > ./full-status.raw This example uses the environmental variables to determine DB files, and produces a "raw" (i.e., not pretty and formatted) dump of the products with no chains, sans auxiliary notes. This is useful when you want to look at versions that may have been declared and forgotten. The example.sh file contains a more detailed example of how to set up a script to look at *all* instances and chains (and lack thereof) of all products. (-raw is a v1_1 enhancement, as is -chain nochain). For examples of scripts, real DB files, output reports, see $CHEKKER_DIR/examples. Future Enhancements: -------------------- - ability to compare with previous report and mark differences since last posting - direct html output, with hyperlinks to additional information on each product (although what happens to the news posting if the reports are generated in html to begin with?...) - easier-to-read sanity chekker; additional reports to product maintainers to "ping" them when a scheduled date is approaching so that they remember to do their product installations/declarations on time - ??? Questions? Comments? Contact Lauri Loebel Carpenter, x2214, lauri@fnal.gov.