Policies for Using Online Directories and Accounts

From GlueXWiki
Revision as of 13:29, 26 November 2013 by Wolin (Talk | contribs)

Jump to: navigation, search

Draft - for discussion

This note is intended to jump-start a discussion on how to organize online directories and how to use online accounts. Comments, suggestions and criticisms are welcome. Our hope is to come to general consensus soon, and we expect developers to follow the guidelines shortly thereafter.


Elliott Wolin, Dave Lawrence, Mark Dalton
26-Nov-2013


Below we discuss suggested best practices concerning allocation of directories on the online file server, as well as guidelines for using the various accounts available on the online computer system. Our recommendations are based long-term on experience from CLAS, experience from the Hall D offline software effort, GlueX-doc-1892 developed as part of the 12GEV planning process concerning this topic, and discussions with Serguei P and others.

The next two sections give background information and discuss general concerns, skip to the last section if you are just interested in a summary of recommended best practices.


Goals

The single most important goal is to protect the production software deployment directories from accidental overwrite. Note that the worst case is not simply causing the system to hang or crash, rather it is to cause the system to appear to work but in fact not work properly. Many days of data taking could be lost if this happens.

Another important goal is to provide a suitable environment for developers. Such an environment should allow for rapid development, testing and installation of new code without compromising production code, and should also allow developers to easily collaborate. Note that we have already implemented a code management/build system that will not be discussed below except to show how it furthers the goals outlined in this document.

Finally, for those of us who will be on call for online systems, another goal is to minimize the number of calls we get at 3am. This can only be accomplished if there is very strict control over what gets released for production use.


General Remarks Concerning Directory and Account Strategy

Almost all directories of interest reside on the gluonfs1 file server in /gluex. This area is visible on all computers and ROCs in the online cluster, and can be seen from all accounts. This includes the main operator account, hdops, as well as individual accounts. It is critical to get the protections in this area correct so that code can be developed and tested by (groups of) individuals, installed by system installers (via the hdsys account), and used but not overwritten by the hdops account. Of course the hdops account will need to have write access to some directories for logging, backup and the like.

In analogy with the offline, the main code deployment directory is /gluex/builds, with many named builds appearing underneath. This area must be read-only to hdops, and writeable only from the hdsys installation account (same as for the gluex account in the offline system). Operators and developers must be able to always rely on finding working code in the build areas, with the exception of the devel build, which by its very nature is unstable. A small number of additional directories need to be treated like the build directory. These will hold production configuration information needed by CODA and other packages, and again must be writeable only by the hdsys account.

Note that development work should NOT be done in the directories described above. /gluex/Subsystems (similar to /group/halld/Subsystems) is available for developers to use in any way they wish, and production running should never access or rely on code or configuration files in this area. Once again, developers should work from their own accounts and should not use the hdsys account (which exists solely for making releases into the production areas). Other areas developers can work in are /gluex/Users and of course /home/<your-username>, where the same remarks about not being used for production running apply.


CODA

The CODA toolkit supplies the foundation for data acquisition in the hall and it is critical that a working version exists at all times. Until now /gluex/coda contained a version of CODA maintained by Dave Abbott that was used the past year or so for his private use and testing in the counting house. Starting very soon /gluex/coda will contain a stable release of CODA maintained by the Hall D DAQ group (will be installed just as soon as the JLab DAQ group creates such a release). This area may not contain the latest bug fixes to CODA, but developers should be able to rely on finding a working version there. Note that Dave Abbott's test version of CODA will move into /gluex/Subsystems (to be used as described earlier).


Summary of Recommended Best Practices

  • Operators should work exclusively from the hdops account, which only has write access to selected logging and backup directories.
  • Production code should be installed via the hdsys account, which is the sole purpose of this account. Production directories are only writeable from the hdsys account.
  • Only selected online experts are allowed to install code via the hdsys account, contact the Online group if you need to have code installed.
  • Developers should work from their own personal accounts, NOT from the hdsys account. Personal accounts should default to using the halld group.
  • Developers should use /gluex/Subsystems when code or configuration files must be shared (same as is done in /group/halld for the offline).
  • All development efforts should use available code management tools.
  • Use the scons-based online build system except in special cases (e.g. EPICS and builds of the offline code on online computers).