Quattor Workshop - CNAF (Bologna) - 30/9/2013-2/10/2013

Table of Contents

1. Project Status - L. Munoz
2. Core modules
   1. Configuration Modules - L. Munoz
   2. ncm-ncd hooks and policy-based component scheduling

​Agenda

Project Status - L. Munoz

Survey ran before the workshop

• Significant improvement compared to previous ones
• QWG : many were not able to move to QWG or forked a long time ago. We need to think more heavily at it.
• Aquilon adoption making progress (2-3 sites)
• Community support is perceived as good
• Documentation: still the weak point, were not able to make significant progresses
  • LAL wiki: certificate problem still perceived as a barrier, a developer only resource

Core modules

Configuration Modules - L. Munoz

Releases

• Count : nine releases, 3 of them tagged as stable
  • New releases are not mandatory
• Need a releaser manager backup for Luis

Config modules: main activity is on the core components

• Not much on grid components or on daemons
• ncm-openldap and ncm-cups were resurrected

New features

• Preliminary support for SSSD in authconfig
• YUM-based SPMA ready for production
• Hooks for ncm-ncd before and after execution of components

Metaconfig stuff

• Ugent has schemas and templates for many services: would like to share them
  • But we can hardly promise backward compatibility

Work in progress

• Policy-based component dispatching in ncm-ncd
• Solaris port
• ncm-network: still not much progress

ncm-ncd hooks and policy-based component scheduling

See proposal.

Goal: execute some arbitrary actions before running all components and after.

• These actions will have no access to node profile
• Specified by run-init and run-finalizein /etc/ncm-ncd.conf
• An error during run-init will prevent executing components but run-finalize will run

Hooks may be used to implement site-specific policy for component scheduling, allowing to filter out some components from the initial list based on some local criteria

• But what to do with dependencies if one is filtered out? Can be very complicated
• Probably better/enough to implement a "everything or nothing" strategy: at least use case can be cleanly defined

Some use cases for executing only part of the configuration changes for a component. Proposal:

• Split component configuration into 2 different parts/subtree, e.g. /software/components/filecopy and /software/components/filecopy-magic
• Bind /software/components/filecopy-magic to type_filecopy
• Define a component alias name in filecopy-magic saying it will use component filecopy to execute the action
  • New field in deps structure
• Filter out filecopy-magic in run-init hook