lib/libwrapper.so: wrong ELF class: ELFCLASS32 the last java version for that platform (ex: yum install java-1.7.0-openjdk.x86_64) has to be installed. This user need to be part of Mock in /etc/group: mock:x:498:bambooĭecember 4th 2012: Installation of remote agents and test jobs on them The Bamboo software in the nodes has to be running as Bamboo user. This plugin ( ) will be review for allowing execute the poweroff at the end of the build In production the nodes have to be secured:

Install Bamboo software and mark it to run under Bamboo userĭecember 5th 2012: Investigating how to do remote deployment testsĭisabled remote agent authentication on the Bamboo server to be able to start/stop nodes without having to manually approve them in the tool.

The artifacts are stored in the main server before the restarting of the agent, so it is not a problem that the agent is reverted to the clean checkpoint.

More logic can be added later to provide capacities to manage high platform demands, etc. This script will restore the initial checkpoint in the stopped nodes and start them. This will shout down the node at the end of the job.Ī small script, that is a more basic copy of the ETICS pool control, has to be created to run every minute. Of course bamboo user has to be added to the /etc/sudoers in this way: It is necessary to add a stage, can be called poweroff, and create inside a task which post command in case of success and failed is 'sudo poweroff'. The main problem to had clean nodes was how to poweroff the node after a job. It has only to run as frequent as possible, check the nodes that are powered off, restart the initial check point, and start them.ĭecember 6th 2012: Investigating how to do remote deployment tests It can be based on the current script used in ETICS to control the pool, but simpler.

A script to restore the checkpoints is needed.

From the user's point of view, he will have a static pool of agents always ready to run a job. This nodes will be reverted to the checkpoint simply by adding a new stage on the job (that should be mandatory or converted to a plugin). They will be created in Openstack, based on minimal images with a little customization needed to correctly run the jobs coming from Bamboo.

For the remote agents, the future Agile infrastructure is the most obvious target.

In case of problems with the server, it could be easily reinstalled by only pointing to the central database.

For the database, we can store it in the central service.

The folder where all the artifacts are stored should be mapped to a high capacity and reliable system such as AFS.

For the server, a virtual node is enough as zero jobs will be executed there.

Worklog December 6th 2012: Suggested infrastructure

Discussion with Alejandro about how emi.favorite is doing the deployments.End October - Mid November 2012: Installation of testing Bamboo server (attemp 1).Mid November - November 26th 2012: Installation of testing Bamboo server (attemp 2).November 27th 2012: Installation of testing Bamboo server (attemp 3).

November 30th 2012: lcgdm-dsi job replication.December 3rd 2012: Installation of remote agents.December 4th 2012: Installation of remote agents and test jobs on them.December 5th 2012: Investigating how to do remote deployment tests.December 6th 2012: Investigating how to do remote deployment tests.

December 6th 2012: Suggested infrastructure.

Deployit vs puppet