ARC Experiences with ETICS, April 2009

This report summarizes ARC experiences with ETICS (I've concentrated mostly on problematic issues) as of April 2009. Available also in pdf.

Terminology

Getting used to specific language used within the system took some while. For example what does the terms "registered" and "supported" platform mean and how do the concepts behind them differ. That should just be interpreted as wish for even more clear documentation (see point III.) .

Usage

Getting used to specifics of web interface, quite often need to reload certificate (little bit annoying). It is well usable but it would be perfect if it would be little bit faster (though not sure whether this is feasible without changing underline technology).

Available platforms

I found a little bit misleading claim on support for wide range of platforms. When getting acquitted with ETICS one get along terms as "registered" and "supported" platforms. For instance output of "etics-list-platforms" binary comming with ETICS command line client returns list containing ~60 different "registered" platforms (platform means specific combination of OS, CPU architecture and compiler e.g. sl5_ia32_gcc412). I found it a little bit confusing that not all platforms that are "registered" are actually directly usable. I did not find any simple mean for how to get information on whether the selected platform is available from within command line client, except of submitting a remote build to all platforms returned as result of the binary and checking which gets through (Though it is possible to get this information through web interface when submitting remote build of particular configuration, there a platform needs to be selected from a list which contain only those platforms that are really usable (~12 platforms)).

I was already explained what really is meant by term registered but never the less I still think it is misleading to some extent and may be it would be worthwhile to add some kind of disclaimer to man page (or output) of this binary or to add an option that will list only those platforms that are available in the default pool at a specific time of issuing the command.

Dependencies

Dependencies handling model used within ETICS is maybe the single most innovative and at the same time most problematic feature of the build system. One could identify three sorts of dependencies within ETICS:

Preinstalled dependencies

Software that comes as default equipment of a platform, there is available list of per default available packages for each platform. This is rather trivial and there is no way to change this from the user side (though the ETICS team decided to add gettext-devel package to relevant platforms when we've encountered problems with autoconfiguration. It was considered to be too low level to be dealt with through general external-dependencies mechanism). In the following we will discuss the two approaches that are more relevant from the user perspective.

External dependencies

So called "External dependencies". This term refers to packages that are not part of the per default available software at the worker nodes. Each specific external software is managed as a component of one of ETICS projects. The project is (not very surprisingly) called "externals". When building target code any of those components can be chosen as a dependency. In such a case all of selected packages will be installed in the steps preceding the build steps of the target code. There is well defined procedure to request addition of software to the ETICS, which - if successful- results in addition of the package for selected platforms in the "externals" project in ETICS. From this location it can be used by any other project and component within the system. The management and control of the components are on the side of ETICS team.

Alternative approach to external dependencies

Dependencies managed as components within the project itself. Once the component with dependency is set up and configured, its use is very similar to this of "External dependencies". This approach gives most flexibility and freedom to the user, all responsibility rests within the project (with all resulting advantages and disadvantages). This is the approach that is currently used within ARC.

Discussion

There are several points to note on the dependencies handling within ETICS, most importantly the dependent software is not installed using standard package management tools (such as rpm, dpkg etc...) of the distribution (resp. OS), and furthermore it is not installed in standard locations. Consequently there is need to set/modify some environmental variables (e.g. GLIBMM_CFLAGS or PKG_CONFIG_PATH) to successfully use them during compilation.

I will illustrate some of the issues that might be connected to this approach to the dependencies' management on the problems that we have encountered during ARC builds. The ARC development code is stored in the svn repository under http://svn.nordugrid.org/repos/nordugrid/arc1/trunk. It is standard autotools based project source code repository. There are only few of mandatory external dependencies of ARC and those are quite low level thus there was only one mandatory dependency of ARC that was not available per default on worker nodes on ETICS default infrastructure, namely glibmm (both glibmm and glibmm-devel packages on most platforms).

Unfortunately the standard approach to dependencies described in point IV.B did not work for us. When selecting glibmm dependency within the configuration of ARC ("configuration" is simply set of dependencies, environmental variables, and commands to perform to build and test the code) the dependencies were installed in the home directory of the (unprivileged) user that runs the build. Since libraries are installed in non standard locations there is need to set some environmental variables. In our case it was GLIBMM_CFLAGS, GLIBMM_LIBS and CPPFLAGS. After setting them the builds started to pass autoconf and configure steps but always failed in compilation step with error pointing to weird problem with compilation flags. We still did not find resolution to this problem.

Never the less, we have overcome this problem using approach described in IV.C. and we were able to build the code on multiple platforms already. As mentioned earlier the approach consist in setting up components for the dependencies (glibmm in our case) within the ARC project itself. There we have configured dependencies builds from sources for all relevant platforms. The dependencies installation location is also non standard (we've chosen /tmp directory) thus it was necessary to configure PKG_CONFIG_PATH environmental variable to point to relevant locations.