...
- Production (nmprod, vaprod)
- The current release of the AAT/PPI
- No redeployments without an announcement to the archive_issues list
- Web interface: archive-new.nrao.edu
- Test (dsoc-test, naasc-test)
- Used for integration testing & validation of changes (features or bug fixes)
- Also the home for pre-release candidates for release to production
- Typically stable on day+ timescales
- Major redeployments are announced on the archive_test list
- Web interface: archive-test.nrao.edu
- Development (nmtest, vatest)
- DeveloperDevelopers' s basic verification testing ground
- Often subject to sudden redeployments of subsystems
- Can have components from multiple branches of development deployed at one time
- Web interface: webtest.aoc.nrao.edu/portal/#/
- (Yes, I know, that name is unfortunate)
However, when it comes to the basic utilities for Data Analysts, the separation between these environments can be somewhat blurred: those the tools are all installed next to each other within the vlapipe & almapipe account's home directories. This makes it easy to potentially use the wrong set of software (or mix software and settings from multiple environments) by mistake, and that's without accounting for bugs in the software itself. This document is meant to demonstrate a few suggested methods of accessing those tools in ways which might reduce the chance of confusion among the installations.
...
As a convenience feature, these two accounts have had the 'activate_profile' & 'deactivate_profile' commands added to their Bash configuration. When given the name of a CAPO profile (nmprod, dsoc-test, etc) ' activate_profile' sets up a few environment variables and sets up your shell so that the corresponding set of utilities (and the correct supporting libraries) in your PATH $PATH, so that they're easy to use.
You can 'can activate_profile' with a new argument to update to a new configuration (for instance, testing a new feature before release), or 'or deactivate_profile' to clean up what was done and go back to the basic account settings.
...
When running just a few commands, it might be easier to simply directly call the appropriate utility without resorting to the relevant 'pipe' account. In that case, pay particular attention to the directory from which you run the command (either by changing directory there or typing out the path). The differences between : /users/vlapipe/workflows/nmprod/bin/myCommand and /users/vlapipe/workflows/nmtest/bin/myCommand can (potentially) be both not just the details of the software itself, in addition to but also any differences in the profile's parameters.
...
You can provide most (if not all) the AAT/PPI utilities with a a -P option to define the CAPO profile you want to use. It's typically a good idea to do so, as you likely do not have the the CAPO_PROFILE environment variable set, and not all the utilities are capable of guessing the profile from their location.
Often, you'll want to ensure that the profile you provide matches that of the utility you're running, but there is one exception: In version 3.7.0 and later, restoreToCache can be provided one of the VLASS profiles (vlass.test, vlass.w7, etc) to run the restore workflow with appropriate settings for that project.
...
For running a larger set of commands for a single environment, there is an alternative to using the vlapipe/almapipe accounts (which is particularly helpful if you need access to directories where those accounts don't have permissions). This is not as comprehensive as using 'activate_profile', so it is recommended that you don't switch between environments using this method.
It is possible to approximate what is done via via activate_profile with:
export CAPO_PROFILE=myprofilesource ~pipeaccount/workflows/myprofile/bin/activate
Where pipeaccount is vlapipe or almapipe, depending on where you're working, and myprofile is the appropriate name from the discussion of the 3 environments/installations in the introduction.
...
The entirety of the software making up the AAT/PPI is deployed upon that environment's server in NM, with only a subset deployed to its companion machine in CV. There is a separate copy of the utilities deployed to the almapipe account, and there is an independent workflow system on the CV server. However, as most of the AAT/PPI utilities are just sending system messages to provoke action, the fact that the messages message processing system (amygdala) is located in NM may cause additional delay for some commands.
...
The configuration details for the AAT/PPI are kept in text files in /home/casa/capo. . This directory is replicated to CV via rsync on a cron job, so it is not immediately updated after an edit. There are a set of properties for each site (NM vs CV) and environment (Development, Test, Production). Included in that directory are a set of files for the VLASS project, containing configuration specific to their processing needs.
...
{needs more details}There are already simlinkssymlinks, no official timeline, but be prepared for the replacement of nmprod with dsoc-prod, and nmtest with dsoc-dev the like.