• 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

• 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

• 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...).

• Progress at 10:00: 30% of second day reached

• 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

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

1. Check that your machine is booting correctly and getting a fixed IP address

• 60% Integrated test before lunch, identifying critical path

• database
• instrument
• telescope
• scheduler
• integration

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.1.XXX   <vm_name>.<domain> <vm_name>

alma unix group

# /usr/sbin/groupadd -g 335 alma

Users

• 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. 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

1. Login as the main user assign to your machine (f.i. teamt)

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

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

user> git clone ssh://its@integration/opt/git/los.git

user> git pull

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

user> git push

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

• directoryStructure -> create WS_MODROOT area ->

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

• 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

• 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

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

TODO list

Who	What	Status
NN	Something

• tel
• ins
• sch
• dba
• its

1. Login as the main user assign to your machine (f.i. tel)

•  cd ~/<local repository>/ICD/src; make clean all install 

•  cd ˜/<local repository>/<module name>/src; make clean all install 

• • cp -r /alma/ACS-2014.2/ACSSW/config/.acs $HOME

1. Stop ACS and all running containers by pressing the stop button on the GUI or using the command acsStop

• git status

1. Check that almamgr account exits and that you can login to it
2. Check that the /alma/ACS-2014.2/ directory exists and is populated

• • Simply run echo $SHELL and check that the output reads /bin/bash

1. Create a .acs directory
   • run cp -r /alma/ACS-2014.2/ACSSW/config/.acs $HOME

• • add the following lines to your $HOME/.bashrc file

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

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

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

• git clone ssh://integration/opt/git/los.git

• git pull

• git add [changed files]
• git commit

• git push

• cd ~/
• getTemplate -> directoryStructure -> create WS_MODROOT area ->

• cd ~//ICD/src; make clean all install
• =cd ˜///src; make clean all install =

Assignments

• Database (C++):
• Scheduler (C++):
• Instrument (C++):
• Telescope (C++):
• Integration: Jorge, Tomás

Group Exercise #N: LOS Development

Database

Scheduler

Instrument

Telescope

Integration

• Jorge, Tomás

First Day

Second Day

Group Exercise #N: LOS Integration

Third Day

Conclusions and Final Remarks

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

Network

• database
• instrument
• telescope
• scheduler
• integration

• dba
• ins
• tel
• sch
• its

Group Exercise #1: Setting up an ACS work environment

Before you begin

1. Check that your machine is booting correctly and getting a fix 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

Setting up the ACS environment variables

1. Create a .acs directory
   • run cp -r /alma/ACS-2014.2/ACSSW/config/.acs $HOME
2. Source the ACS bash profile
   • add the following lines to your $HOME/.bashrc file

      export INTROOT=$HOME/introot
      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:

acsStartContainer -<lang> <name>
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

1. Activate and deactivate ACS components from the object explorer
2. Stop ACS and all running containers by pressing the stop button on the GUI or using the command

Group Exercise #2: Setting up a development environment

Setting up the your local git repository

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

Cloning the course repository

• git clone ssh://integration/opt/git/los.git

Pulling from the repository to get updates

• git pull

Pushing to the repository to provide your updates

• git add [changed files]
• git commit

• git push

• git status

Setting up your INTROOT area

rm –rf $INTROOT
getTemplateForDirectory INTROOT $INTROOT

Setting up your your first software module

• cd ~/
• getTemplate -> directoryStructure -> create WS_MODROOT area ->

• cd ~//ICD/src; make clean all install
• cd ˜///src; make clean all install

Jorge Ibsen - 2014-08-22