Choose timezone
Your profile timezone:
CERN Coordination Meeting
Description
Agenda:
- Transaction status
- Locking status
- Summarize the valid use cases when a parent configuration is provided in order to lock (what we discussed yesterday)
- Need to schedule design discussions on requirements from SA3/Porting and DILIGENT:
DILIGENT reqs:
1) locking of configurations, to prevent changes in stable/released configurations. Recursive locking (i.e. propagate the lock to
subconfigurations) might also be considered. (HIGH)
2) access control - it should be possible to avoid anonymous access to the datamodel of a project, its reports and artefacts. This is related to the possibility of controlling grants on read operations, as already done with write/submit operations. (HIGH)
3) when renaming modules, change property names in commands of configurations for which the renamed configuration is visible (e.g.
configurations depending on module configurations). Without this, all the commands have to be modified manually. (NORMAL)
4) when renaming modules, also rename properties used in dynamic dependency resolution (i.e. <modulename>.DEFAULT properties). (NORMAL)
5) allow to move components among projects/subsystems (NORMAL)
6) investigation of how to automatically deploy a component grouping all needed information in a possible "Deploy Command" associated to the configurations. (NORMAL)
7) provide a way (activable by the user) to automatically copy known files/directories provided in known locations of a module (e.g. /README, /INSTALL, /LICENSE, /CHANGELOG, /doc/public/, ...) to ${prefix} for automatic inclusion in the package. (Could this be achieved by selecting some plugin/profile?) (LOW)
SA3/Porting:
Base OS package issues
______________________
Dependencies such as httpd-devel, mysql-devel, glib2-devel, swig and expat currently require a porter to package up a tarball of an RPM already in the base OS, put it into AFS and change org.glite property overrides. All of these current requirements are unnecessary. All that is required is a package.location variable that is set per platform. If the module is found on the OS it will not be installed from the ETICS database in AFS.
Action: ETICS will support base OS dependencies.
Caveats: We have noted that Debian doesn't have a set install location for packages, however if a package management system has a set location this should be used before attempting to download the dependency.
ETICS node building
___________________
TCD has tried to roll back to the glite-WN configuration specified by Laurence. However it has been seen that features that existed in February
2007 no longer apply in etics-client >= 1.0.0. This means that certain modules will not build. TCD also found that there is an issue with inconsistent CVS tags. Some service-discovery modules use tags of the form module_R_x_y_z for release 1 modules, but use module_R_x_y_z_r for release
2 modules. This means that it is difficult to deduce the version required to automatically generate org.glite.node.WN and other node types. ETICS now have a mandate to generate all node configurations.
Suggestions: TCD suggests the enforcement of a consistent CVS tagging policy and moving to release 2 or later of the problematic modules.
Caveats: Note that having the binary versions of release 1 modules already in the repository for some modules may disguise the fact that these modules no longer build. TCD suggests that CERN should have a build from binary and build from source build machine to highlight the problems to developers.
Patching System
_______________
TCD can patch modules using a script that implements a Linux patch, command line option or a sed script. This should eventually become a contribution to ETICS called etics-patch. It should be a new option at the end of the VCS command that automatically patches the checked out modules.
Actions: There activity would benefit greatly from platform specific cloning of configurations rather than just a complete clone of configuration. This allows the porter to copy all build commands and checkout commands that can allow patching in between. Alternatively, and probably a better solution is the inclusion of a new action that allows patching without having to clone the checkout and build rules. The patching mechanism will then only be visible on platform configurations were it is absolutely necessary.
NMI Building
____________
TCD needs NMI building locally. Then cross-site NMI building is required.
To start with TCD requires a submit node and execute nodes for NMI building. The submit node contains the ETICS server. This ETICS server (installed at TCD) will need to authorize TCD users and therefore requires a mysql-jdbc connection to CERNs central manager and dB host. If we do it this way TCD can then register its RPMs into CERN. If we mirror the dB on a nightly basis we can then mangle the dB as much as we like for testing, and we can test new assumptions.
Eventually we could (if TCD college policy allows) implement a cross-site solution that allows others to submit to our site, with the requirement that we can drop the jobs with our own higher priority jobs. TCD at least would have the option to submit jobs remotely to CERN to confirm configurations work at multiple sites.
Note: most of the requirements of TCD and also the requirements of industry partners, so TCD can act as a beta-tester of the 4 issues mentioned above.
The agenda of this meeting is empty
