70 likes | 311 Views
Remote Software Deployment. Nick West. Overview. RSD is a framework for remote software installation. For Library Developers It standardises the writing of 2 scripts:- To assemble a tar (usually source) of the library on the local machine.
E N D
Remote Software Deployment Nick West
Overview • RSD is a framework for remote software installation. • For Library Developers • It standardises the writing of 2 scripts:- • To assemble a tar (usually source) of the library on the local machine. • To install/validate the library given its tar file on a remote machine. • For End Users:- • It allows complete applications (software stacks) to be installed on un-primed remote machines with a single command.
Some Definitions • A Library • The basic building block. • Libraries are specified with the syntax: • name:version e.g. mysql:5.0.22 • An RSD library may consist of multiple linux libraries. For example root is considered to be a single RSD library. • An Application • Is a library stack i.e. a sequence of specified libraries built in order. For example the application minossoft:S07-09-20-R1-26-build_1contains:- • dcap:v2_39_sl3.0.3_Linux+2.4libsigc++:1.2.5 • mysql:5.0.22 • root:v5-16-00 • minossoft:S07-09-20-R1-26
How RSD Works • Assemble: The Library Developer • Creates scripts to assemble and install libraries. RSD uploads them onto the web. • Launch/Install: The End User • Defines applications built from the libraries and launches a job to a remote machine. • On the remote machine a bootstrap script first downloads RSD, then the required libraries and installs the application and returns build results.
RSD: The Developer Perspective • RSD doesn’t solve the problem of library installation • but it provides a framework for script writing so it only has to be done once! • For tar file assembly script • It provides a workspace. • It uploads the tar file. • For the library installation script • It provides access to all supporting libraries i.e. those below the library on the software stack. • It provides simple tools to log the operation of the script. • It provides a standard place for scripts to be used be end user to setup the library.
RSD: The End User Perspective… • Simple installation operation • For example the command:-rsd launchlcg:lcgce01.gridpp.rl.ac.uk:2119/jobmanager-lcgpbs-minosL \ minossoft:S07-09-20-R1-26-build_1-SL4submits an LCG GRID job using Ganga to build the specified application on the RAL T1 CE using queue lcgpbs-minosL • Simple removal operation • Using the “remove” command e.g.rds launchlcg:lcgce01.gridpp.rl.ac.uk:2119/jobmanager-lcgpbs-minosL \ --remove minossoft:S07-09-20-R1-26-build_1-SL4 • Transparent library sharing • Libraries are built in the context of the supporting libraries. • Before installing a new library RSD checks to see if one with the right version and context already exists and reuses it if found. • Libraries are automatically removed once all applications that share them have been removed.
RSD: …The End User Perspective • Basic platform support • RSD identifies the platform (currently just SL3/4) and makes that part of the library context and application build name. • So the same file system can be shared between different platforms without the risk that RSD will mix libraries across platforms. • Validated installation • Using the validation step of each library install script. • Simple build optimisation • Before running a full install of a library that has been built before RSD first attempts to validate. • So if installation fails late in the software stack the next RSD install job will simply validate supporting libraries and will skip their re-installation. • Limited remote job submission • Currently either • To the local machine. • Via Ganga to either PBS or LCG grid. • Software tag publishing • When installing/removing on an LCG GRID machine RSD will use the tool lcg-ManageVOTag to either publish or withdraw software tags. (Software tags allow users to target production jobs to batch farms with the required software).