Why is CONDABASE defined in /etc/procmgrd.cnf?
Multiple options were discussed. Solution #4 was eventually chosen. (10/31/2018)
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris Ford writes |
|---|
|
Problem: procmgr needs location of conda.sh before activating conda env (including remote hosts)
Solution #1: hardcode the path in the procmgr code
Pro: expedient!
Con: maintenance nightmare -- path cannot be modified without new procmgr release
Solution #2: run 'conda info --base' locally
Pro: avoids hardcoding of path
Con: may require conda base to be activated prior to running procmgr; lots of moving parts
Solution #3: include the path in cnf file
Pro: avoids hardcoding of path; enables user to adjust
Con: adds clutter to every cnf file; enables user to get it wrong
Solution #4: include the path in a static procmgr configuration file
Pro: avoids hardcoding of path; enables sysadmin to adjust; /etc/procmgrd.conf exists today
Con: /etc/procmgrd.conf historically not present on LCLS operator consoles; /etc is not the best directory choice
I prefer solution #4. How about you? |
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Clemens Weninger writes |
|---|
|
Solutions #4 or #3 would be my preference. |
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris O'Grady writes |
|---|
|
If #2 (the ideal solution) is proving to be difficult, I think I would vote for #3.
Solution #4 (procmgrd.conf) feels strange to me, but I could be convinced. |
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris Ford writes |
|---|
|
Regarding #4, we can adjust the file name and location if they are a problem.
I recall that Amedeo preferred a location other than /etc for such configuration files.
But that was years ago, and neither Amedeo nor I recall the exact details.
Whatever the file name, here are the seldom-changing parameters it currently holds:
# procmgrd.conf
PORTBASE=29000
PROCMGRDBIN=/reg/common/package/procServ/2.6.0-SLAC/x86_64-rhel7-gcc48-opt/bin/procmgrd
PROCMGRDUSER=nobody |
| Code Block |
|---|
| language | text |
|---|
| title | Chris O'Grady writes |
|---|
|
If #2 doesn’t work, then I think you’ve convinced me to change my vote to #4 (keeps the cnf file clean). |
Procmgr: how to handle RELDIR and TESTRELDIR env vars?
(10/8/2018)
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris O'Grady writes |
|---|
|
if RELDIR is defined you get:
PATH=$RELDIR/bin
if TESTRELDIR is defined you get
PATH, LD_LIBRARY_PATH, PYTHONPATH
If both are defined, you get all of the above, with TESTRELDIR taking precedence over RELDIR in PATH. |
DAQ packaging changes, and cnf/procmgr tweaks
Note references to RELDIR and TESTRELDIR (10/4/2018).
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris O'Grady writes |
|---|
|
I just committed changes that should allow us to package the DAQ code (python/C++) in a conda-friendly manner
(many thanks to Chris Ford for changing procmgr to allow picking up of executables via PATH, which is how conda works).
This is all part of an effort to get away from running many DAQ processes from “Matt’s directory”. The summary:
- everything (daq/psana/xtcdata/psalg) now lives in the standard bin/lib/site-packages directories in the install dir
- DAQ now has 2 python packages: pydaq/cas with an associated setup.py. pydaq should probably be renamed to “control”. build_all.sh has been modified to install the daq python.
- cnf files have been moved to a directory named “cnf”
- all executables launched by a cnf (python or C) are picked up from the install/bin directory via PATH
- PATH/LD_LIBRARY_PATH/PYTHONPATH currently gets set using the env variable “TESTRELDIR” hardwired at the top of the cnf files
- in future there would be an additional env variable RELDIR (the “base release”) which can be augmented with “TESTRELDIR” as appropriate if one only wants to checkout/build part of the code base.
So far I have only changed lab3-base.cnf and lab3-hsd.cnf to the new style. I will work with you to change other cnf files.
There may be issues that arise with these changes. If so, I will work with you to fix. |
I can determine the current conda release version from my environment. Why does procmgr need it configured in cnf files?
| Code Block |
|---|
| language | text |
|---|
| theme | DJango |
|---|
| title | Chris Ford writes |
|---|
|
Not everyone has the same use case. A developer typically runs procmgr after activating conda, but others invoke procmgr directly.
For example, LCLS hutches start procmgr from desktop icons.
Not every process requires conda. The conda keyword identifies a procmgr process as requiring conda.
Procmgr supports remote processes. Processes running remotely see environment variables defined remotely,
these variables differ from what you observe locally.
When deployed at LCLS, relying on environment variables can complicate determining exactly which DAQ release is running.
We avoid relying on environment variables when possible. |
