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 Question

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 at 10:00: 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
  • teamt: first functions ready, first unit test ready, missing TAT references and error handling
  • teami: two components up and running, first functions ready, missing unit test
  • teams: test infrastructure being developed, no functional development nor unit tests yet
  • teamd: no functional development nor unit tests yet. Impaired by team size, requested help from teamt
  • its: show and tell for teamt and teami, brief TAT talk
  • Progress at 15:30: 40% of second day
  • At the end of the day:
    • teamt had their functionality ready, manually tested and were working on the tests.
    • teami was adding error and logging
    • teams was starting to develop thread management for the sb execution
    • teamd finished core functions. Module compiles, but there was not time to test it before leaving
  • Progress at 18:00: 50% of second day

Third Day

  • First integration at the beginning of the day, code review and tests on a per component basis. Each team had to explain their code and share with others their findings. Status:
    • teamt: functionality completed, tests needed to be added, passed execution
    • teami: functionality completed, tests needed to be added, passed execution
    • teamd: 70% functionality coded with runtime errors. Took the opportunity to use gdb to debug. Code corrected
    • teams: functionality coded, not possible to test without database. Code review indicated improvement areas
  • Progress at 10:00: 100% of second day reached
  • Next step: focus on finishing tests, functionality and helping teamd to finish
  • Progress at lunch: 30% of third day
  • After lunch, code was declared frozen and an interactive debugging session on a per component session was started, with all participants
  • Progress at 16:30: 60% of third day
  • All components managed to start around 14:30
  • Per component test until 15:00
  • End to end integrated system tested (through python scripts) successfully around 15:30 on a single machine
  • Progress at 15:30: 100% of third day (running on a single machine)
  • End to end integrated system on a distributed until 16:15.
  • Progress at 16:10: 100% of third day (running on a distributed environment)
  • APPLAUSE!
  • ACS Community presentation. Walk through the pages, scope, participants and discussion
  • Group photo

Conclusions

All attendants gave positive feedback. Most relevant are:
  • Zulema: More time explaining the course project.
  • Danilo: Improve initial instructions to understand the steps that need to be taken initially
  • Cesar: C++ component tutorial too advance for a component primer, a simpler step by step tutorial is needed
  • Tomás: Without the characteristic components, complexity level per component is not correctly balanced. Need fully develop examples for each language. Database component blocks Scheduler development if no simulation is available.
  • Jorge: specs for network, host machines need to be better specified. Need for lego toy models to make this visually attractive.
  • Overall positive feedback about the course content and methodology. Four days would have help to include more topics in the course (characteristic components, notification channel, error development, threads in depth, other languages...).

-- Jorge Ibsen - 2014-08-22

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2014-11-06 - GuillermoGCastro
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback