Agenda

- Removing default value for dynamic dependencies
- Use fully qualified names for module.DEFAULT
- Locking functionality
- Scheduler functionality
- Workpackage status

Participants:

Marian, Tomasz, Meb, Lorenzo, Alberto, Guillermo, Elisabetta, Matteo, Saverio and Mattia.
Peter and Eva

1. Removing default value for dynamic dependencies

In order to satisfy this requirement the following changes are necessary:

. Database

- For all entries where the dynamicDependencyID is set the dependencyId should be set to null

. WS

- Some minor changes and checks

. Client

- During the checkout the presence for this configurationID should not be checked anymore. If it's
not possible to resolve the value dynamically it should not rely on this value
- On the editing part, the defaultConfigurationID should not be set when creating/updating a configuration
- It might also affect the INI file. The changes could be applied in one day.

. WA

- Do not display the default value
- When creating dynamic dependencies it should not allow to select a configuration but a module
- It is not clear if it should be allowed to select a module or a module and a configuration. In principle both will be valid

* The constraint to release this change should be done once locked is released.
The problem is that people depending on other project's configurations might fail unless the dependency is set on a locked configuration.

- In principle these changes are to be applied by 15th July, we'll see when it's released (depending on the locking feature)
- Deploy lxb2180.cern.ch with WS 1.2 and a cloned DB from etics.cern.ch

2. ITEM 35. Use of fully qualified names in .DEFAULT

- Currently we are using as properties for the dynamic dependencies moduleName.DEFAULT. This breaks if there are two modules with the same name.
The proposal is to qualify this like: projectName.moduleName.DEFAULT
- Changes:
  1. DB update
  2. checkout command to be updated
  3. editing part to set these values
- These changes only affect the client
- For the editing only two lines of code should be

. There is an open bug related to the fact that when a module name is updated the dynamic dependencies break, it needs to be discussed

3. Locking:

Work in progress

4. Work package status

WP1

- No particual technical announcement
- The EGEE All Activity Meeting took place during the last days. In the next EGEE review better QA information should be presented (requested by the reviewers). Next review will take place in May/June next year.

WP2

- Working on fixing the draining problems with cross site migration. Need to analyze the different security policies
- It's working fine, CERN/INFN migration should be working fine
- It would be good if people could try it
- Marian is working to add nodes in XXX IPv6
- Marian has been working in the Service Installation Guide
- Some other bug fixing, Condor failures
- The ETICS side in UW is running fine

WP3

- Finish the 1.1.0 test, some fixes have been committed
- Local editing testing the executeTransaction method, it seems to work
- 1.1.0 etics-log command allows you to specify dates without hours

WP4

 - Focused on testing diligent. Some problems encountered with the default platform
 - To do: modify the installation plugin and finish the final version of the deliverable

WP5

- Two deliverables already late (5.7 and 5.9), drafts required by the reviewers (were due by the end of the year)
- Adriano is working on that
- D5.9 (Dissemination plan) sent for review to the PMB
- Alberto Comte is working in trend analysis
- Lorenzo is working to extract metrics from the build/test reports so that it can be archived and analysis can be performed (under development)
- Working on the new look and feel for the WebApplication. The idea is to release the same functionality we currently have
- Working on co-Scheduling using the new setter and getter methods