Group Exercises

This page contains information about the general setup for the course project and the initial setup of the ACS development environment. It assumes that you are working within the standard virtual machine prepared for the course.

General Setup

Course virtual machine

To run the CentOS5 vmware virtual machine (32 bits) containing the ACS release 2014.2 you'll need the latest version of vmware player (linux, windows), vmware workstation (linux, windows) or vmware fusion (mac). To reduce the load on the host machine, you may choose to run at user level 3 (no graphical environment). In this case, your host environment should be able to open an xterm and ssh connections to the guest OS.

Network

The network is configured to assign a fixed IP address to each virtual machine. The course virtual machines will be named:

Name	Resp	user	IP (192.168.0.)	Module
database	Guigue	teamd	111	DataBase
instrument	Danilo, Pedro	teami	114	Instrument
telescope	Fede, Leandro, Fernando	teamt	110	Telescope
scheduler	César, Roberto, Zulema	teams	117	Scheduler
integration	Tomás, Jorge	cts	112	N/A

Instructions to change the hostname of your virtual machine can be found in this article: CentOS name change. To facilitate name resolution, the hosts file in your virtual box should include an entry for each virtual machine used during the course:

# virtual machine <vm_name>
192.168.0.XXX   <vm_name>.<domain> <vm_name>

alma unix group

An alma unix group with GID 335 should be created in your environment. This is strictly speaking just a convention, but since many scripts may make reference to this group, having it may make life simpler. If you don't have it, simple add it using the groupadd command:

# /usr/sbin/groupadd -g 335 alma

Users

The following unix users will be used in the course during the development:

• its: for integration
• teamt: telescope development
• teami: instrument development
• teams: scheduler development
• teamd: database development

Add them to your machine using the useradd command:

# /usr/sbin/useradd -m -g alma -s /bin/bash -d /home/<user> <user>

Before you begin

1. Check that your machine is booting correctly and getting a fixed IP address
2. Check that almamgr account exits and that you can login to it
3. Check that the /alma/ACS-2014.2/ directory exists and is populated
4. Check that your development account is using a bash shell
   • Simply run echo $SHELL and check that the output reads /bin/bash
5. Create the course users in your virtual machine.
   • Use the same UIDs across the virtual machines to make the global configuration consistent

Group Exercise #1: Setting up an ACS work environment

Setting up the ACS environment variables

1. Login as the main user assign to your machine (f.i. teamt)
2. Create a .acs directory

[user@host]$ cp -r /alma/ACS-2014.2/ACSSW/config/.acs $HOME

1. Source the ACS bash profile
   • add the following lines to your $HOME/.bashrc file

# setting up INTROOT
export INTROOT=$HOME/introot
# sourcing ACS environment variables
source .acs/.bash_profile.acs

1. Logout and login your account and open an xterm. The prompt should read

user> 

Starting/stopping ACS services and running the tools

1. Start the ACS Command Center typing acscommandcenter at the command line
2. Start ACS services and manager pressing the start button on the GUI. Alternatively, type acsStart at the command line
3. Start containers. ACS default demo containers are named:
   • bilboContainer (C++)
   • frodoContainer (Java)
   • aragornContainer (Python)
4. You can use the ACS Command Center or alternatively the following command lines:

user> acsStartContainer -<lang> <name>
user> acsStopContainer <name>

1. Start the tools from the Tools menu. Object Explorer and Logging Client in particular. Alternatively you can start the tools from the command line with the following commands: objexp, jlog
2. Activate and deactivate ACS components from the object explorer
3. Stop ACS and all running containers by pressing the stop button on the GUI or using the command acsStop

Group Exercise #2: Setting up a development environment

Setting up the your local git repository

Git is used as the source code repository. Below are the elementary working commands. A more complete git commands reference is here. Before you start you need to define your git user name (same as development account) and e-mail:

user> git config --global user.name $USER
user> git config --global user.email $USER@$HOSTNAME

Cloning the course repository

There is a central git repository at the integration server. You will clone that repository and do all further changes locally by issuing:

user> git clone git://integration/ACS-Workshop

Pulling from the repository to get updates

You can get the latests updates for your local repository from the central server:

user> git pull

Pushing to the repository to provide your updates

To commit changes to your local repository:

user> git add [changed files]
user> git commit

And to push your changes back to the central server (and make them available to others):

user> git push

If you are not sure you can always check the change status: user> git status

Setting up your INTROOT area

Create an integration root area for your personal account (INTROOT) by issuing the following commands:

user> rm –rf $INTROOT
user> getTemplateForDirectory INTROOT $INTROOT

Setting up your your first software module

Documentation about tools and module structure: ALMA Software Development Tools and Integration Procedures. Create a new module using the getTemplate command:

user> cd ~/<local repository>
user> getTemplate

and navigate the text menu as follows:

• directoryStructure -> create WS_MODROOT area ->

Inside the ICD module, run make all to compile the IDL files and generate all stubs and skeletons.

user> cd ~/<local repository>/ICD/src; 
user> make clean all install 
user> cd ˜/<local repository>/<module name>/src
user> make clean all install 

Group Exercise #3: LOS Development

First Day

The task for the first day is to implement a first empty component in C++ that compiles correctly, setting up the CDB and run a manual test using a python simple client. Progress will be measured as follows:

• 30% C++ component code successfully compiling
• 60% Test CDB configured and ability to use the object explorer to activate/deactivate the component
• 100% Run a python simple client script to activate/deactivate to the component

Second Day

The tasks for the second day are to create a first automatic component test, a first system commit, running the test against an integrated test CDB, and incrementally adding functionality. The progress will be measured periodically against the following metric:

• 30% First integration with at least manual tests
• 60% Core per-component functionality ready
• 100% Run of integrated system at the end of the day

Group Exercise #4: LOS Integration

The task for the third day is to add errors and logging to each component and fully integrate the system to run an automatic observation. Progress metrics are:

• 30% Logging and Error handling coding
• 60% Integrated test before lunch, identifying critical path
• 100% Successful end-to-end automatic observation

TODO list

Who	What	Status
NN	Something

Worklog, Conclusions and Final Remarks

First Day

• Initial difficulties with the network setup. Provided router had limited capacity and router had to be reconfigured to assign fixed IPs to virtual machines. Difficulties in setting up vm intercommunication
• Missing requirements on hosts running vmware images. Many had old laptops with just 2GB RAM or slow CPUs
• Not all participants had worked recently with C++, little to no CORBA experience
• C++ component tutorial too advance for the basic track. Need ACS component examples (instead of characteristic components examples).
• Difficulties in understanding what needed to be done to start the exercise. Need to bridge better concepts and methodology with the code mechanics. DataBase was the most affected
• Progress: 3/4 of first goal (30%) -> 22.5% of first day

Second Day

• Review of difficulties on previous days. Bridged concepts with C++ class diagrams for the coding mechanics. Minor fixes to the code were provided by ITS (MACI macros, method signatures)
• After providing a project CDB and demonstrating activation/deactivation to the group reached 100% of second goal for first day
• First integrated manual tests (ITS/config/CDB created, activation/deactivation with objexp, activation/deactivation with python simple client).
• Progress: 30% of second day reached
• Initial pyUnit test and TAT files examples provided, pointers to acsexplBuiding and acsexmplFridge examples provided. Skeleton for DataBase component provided

Third Day

-- Jorge Ibsen - 2014-08-22