LimsConfigSlicer - nsc-norway/system GitHub Wiki

LIMS config slicer

The config slicer is documented on the Genologics Zendesk: https://genologics.zendesk.com/hc/en-us/articles/213974803-Managing-Configurations-with-Config-Slicer

The #1 use cases are to Add index sequences to LIMS and to install new versions of protocols.

Transport of protocols and version control (NSC-OUS node)

For major changes to protocols we need to transport a new version of them from the development to the production server. There are a number of wrapper scripts which automate some of the interaction with config-slicer.

The general principle we use is that no configuration objects (such as process types, protocols, etc.) should be overwritten -- instead, a new version should be added. On dev-lims, there is usually just a single version of each protocol, etc., which can be renamed when a new version is prepared. This can be copied over and over again to ous-lims, and each time there will be a new version on ous-lims.

The following objects can be versioned:

  • Protocols (together with their step configuration)
  • Process types (together with their UDFs)
  • Reagent kits

Sample and Project UDFs cannot be updated using versioning, and the changes need to be applied in parallel on both server instances. Workflows cannot be renamed, so it is usually just as practical to create new workflows on the production server each time new protocols are installed.

Config slicer overview

Config slicer is a Java application which uses the API to read and alter the configuration. It is located in /opt/gls/clarity/tools/config-slicer.

The config slicer writes to a log file called configslicer.log. Feel free to delete this file before use, in order to only see your own output.

Wrapper scripts

The *cs.sh wrapper scripts automatically pass the URL, username and password arguments to the config slicer, and then forwards any other arguments specified at the command line.

  • cs.sh : Invoke config slicer locally
  • devcs.sh : Invoke config slicer operating on dev system, from the production system
  • transport.sh : Script which calls cs.sh and devcs.sh in order to copy a protocol from dev-lims to ous-lims
  • reverse-validation.sh : Takes a protocol from prod. and identifies the differences, if any, with the same protocol on dev
  • reverse-transfer.sh : Copies a protocol from prod. to dev and forces the import using the hazardous importAndOverwrite option

Using the transport.sh script to copy a protocol

The transport.sh script calls the config slicer to perform roughly these commands:

  • Export a manifest file from dev for a protocol
  • Export an XML config file from dev using the manifest
  • Validate the XML against prod. If not valid, terminate here.
  • Prompt for confirmation to import
  • Import the XML on production

Usage: Log on to the production server ous-lims.sequencing.uio.no and change to the glsjboss user

sudo -u glsjboss -s

Change to the config slicer dir

cd /opt/gls/clarity/tools/config-slicer

Run the transportation script specifying the protocol to transport

./transport.sh PROTOCOL_NAME

e.g.

./transport.sh "Demultiplexing and QC NSC 2.0"

Troubleshooting

Typically there will be conflicts. The easiest is to first look at the output and look for Exists and are different. Sometimes it will be ovious what is the difference.

Common options are:

  • Manually change to object so it matches on both sides
  • Create a new version of the object by renaming it on the dev server

The configslicer.log XML diff sometimes produces a heap of "false positive" differences, with just the order of the XML attributes changed (irrelevant). It can still be useful for trying to spot the differences.