Working with community-defined RTEs

Community-defined RTEs are RTEs that created, managed and distributed by a particular community.

ARC provides the software solution to automate Community-defined RTEs discovery and software environment provisioning for distributed computing e-Infrastructures.

Typically community-defined RTEs describes software packages used for computations. The community itself is responsible for building, testing and verifying a particular version of software packages and the RTE scripts that will prepare such runtime enviroment to be used on the computing cluster worker nodes behind the computing element.

In general RunTime Environments in ARC are very flexible, so in addition to defining software packages such RTEs can be used to transfer data or communicate with community services to fetch/register some data. It is up to community to define what they need.

This document describes how to work with community RTEs from the ARC CE admin point of view.

To establish a community-defined RTEs registry refer to this guide.

1. Enable Community-defined RTEs support

Community RTEs support is added as a technology preview in the ARC 6.5 and turned off by default.

If you need to support Community RTEs deployment on the ARC CE, please install nordugrid-arc-community-rtes package:

[root ~]# dnf -y install nordugrid-arc-community-rtes

2. Establish trust chain with community

The trust-chain between community and site-admin is based on the digital signatures. All Community-defined RTEs are supposed to be signed using OpenPGP standard for signatures. Technical implementation relies on the GNU Privacy Guard (GPG) software.

To add a new community to the trusted list run:

[root ~]# arcctl rte community add example.org
The imported community public key data is:
  pub   2048R/AA56A775 2020-01-30 [expires: 2022-01-29]
        Key fingerprint = 3A47 F0D4 E406 D854 EDAA  ADB5 8FD6 DD57 AA56 A775
  uid                  Example Computations Lab <support@example.org>
  sub   2048R/3F914B9D 2020-01-30 [expires: 2022-01-29]

Is the community key fingerprint correct? (yes/NO): yes

Warning

Check the community key fingerprint matches the one provided to you by community authorities!

Note

Alternatively you can pass expected fingerprint value to --fingerprint option

In the provided example the example.org is the name of the community to add and at the same time it is interpreted as a domain name of ARCHERY community-defined RTEs registry.

If the ARCHERY domain name is different add the --archery <DOMAIN> option.

It is also possible to establish trust with community using OpenPGP compatible keyserver or web-based RTEs registry [1] as an alternative to ARCHERY.

[1]

TODO: Document this alternative options. For now you can follow –help to find some info

3. Discover RTEs in the registry

Note

Examples below show APPS/EXAMPLE.ORG/SIMULATION-3.0.1 is already deployed on ARC CE. That is result of the next step execution.

You can list all available community-defined RTEs with rte-list command:

[root ~]# arcctl rte community rte-list example.org
APPS/EXAMPLE.ORG/SIMULATION-3.0.1    (deployed, registry)
APPS/EXAMPLE.ORG/ANALYSIS-1.7.0      (registry)
ENV/EXAMPLE.ORG/SENDSTATS-1.0.0      (registry)

RTEs optionally provide description string that can be viewer with long listing:

[root ~]# arcctl rte community rte-list example.org --long
Community deployed RTEs:
  APPS/EXAMPLE.ORG/SIMULATION-3.0.1   # Example Simulation Software
Additional community RTEs available in the registry:
  APPS/EXAMPLE.ORG/ANALYSIS-1.7.0     # Example Analysis Software
  ENV/EXAMPLE.ORG/SENDSTATS-1.0.0     # Send stats to central example.org services

Before deployment it can be useful to look inside the RTE script. The rte-cat will show you the content:

[root ~]# arcctl rte community rte-cat example.org APPS/EXAMPLE.ORG/ANALYSIS-1.7.0
# description: Example Analysis Sowtware
# download: url:https://example.org/soft/analysis.sif checksum:md5:63490ad38190a6f172a9020c0c5615f4

if [ "x$1" = "x1" ]; then
  mkdir ${RUNTIME_JOB_DIR}/bin
  cat > ${RUNTIME_JOB_DIR}/bin/example-analysis <<EOF
#!/bin/bash
exec singularity run ${RUNTIME_JOB_SWDIR}/analysis.sif "\$@"
EOF
  chmod +x ${RUNTIME_JOB_DIR}/bin/example-analysis
  export PATH=${RUNTIME_JOB_DIR}/bin:${PATH}
fi

4. Deploy community-defined RTE

Deploying a community-defined RTE from the registry requires nothing more that passing the RTE name to rte-deploy:

[root ~]# arcctl rte community rte-deploy example.org APPS/EXAMPLE.ORG/SIMULATION-3.0.1

This command will:

• fetch the RTE script signed by community

• verify the signature using trusted community public keys (installed during step 2)

• deploy the RTE script itself to be used further with arcctl rte

• download files specified in the community-defined RTE script to the community software location

• verify the checksum data of downloaded files

Note

HINT: It is useful to increase the debug level to at least INFO level during the deployment phase to monitor the progress.

5. Enable community-defined RTE

After deployment of community-defined RTEs, operating can be done as ususal - the same was as for other RTE types.

In particular you can list, enable or default RTEs including deployed from community registry:

[root ~]# arcctl rte list
ENV/CANDYPOND                      (system, disabled)
ENV/PROXY                          (system, enabled)
ENV/RTE                            (system, disabled)
ENV/SINGULARITY                    (system, disabled)
APPS/EXAMPLE.ORG/SIMULATION-3.0.1  (community, disabled)

[root ~]# arcctl rte enable APPS/EXAMPLE.ORG/SIMULATION-3.0.1

Additional information and hints

This section provide information how to customize the community-defined RTEs operations.

Location of deployed community software

By default the location for the deployed community software is picked up automatically based on arc.conf and relies on the session directory in particular.

You can discover and change the location with arcctl:

[root ~]# arcctl rte community config-get example.org
SOFTWARE_DIR=/shared/session/_software/example.org
SOFTWARE_SHARED=Yes

[root ~]# arcctl rte community config-set example.org SOFTWARE_DIR /opt/community/example.org

Operating without the registry

It is possible to deploy community-defined RTEs using the same arcctl automations without registry.

During the deployment phase you can provide the URL to the signed RTE file with the --url option:

[root ~]# arcctl rte community deploy example.org ENV/URLDEPLOYED-1.0.0 --url http://example.org/rte.signed

Or it can be even an RTE script without a signature if you trust the contents:

[root ~]# arcctl rte community deploy example.org APPS/SIM-DEVEL --url file:///home/example/dev/myrte.sh --insecure

Removing RTEs and communities

If you want to remove a deployed RTE or an entire community, there are rte-remove and remove actions respectively:

[root ~]# arcctl rte community rte-remove example.org APPS/EXAMPLE.ORG/SIMULATION-3.0.1
[2020-02-06 18:11:03,653] [ARCCTL.RunTimeEnvironment.Community] [ERROR] [32505] [Community
RTE APPS/EXAMPLE.ORG/SIMULATION-3.0.1 is enabled. Please disable it first or use "--force"
to disable and undefault automatically]
[root ~]# arcctl rte community rte-remove example.org APPS/EXAMPLE.ORG/SIMULATION-3.0.1 --force
[root ~]# arcctl rte community remove example.org