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:
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
- Check that your machine is booting correctly and getting a fixed IP address
- Check that
almamgr
account exits and that you can login to it
- Check that the
/alma/ACS-2014.2/
directory exists and is populated
- Check that your development account is using a bash shell
- Simply run
echo $SHELL
and check that the output reads /bin/bash
- 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
- Login as the main user assign to your machine (f.i.
teamt
)
- Create a
.acs
directory
[user@host]$ cp -r /alma/ACS-2014.2/ACSSW/config/.acs $HOME
- 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
- Logout and login your account and open an xterm. The prompt should read
user>
Starting/stopping ACS services and running the tools
- Start the ACS Command Center typing
acscommandcenter
at the command line
- Start ACS services and manager pressing the start button on the GUI. Alternatively, type
acsStart
at the command line
- Start containers. ACS default demo containers are named:
- bilboContainer (C++)
- frodoContainer (Java)
- aragornContainer (Python)
- You can use the ACS Command Center or alternatively the following command lines:
user> acsStartContainer -<lang> <name>
user> acsStopContainer <name>
- 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
- Activate and deactivate ACS components from the object explorer
- 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
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